前言

分散式服務架構不僅僅包含核心的執行時類庫，還包括服務劃分原則、服務化最佳實踐、服務治理、服務監控、服務開發框架等，它是一套完整的解決方案，用來協助應用做服務化改造，以及指導使用者如何構建適合自己業務場景的服務化體系，將服務化的價值發揮到極致。

基於分散式服務架構，業務終於可以把全部精力都放到應用層的邏輯開發，研發效率、系統可靠性都得到了極大的提升。目前，華為電信軟體主要解決方案几乎所有的Java系統都基於分散式服務架構構建，底層的基礎框架實現了統一。

近年來，隨著DevOps和以Docker為首的容器技術的發展，微服務架構逐漸流行起來，微服務架構的流行有其必然的歷史原因，它是敏捷開發、基礎設施服務化、DevOps和網際網路行業快速發展的綜合產物。亞馬遜AWS、Netflix 等都是微服務的成功實踐者，相信未來國內越來越多的大型應用也會演進到微服務架構。

華為軟體公司的Java架構經歷了傳統的MVC垂直架構-RPC框架-分散式服務架構，目前正在向Docker+微服務方向演進，整個服務化架構的演進歷程也是業界技術變遷的一個縮影。

 

所以說，分散式服務架構和微服務，都是成為架構師之路的重要基石，不可或缺的技術，小夥伴們要重視這一塊兒內容的學習。

今天剛好，就給大家準備了這兩塊兒的技術知識，希望大家能夠喜歡多多轉發讓更多人受益！

咱們將把這兩部分知識從目錄、內容和具體章節逐一介紹，大家要仔細研讀！

首先，給大家介紹的第一塊兒內容是——分散式服務架構原理實踐

1.目錄

 

2.主要內容

第1章，應用架構演進

隨著業務的發展，應用規模不斷擴大，系統內部的巨無霸應用越來越多，常規的垂直應用架構已經無法應對複雜業務帶來的各種挑戰。通過將業務公共能力抽象成原子服務，對複雜應用進行水平拆分和服務化，實現服務消費者和提供者的解耦。公共能力抽取和複用，可以有效降低公共模組重複開發建設的成本。

傳統垂直架構改造的核心就是要對應用做服務化改造，服務化改造使用到的核心技術架構就是分散式服務架構。

本章對應用架構的演進歷史進行剖析，使讀者能夠更清晰和全面地瞭解應用架構的歷史演進過程以及未來架構的發展方向。

第2章，分散式服務架構入門

在一個不斷髮展的大型應用中，新的業務需求和功能不斷增加，技術也在不斷演進，不同團隊構建的功能子系統採用的技術架構五花八門，子系統之間的開發、部署和運維模式也存在較大差異。如果企業內部沒有統一的服務架構進行技術層面的拉通，開發和運維效率都將受到很大制約。

傳統垂直架構改造的核心就是要對應用進行服務化，服務化改造使用到的核心技術就是分散式服務架構。

第3章，通訊框架

單機版的本地方法呼叫變成遠端服務呼叫之後，一個高效能的通用通訊框架成為分散式服務架構必不可少的有機組成部分。

通訊框架涉及到Socket通訊、多執行緒程式設計、協定棧等相關知識，這部分在Java 技術堆疊中屬於偏難掌握的部分。本章將對通訊框架的原理和設計重點進行詳細講解，以期大家可以儘快熟悉通訊框架的設計要點並在實際工作中靈活使用。

第4章，序列化與反序列化

服務提供者和消費者通過網路進行通訊，物件需要進行序列化和反序列化，常見的序列化和反序列化方式很多，如何選擇是重點也是難點。

第5章，協定棧

不同服務在效能上適用不同協定進行傳輸。比如對接異構第三方服務時，通常會選擇HTTP/Restful 等公有協定:對於內部不同模組之間的服務呼叫，往往會選擇效能較高的二進位制私有協定。

第6章，服務路由

