《分佈式服務架構：原理、設計與實戰》第一章分佈式微服務架構設計原理

一、從傳統單體架構到服務化架構

1.1 JEE架構

JEE將企業級軟件架構分爲三個層級 ： Web 層、業務邏輯層和數據存取層。對應的職能團隊，主要包括：用戶 交互 UI 團隊、後臺業務邏輯處理團
隊、 數據存取 ORM 團隊與 DBA 團隊等。

1.2 SSH架構

MVC模型：

SSH架構層次：實現交互 UI 接口的 Web MVC 層、實現業務邏輯的 Spring 層及實現對象關係映射的 Hibernate層。

每一個層級的實現比JEE對應的層次更簡單、更輕量級 ，不須要開啓整個應用服務器便可測試和驗證，極大提升了開發效率，這得益於 Spring 框架的控制翻轉理念。

1.3 服務化架構

從 JEE 時代到 SSH 時代，服務的特色仍然是單體化，業務邏輯仍然糯合在一個項目中。傳統 JEE 和 SSH 沒法知足對海量用戶發起的高井發請求進行處理的需求，沒法突破稿合在一塊兒的模塊化組件的性能瓶頸，單一進程己經沒法知足需求，而且水平擴展的能力也是頗有限的。因而SOA 出現了， SOA 表明面向服務的架構，俗稱服務化。

SOA特色：

• 良好的對外接口，經過網絡協議對外提供服務。服務之間鬆耦合。
• 單個服務發生改變，不影響整個流程。只要接口不變，對外是透明的。
• 通訊格式XML，後來被JSON取代。
• 服務的可重用性。
• SOA能夠最大化使用內部和外部的公共服務。

SOA 的兩個主流實現方式： Web Service 和 ESB。

Web Service技術使每一個服務之間是對等的，而且互相是解耦的，經過 WSDL 定義的服務發現接口進行訪問 ，並經過 SOAP 協議進行通訊 。 SOAP 協議一般是一種在 HTTP 或者 HTTPS通道上傳輸 X島伍數據來實現的協議，可是每一個服務都要依賴中心化 Web Service 目錄來發現現存的服務。

ESB 的核心在於企業服務總線的功能和職責。

• 監控和控制服務之間的消息路由。
• 控制可插拔的服務化。
• 解析服務之間通訊的內容和格式。
• 統一編排信息處理流程。
• 冗餘備份。

二、從服務化到微服務

2.1 微服務架構的產生

Web Service 的問題：

• 依賴中心化的服務發現機制。
• SOAP使用XML冗餘大。
• 服務化管理和治理設施不完善。

ESB 的問題：

• ESB 雖然是 SOA 實現的一種方式，卻更多地體現了系統集成的便利性，經過統一的服務總線將服務組合在一塊兒，並提供組合的業務流程服務。
• 組合在 ESB 上的服務自己多是一個太重的總體服務，或者是傳統的 JEE 服務等。
• ESB 視圖經過總線來隱藏系統內部的複雜性，可是系統內部的複雜性仍然存在。
• 對於總線自己的中心化的管理模型，系統變動影響的範圍常常會隨之擴大。

微服務架構倡導將軟件應用設計成多個可獨立開發、可配置、可運行和可維護的子服務，子服務之間經過良好的接口定義通訊機制，一般使用 RESTful 風格的 API 形式來通訊 ，由於RESTful 風格的 API 一般是在 HTTP 或者 HTTPS 通道上傳輸 JSON 格式的數據來實現的， HTTP協議有跨語言、跨異構系統的優勢，固然，也能夠經過底層的二進制協議、消息隊列協議等進行交互。這些服務不須要中心化的統一管理，每一個服務的功能可自治，而且能夠由不一樣的語言、系統和平臺實現 。

微服務架構並非爲了拆分而拆分，真正的目的是經過對微服務進行水平擴展解決傳統的單體應用在業務急劇增加時遇到的問題，並且因爲拆分的微服務系統中專業的人作專業的事，人員和項目的職責單1、低藕合、高內聚，因此產生問題的機率就會降到最小。

2.2 微服務架構與傳統單體架構的對比

微服務的架構：

• 微服務把每個職責單一的功能放在一個獨立的服務中 。
• 每一個服務運行在一個單獨的進程中。
• 每一個服務有多個實例運行。運行在容器化的平臺，能夠平滑伸縮。
• 每一個服務有本身的數據存儲。獨立的數據，緩存，消息隊列等。
• 每一個服務有獨立的運營平臺。每一個服務高度自治，內部變化對外透明。
• 每一個服務能夠根據性能獨立地水平伸縮。

 傳統單體架構的伸縮架構：

• 傳統單體架構將全部模塊化組件混合後運行在同一個服務JVM進程中 。
• 可對包含多個模塊化組件的總體JVM進程進行水平擴展，而沒法對某個模塊化組件進行水平擴展。
• 某個模塊化組件發生變化時，須要全部的模塊化組件進行編譯、打包和上線。
• 模塊間的依賴將會不清晰，互相糯合、互相依賴。

