微服務架構綜述

什麼是微服務架構

微服務架構是一種架構模式，它提倡將單一的應用程式劃分為一組小的服務，服務之間互相協調、互相配合，為使用者提供最終價值。每個服務執行在其獨立的程序中，服務與服務間採用輕量級的通訊機制互相溝通（通常是基於HTTP的RESTful API）。每個服務都圍繞具體業務進行構建，並且能夠被獨立地部署到生產環境、類生產環境等。另外，應儘量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建。 ---------Martin Fowler

微服務要多“微”？

微服務架構通過對特定業務領域的分析與建模，將複雜的應用分解成小而專一、耦合度低且高度自治的一組服務，每個服務都是很小的應用，那麼“微”的程度到底是怎樣的？

由於不同語言有不同特點，不同功能的替換或重寫很大程度取決於成員的能力，因此程式碼行數的多少以及重寫時間的長短都不能用於衡量“微”。

微服務的“微”並不是一個真正可衡量、看得見、摸得著的微，其所表達是一種設計思想和指導方針。這需要團隊覺得合適，在此之前應遵循以下兩個基本前提：

• 業務獨立性

應保證微服務具有業務獨立性的單元，並不是只是為了微而微。

• 團隊自主性

團隊應該由不同技能、不同角色的成員組成且團隊規模要小。

單一職責

編寫程式碼的原則是“高內聚，低耦合”。高內聚指的是一個模組中各個元素彼此結合緊密；低耦合指的是一個完整的系統中，模組與模組之間應儘可能獨立存在。符合該原則的系統具有良好的重用性、可維護性和擴充套件性，能夠持續支援業務的發展。

面向物件的設計中有“SOLID”原則，S指的是SRP（Single Responsibility Principle，單一職責原則）：即一個物件應該只有一個發生變化的原因，如果該物件可以被多個原因改變，則其承擔了多個職責。

Linux中的每個命令都獨立負責一個功能，但命令與命令可以通過管道連線起來可以實現更強大的功能。類似的，對於每個服務而言，我們希望它處理的業務邏輯能夠單一，在服務架構層面遵循單一職責原則。即微服務架構中的每個服務都是具有業務邏輯 ，符合高內聚、低耦合原則以及單一職責原則的單元，不同服務通過“管道”方式靈活組合，從而構建龐大的系統。

輕量級通訊

服務之間應該通過輕量級的通訊機制，實現彼此的互通互聯，互相協作。所謂輕量級通訊機制，通常指語言無關、平臺無關的互動方式。