分散式服務架構.上線執行時都是叢集組網，這意味著叢集中存在某個服務的多範例部署，消費者如何從服務列表中選擇合適的服務提供者進行呼叫，這就涉及到服務路由。分散式服務架構要能夠滿足使用者靈活的路由需求。

第7章，叢集容錯

叢集服務呼叫失敗後，服務架構需要能夠在底層自動容錯，容錯策略很多，分別適用於不同場景。本章將對叢集容錯的功能和設計進行詳細講解。

第8章，服務呼叫

除了常用的同步服務呼叫之外，分散式服務架構還需要支援其他幾種形式的服務呼叫，本章將對這些呼叫方式進行詳細講解。

第9章，服務註冊中心

對於服務提供者，它需要釋出服務，由於應用系統的複雜性，服務的數量、型別不斷膨脹;對於服務消費者，它最關心的是如何獲取到它所需要的服務。對於服務提供方和服務消費方來說，它們還有可能兼具這兩種角色:既需要提供服務，又需要消費服務。

如何有效地管理服務訂閱/釋出,避免寫死地址資訊是分散式服務架構需要解決的一個問題。通過將服務統一管理起來， 可以有效地優化內部應用對服務釋出/使用的流程和管理，服務註冊中心就是專門用來管理服務訂閱/釋出的設定管理節點。

第10章，服務釋出和參照

服務提供者需要支援通過設定、註解、API 呼叫等方式，把本地介面釋出成遠端服務:對於消費者，可以通過對等的方式參照遠.程服務提供者，實現服務的釋出和參照。

第11章，服務灰度釋出

灰度釋出是指在黑與白之間，能夠平滑過渡的一種釋出方式。

AB test 就是一種灰度釋出方式:讓一部分使用者繼續用A,一部分使用者開始用B;如果使用者對B沒有什麼反對意見，那麼逐步擴大範圍，把所有使用者都遷移到B上面來。灰度釋出可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度。

第12章，引數傳遞

服務消費者和提供者之間進行通訊時，除了介面定義的請求引數，往往還需要攜帶一些額外引數，例如訊息提供者的IP地址、訊息呼叫鏈的跟蹤ID等;這些引數不能通過業務介面來進行傳遞，

需要底層的分散式服務架構支援這種引數傳遞方式。

第13章，服務多版本

服務上線之後，隨著業務的發展需要對功能進行變更，或者修復線上的BUG;服務升級之後，往往需要對服務採用多版本管理。

服務多版本管理是分散式服務架構的重要特性，它涉及服務的開發、部署、線上升級和服務治理。

第14章，流量控制

當資源成為瓶頸時，服務架構需要對消費者做限流，啟動流控保護機制。流量控制有多種策略，比較常用的有:針對存取速率的靜態流控、針對資源佔用的動態流控、針對消費者並行連線數的連線控制和針對並行存取數的並行控制。

在實踐中，各種流量控制策略需要綜合使用才能起到較好的效果，本章針對分散式服務架構的流量控制設計原則和實踐進行講解。

第15章，服務降級

大促或者業務高峰時，為了保證核心服務的SLA,往往需要停掉一些不太重要的業務，例如商品評論、論壇或者粉絲積分等。

另外一種場景就是某些服務因為某種原因不可用，但是流程不能直接失敗，需要本地Mock伺服器端實現，做流程放通。以圖書閱讀為例，如果使用者登入餘額鑑權服務不能正常工作，需要做業務放通，記錄消費話單，允許使用者繼續閱讀，而不是返回失敗。

上述兩種場景，都使用到了分散式服務架構的一個重要服務治理功能:服務降級。服務降級主要包括容錯降級和遮蔽降級兩種模式，下面我們就兩種服務降級的策略和設計進行講解。

第16章，服務優先順序排程

當系統當前資源非常有限時，為了保證高優先順序的服務能夠正常執行，保障服務SLA，需要降低一些非核心服務的排程頻次，釋放部分資源佔用，保障系統的整體執行平穩。

服務優先順序的排程策略非常多，對於分散式服務架構而言，需要能夠支援服務釋出時設定優先順序策略，並在資源成為瓶頸時，按照使用者設定的優先順序策略排程執行服務。