2.3 微服務架構與 SOA 服務化的對比

微服務架構與 SOA 服務化雖然一脈相承，卻略有不一樣。

• 目的不一樣。SOA強調異構服務之間協做和集成。微服務目的是拆分，實現敏捷開發部署。
• 部署方式不一樣。拆分紅多個小服務，使用敏捷擴容，Docker實現自動化容器管理。SOA服務將多個服務打包在一塊兒，部署在一個服務器上。
• 服務粒度不一樣。微服務拆分粒度更細，職責單一。經過服務組合實現業務流程。SOA對粒度沒有要求，一般是粗粒度的。

三、微服務架構的核心要點和實現原理

3.1 微服務架構中職能團隊的劃分

微服務架構按照業務的功能進行劃分，每一個單一的業務功能叫做一個服務，每一個服務對應一個獨立的職能團隊，團隊裏包含用戶交互UI設計師、後臺服務開發人員、DBA、運營和運維人員。

3.2 微服務的去中心化治理

微服務架構倡導去中心化的服務管理和治理，儘可能不設置中心化的管理服務，最差也須要在中心化的管理服務宕機時有替代方案和設計。

3.3 微服務的交互模式

• 讀者容錯模式：微服務化中服務提供者和消費者之間如何對接口的改變進行容錯。
• 消費者驅動契約模式：用來定義服務化中服務之間交互接口改變的最佳規則。
• 去數據共享模式：不要共享緩存和數據庫等資源，也不要使用總線模式，服務之間的通訊和交互只能依賴定義良好的接口，一般使用RESTful樣式的API或者透明的RPC調用框架。

共享數據集成的缺點

• 微服務之間的交互除了接口契約，還存在數據存儲契約。
• 上游數據格式變化，可能致使下游的處理邏輯出問題。
• 多個服務共享一個資源服務，資源服務的運維難以劃清職責和界限。
• 多機房部署，須要考慮到服務和資源的路由狀況，跨機房調用，難以實現服務自治。

3.4 微服務的分解和組合模式

使用微服務架構劃分服務和團隊是微服務架構實施的重要一步，良好的劃分和拆分使系統達到鬆耦合和高內聚的效果，而後經過微服務的靈活組裝能夠知足上層的各類各樣的業務處理需求。

組合微服務方式

• 服務代理模式：最簡單的服務組合模式，它根據業務的需求選擇調用後端的某個服務。在返回給使用端以前，代理能夠對後端服務的輸出進行加工，也能夠直接把後端服務的返回結果返回給使用端。通常會對讀請求切換設計一個開關，開關打開時查詢新系統，開關關閉時查詢老系統。典型的案例：平滑的系統遷移。

• 服務聚合模式：最經常使用的服務組合模式，它根據業務流程處理的須要，以必定的順序調用依賴的多個微服務，對依賴的微服務返回的數據進行組合、加工和轉換，最後以必定的形式返回給使用方。

聚合服務能夠是前端應用

也能夠是純後臺服務

 

• 服務串聯模式：相似於一個工做流，服務直接的調用一般使用同步的RESTful風格的遠程調用實現。優勢是在非串聯服務的正後面增長節點，串聯服務無感知；缺點是不建議服務的層級太多。

• 服務分支模式：是服務代理模式、服務聚合模式和服務串聯模式相結合的產物。

以電商平臺的支付服務架構爲例

• 服務異步消息模式：

以電商平臺交易完成後向物流系統發起消息通知爲例

• 服務共享數據模式：實際上是反模式，用於單元化架構和遺留的總體服務。

3.5 微服務的容錯模式

網絡通訊是不穩定、不可靠的，一個服務依賴的服務可能出錯、超時或者宕機。

• 艙壁隔離模式：微服務容器分組和線程池隔離
• 熔斷模式

• 限流模式：計數器，令牌桶，信號量

• 失效轉移模式：當發生了熔斷和限流時，採用快速失敗的策略，直接返回使用方錯誤；如有備份服務，迅速切換；有多是某臺機器出問題，採用重試方式。

3.6 微服務的粒度

微服務初衷是按照業務的功能進行拆分，直到服務功能和職責單一，甚至拆到不可再拆。原則是拆分到能夠合理排版底層的自服務來得到相應的組合服務，同時考慮團隊人員分配。

四、Java平臺微服務架構的項目組織形式

4.1 微服務項目的依賴關係

• 一方庫：本服務在JVM進程內依賴的Jar包。
• 二方庫：在服務外經過網絡通訊或者RPC調用的服務的Jar包。
• 三方庫：所依賴的其餘公司或者組織提供的服務或者模塊。

4.2 微服務項目的層級結構

4.3 微服務項目的持續發佈

微服務項目須要實現自動化的持續部署和持續集成的功能，包括：代碼管理、自動編譯、發佈QA、自動化測試、性能測試、準生產部署和測試、生產環境發佈等。

五、服務化管理和治理框架的技術選型

5.1 RPC

5.2 服務化

SOA服務化時代的服務化框架和平臺

5.3 微服務