對於輕量級通訊的格式而言，XML或JSON的解析與使用基本與語言無關、平臺無關。對於輕量級通訊的協議而言，通常基於HTTP，能讓服務間的通訊變得標準化且無狀態化。REST(Representational State Transfer）是實現服務之間互相協作的輕量級通訊機制之一。

對於微服務而言，通過使用語言無關、平臺無關的輕量級通訊機制，使服務與服務之間的協作變得更加標準化，這就意味著團隊可以選擇更合適的語言、工具或者平臺來開發服務本身。

獨立性

獨立性指在應用交付的過程中，開發、測試以及部署的獨立。

傳統單塊架構應用，所有功能都存在於同一塊程式碼塊中，當修改某部分時，容易出現功能之間互相影響，即功能的開發不具有獨立性。此外，但程式碼實現後，需要整合、迴歸測試，才能保證功能互相配合、正常工作且互不影響，因此測試過程不具有獨立性。當測試完畢，單塊應用被部署後，由於某個特性存在缺陷將導致部署失敗或回滾。

因此單塊架構中，功能的開發、測試、構建以及部署耦合度較高。

微服務架構中，每個服務都是獨立的業務單元，服務與服務之間是獨立的：

• 每個服務都有獨立的程式碼庫，從程式碼庫的層面，服務與服務是隔離的；
• 每個服務都有獨立的測試機制，從測試的角度而言，服務與服務之間是鬆耦合的；
• 構建包是獨立的，部署流程是也是獨立的，服務能執行在不同程序中。從部署角度考慮，服務與服務之間也是高度解耦的

程序隔離

單塊架構應用，所有功能都執行在同一程序中，當要部署時，需要停掉當前的應用，無法獨立部署。為了提高程式碼的重用以及可維護性，在應用開發中，開發人員會將重複的程式碼提取出來，封裝成元件（此處指的是可以獨立審升級、替換掉的部分）。在傳統的單塊架構中，元件的通常形態叫共享庫，例如JAR包或DLL。應用程式在執行時，所有的元件最終也會被載入到同一程序中執行。

微服務架構中，應用程式由多個服務組成，每個服務都具一個高度自制的獨立業務實體。每個服務都能執行在一個獨立的作業系統程序中，這意味著不同服務能被部署到不同主機上。理論上，能將多個服務部署到同一節點上，但這樣增加了部署和擴充套件的複雜度。

綜上所訴，微服務架構其實是將單一的應用程式劃分為一組小的服務，每個服務都具有業務屬性的獨立單元，同時能夠被獨立開發、獨立執行、獨立測試以及獨立部署。

微服務架構與SOA

面向服務架構SOA，對於複雜的企業IT系統，應按照不同的，可重用的粒度劃分，將功能相關的一組功能提供者組織在一起為消費者服務。其目的是為了解決企業內部不同IT系統資源之間無法互聯而導致的資訊孤島問題。

微服務與SOA

微服務的本質

• 服務作為元件
• 圍繞業務組織團隊
• 關注產品而非專案
• 技術多樣性
• 業務資料獨立
• 基礎設施自動化
• 演進式架構

服務作為元件

軟體領域一直提倡使用元件Component的方式將應用模組化併為其構建相對獨立的單元。傳統實現元件的方式是給獨立的部分或者抽取公用部分構建庫Library，從而達到解耦和複用的效果。這樣的共享庫一般是語言相關、平臺相關，且與應用程式執行在同一個程序中。即庫的變化可能導致整個應用都要更新，重新部署。

將微服務作為元件，與傳統使用元件方式最大的區別是，元件可以被獨立部署。即，每個服務的變更僅需重新部署自身，不影響其他服務。

因此，微服務架構的一個優勢就是能以鬆散的服務形式，構建可獨立化部署的模組化應用。把服務當成元件的另一個優點是，元件和元件之間定義了清晰的、語言無關的、平臺無關的介面。許多開發雖然有良好的公共呼叫介面，但依賴於特定平臺和語言，導致元件間耦合度高。

微服務通過語言無關、平臺無關的輕量級通訊機制協作，靈活性高。不足的是分散式呼叫比程序內呼叫更消耗時間，且嚴重依賴於網路的可靠性與穩定性。

圍繞業務組織團隊

微服務架構團隊組織方式提倡以業務為核心，按照業務能力來組織團隊，團隊中的成員具有多樣性的技能。單塊應用架構根據技能劃分團隊。

關注產品而非專案

專案模式：當專案啟動後，企業或組織根據不通過的技能資源池中抽取相關的資源，組成團隊並完成專案，

單塊架構應用大部分是基於專案模式構建，其弊端如下：

• 團隊成員缺乏主人翁精神；
• 難以制定有效的獎懲機制；
• 團隊成員缺乏產品成就感。

微服務架構提倡的是採用產品模式構建，即讓團隊負責整個服務的生命週期，從服務的分析、開發、測試、部署、運維，所有成員的個人目標和團隊目標一致，都是為了更有效、高效、以可持續性發展的方式為消費者提供服務。最終目標是通過多個服務的協調、組合實現產品的功能，以及傳遞價值。

技術多樣性

傳統的單塊應用架構，傾向於採用統一的技術皮平臺或方案解決問題。

微服務架構中，提倡針對不同的業務特徵選擇合適的技術方案，有針對性地解決具體的業務問題。

業務資料獨立

傳統的單塊應用架構，多采用統一的資料儲存平臺來儲存所有資料。隨著業務快速發展，需求不斷變化，資料變得複雜難以管理，同時隨著應用系統的業務邏輯不斷更新和發展，資料庫不僅承擔著資料儲存的作用，還承擔著不同系統之間的繼承作用。

傳統的資料庫大多是關係型資料庫，儲存的資訊以結構化資訊為主，但隨著網際網路的快速發展，其維護成本會越來越高。

微服務架構提倡服務自主管理其相關的業務資料，這樣的優勢在於：

• 能隨著業務發展，提供業務資料介面整合，而不是以資料庫的方式同其他服務整合；
• 能隨著業務發展，選擇更合適的工具管理或者遷移業務理資料。

基礎服務自動化

傳統單塊架構應用只需要部署一次就能上線。而微服務架構將應用分為多個小的服務，需要對每個服務分別部署，此外每個服務都需要部署帶來的健康監控、錯誤回滾等，這會導致部署和運維的成本隨著服務的增多呈指數級增長。

因此微服務需要更穩定的基礎設定自動化機制，能夠建立執行環境、安裝依賴、部署應用。

演進式架構

微服務不是銀彈

微服務的優勢性在於獨立性、單一職責、技術多樣性。此外微服務的實施也會推動基礎設施自動化以及DevOps文化在團隊中的發展，有利於構建全功能的團隊。

微服務在實施的過程中需要考慮如下因素：

• 分散式系統的複雜度
• 運維成本
• 部署自動化
• DevOps與組織架構
• 服務間依賴測試
• 服務間依賴管理