第17章，服務治理

隨著業務的發展，服務越來越多，如何協調線上執行的各個服務，保障服務的SLA，對服務架構和運維人員是一個很大的挑戰。

隨著業務規模的不斷擴大，小服務資源浪費等問題逐漸顯現，需要能夠基於服務呼叫的效能KPI資料進行容量管理，合理分配各個服務的資源佔用，提高機器的利用率。

線上業務發生故障時，需要對故障業務做服務降級、流量控制、流量遷移等，快速恢復業務。

隨著開發團隊的不斷擴大，服務的上線越來越隨意，甚至發生功能相同、服務名不同的服務同時上線。上線容易下線難，為了規範服務的上線和下線，在服務釋出前，需要走服務預釋出流程，由架構師或者專案經理對需要上線的服務做釋出稽核，稽核通過的才能夠上線。

為了滿足服務線下管控、保障線上高效執行，需要有一個統一的服務治理框架對服務進行統一、有效管控，保障服務的高效、健康執行。

第18章，分散式訊息跟蹤

隨著業務分散式架構的發展，系統間的系統呼叫日趨複雜，以電商的商品購買為例，前臺介面的購買操作涉及到底層上百次服務呼叫，涉及到的中介軟體包括:

◎分散式服務架構

◎訊息佇列 .

◎分散式快取

◎分散式資料訪間中介軟體

◎分散式檔案儲存系統

◎分散式紀錄檔採集

◎其.....

如果無法有效清理後端的分散式呼叫和依賴關係，故障定界將會非常困難。利用分散式訊息跟蹤系統可以有效解決服務化之後系統面臨的運維挑戰，提高運維效率。

第19章，可靠性設計

相對於傳統的本地Java API呼叫，跨程序的分散式服務呼叫面臨的故障風險更高。

1)網路類故障:鏈路閃斷、讀寫超時等。

2)序列化和反序列化失敗。

3)畸形碼流。

4)伺服器端流控和擁塞保護導致的服務呼叫失敗。

5)其他異常.....

對於應用而言，分散式服務架構需要具備足夠的健壯性，在平臺底層能夠攔截並向上遮蔽故障，業務只需要設定容錯策略，即可實現高可靠性。

第20章，微服務架構

過去十年，SOA ( Service-Oriented Architecture)架構得到了廣泛的應用，現在，隨著雲端計算、行動網際網路、Docker 容器等技術的快速發展和應用，「微服務」架構(Micro Service Architecture) 這一全新的架構風格越來越受到大家的關注，也有越來越多的企業和平臺服務提供商在實踐中嘗試並使用它來解決具體業務問題,微服務架構的流行已經成為未來技術發展趨勢之一。

第21章，服務化最佳實踐

在服務化之前，業務通常都是本地API呼叫，本地方法呼叫效能損耗較小。服務化之後，服務提供者和消費者之間採用遠端網路通訊，增加了額外的效能損耗，業務呼叫的時延將增大，同時由於網路閃斷等原因，分散式呼叫失敗的風險也增大。如果服務架構沒有足夠的容錯能力，業務失敗率將會大幅提升。

除了效能、可靠性等問題，跨節點的事務一致性問題、分散式呼叫帶來的故障定界困難、海量微服務運維成本增加等也是分散式服務架構必須要解決的難題。本章節我們將對服務化之後面臨的挑戰進行分析，並給出解決方案和業務最佳實踐。

 

其次，給大家介紹第二塊兒內容是——微服務設計

1.目錄

2.主要內容

第1章微服務

隨著領域驅動設計、持續交付、按需虛擬化、基礎設施自動化、小型自治團隊、大型叢集系統這些實踐的流行，微服務也應運而生。它並不是被髮明出來的，而是從現實世界中總結出來的一種趨勢或模式。但是沒有前面提及的這些概念，微服務也很難出現。在本書接下來的內容中，我會嘗試把這些概念整合起來，從而給出一個涉及如何構建、管理和演化微服務的全景圖。

很多組織發現細粒度的微服務架構可以幫助他們更快地交付軟體，並且有更多機會嘗試新技術。微服務在技術決策上給了我們極大的自由度，使我們能夠更快地響應不可避免的變化。

第2章演化式架構師

目前為止可以看到，微服務給我們提供了很多選擇，因此也需要我們做很多決定。比如應該使用多少種不同的技術，不同的團隊是否應使用不同的程式設計規範，是應該合併多個服務還是把一-個服務拆成多個。我們應該如何做決定呢?這些架構支援在頻繁變換的環境下以更快的節奏進行變化，因此架構師這個角色也需要做相應的改變。本章關於架構師職責的觀點是我的個人見解，希望能物件牙塔中的定義發起最後的攻擊。

第3章如何建模服務

現在你已經知道什麼是微服務了，希望你對它的主要優點也有所理解。你可能已經迫不及待地想要實現它了，對嗎?但是從何做起呢?在本章中，我們會討論如何確定服務之間的邊界，以期最大化微服務的好處，避開它的劣勢。但是，首先我們需要有一個產品作為討論的載體。

第4章整合

在我看來，整合是微服務相關技術中最重要的一-個。做得好的話，你的微服務可以保持自治性，你也可以獨立地修改和釋出它們:但做得不好的話會帶來災難。希望本章能夠幫助你在微服務之旅中，避免曾經在SOA中遇到的那些問題。

第5章分解單塊系統

前面幾章討論了什麼是好的服務以及為什麼小服務能達到更好的效果，還討論了系統具有可演化性的重要性。但事實上，可能我們手中已經有了很多程式碼庫，而它們無一例外都沒有遵循上述的模式。如何才能循序漸進地把-一個單塊系統分解開來呢?

單塊系統的形成非一日之功。開發人員每天都對系統新增新功能和新程式碼。一段時間之後，它變成了組織中一個恐怖而巨大的存在，沒人想去修改它。但別擔心，它並不是無可救藥。只要使用了正確的工具，我們就可以手刃這個怪獸。

第6章部署

部署一個單塊系統的流程非常簡單。然而在眾多相互依賴的微服務中，部署卻是完全不同的情況。如果部署的方法不合適，那麼其帶來的複雜程度會讓你很痛苦。本章會講解一些技巧和技術，從而幫助我們]在細粒度的架構中更好地部署微服務。

我會從持續整合和持續交付說起。這些概念與我們下面要討論的主題並不相同，但又有所關聯，了 解它們可以幫助我們在考慮構建什麼、如何構建以及如何部署時，做出更好的決定。

第7章測試

從我開始接觸程式設計至今，自動化測試的世界日新月異，並且幾乎每個月都會出現新的工具和技術，不斷推動這個世界向前發展。不過，如何高效且有效地測試分散式系統的功能依然是一個挑戰。本章會剖析-下測試細粒度系統面臨的問題和挑戰，並提出- -些解決方案，幫助大家更有信心地釋出新的功能。

測試的覆蓋面很廣，即使只討論自動化測試，也需考慮甚多。使用微服務架構以後，測試的複雜度進-步增加。面對這樣的挑戰，瞭解測試有哪些不同的型別，對我們來說便非常重要了。它可以幫助我們實現儘早交付軟體與保持軟體高品質之間的平衡，因為有時魚和熊掌是不可兼得的。

第8章監控

正如我之前所展示的，將系統拆分成更小的、細粒度的微服務會帶來很多好處。然而，它也增加了生產系統的監控複雜性。在本章中，我將帶大家看看細粒度的系統在系統監控和定位問題上所面臨的挑戰，同時還會介紹一些應對方法，讓魚和熊掌兼得!

設想一下這樣的場景:一個安靜的週五下午，團隊期待著早點開溜去酒吧，開始一個遠離工作的週末。然而，突然收到一-封郵件:網站工作異常! Twitter 上到處都是關於貴公司網站出問題的訊息，而你的老闆在旁邊喋喋不休，一個安靜的週末就這麼沒了。

你需要了解的第一件事情是什麼?問題到底出在哪裡?

在單塊應用的世界裡，我們至少要非常清楚該從哪裡開始調查。網站慢?是單塊應用的問題。網站有 異常?是單塊應用的問題。CPU佔用率100% ?還是單塊應用的問題。燒焦的氣味?你懂的，單一的故障點會極大地簡化對問題的調查!

現在，讓我們回到基於微服務的系統。我們提供給使用者的功能，是由多個小的服務組合而成的，其中一些服務需要整合更多的服務來完成功能。這種方法有很多優點(這很好，否則這本書豈不是浪費時間? )，但在監控的世界裡，我們面臨的是一個更為複雜的問題。

我們現在有多個服務需要監控，有多個紀錄檔需要篩選，多個地方有可能因為網路延遲而出現問題。該如何應對呢?我們得好好梳理一下，否則很可能導致混亂，成為一團亂麻，而這是週五下午(或在任何時間! )我們最不想面對的情況。

這裡的答案很簡單:監控小的服務，然後聚合起來看整體。我們從最簡單的系統一-個節點，來展示該如何做。

第9章安全

關於大型系統的安全漏洞導致資料暴露給各種危險人物的故事，我們已經聽說了太多。最近的愛德華●史諾登洩密事件，更加讓我們意識到公司持有的使用者資訊的價值，以及儲存在為客戶構建的系統中的資料的價值。本章將簡要概述設計系統時，在安全方面應該考慮的一些問題。雖然無法包含安全的方方面面，但會列出一-些主要的選項給你，為進一步研究提供一個很好的起點。

我們需要考慮，在資料從一個點到另一個點的傳輸過程中，如何保護它們，也需要考慮在其他情況下如何進行保護。我們需要考慮底層作業系統及網路的安全。有太多需要考慮的點，有太多可以做的事情!那到底需要多安全呢?我們如何知道什麼是足夠安全呢?

我們還需要考慮人的因素。誰在使用我們的系統，他又會做些什麼?而這又與我們的伺服器如何互動有什麼關係?讓我們從這裡開始。

第10章康威定律和系統設計

到目前為止，本書大部分的內容集中在向細粒度架構邁進時所面臨的技術挑戰。但除此之外，我們也需要考慮組織方面的問題。在這一一章， 我們將瞭解到忽略公司的組織結構會帶來什麼樣的危險。

我們的行業還很年輕，它似乎在不斷地重塑自己。不過，一些關鍵定律還是經受住了時間的考驗。例如摩爾定律，它表示積體電路上可容納的電晶體數目每兩年會增加一倍。該定律已經被證明準確得驚人(儘管有人預測，這種趨勢已經放緩)。還有一條定律，我發現幾乎普遍適用，在我的日常工作中也更有用，那就是康威定律。

第11章規模化微服務

當你處理書中的小例子時，一切似乎都很簡單，但現實世界要複雜得多。當我們的微服務架構從剛開始的簡單變得複雜後，會發生什麼呢?當我們不得不處理髮生故障的多個獨立服務，或管理數以百計的服務時，該怎麼辦呢?當微服務的數量比人還多時，有什麼應對的模式嗎?讓我們一起尋找答案吧!

第12章總結

在前面的章節我們已經討論了相當多的內容，從微服務的定義到如何劃分它的邊界，從整合技術到安全和監控。我們甚至還探討了微服務架構下，架構師的角色應該是什麼樣子的。雖然每個微服務本身很小，但是它對架構的影響卻很廣很大，所以還是需要學習很多東西。在本章，我會嘗試總結一些貫穿全書的關鍵點。

 

總結

因為文章內容的限制，小編在這裡就不做過多的介紹了，需要這兩部分完整版實戰技術檔案的小夥伴，可以轉發關注小編，直接檢視下方圖片，掃碼新增或私信小編【技術】來獲取！！

你的過去我來不及參與，但是你的未來我奉陪到底！

持續給大家分享技術知識，希望大家能夠喜歡！！