微服務架構介紹及實踐

微服務現在是一個很火的概念，尤其是搞IT的大多數都對其有所瞭解。

到底火到什麼程度呢？2016年有一個統計說，兩千家企業裡，30%在使用微服務，15%在實驗開發和測試微服務架構，24%在學習微服務準備轉型，只有剩下的30%的企業沒有使用微服務。

微服務到底有什麼好呢？微服務在2013年才被提出，短短几年就有這麼快速的發展。

微服務架構能夠實現由小型自主服務組成一個整體應用，各個組成部分之間是鬆耦合的，複雜性低，各個部分可以獨立部署，修復bug或者引入新特性更容易，能夠獨立擴充套件，不同技術棧之間可以使用不同框架、不同版本庫甚至不同的作業系統平臺。

下面就自己對微服務架構的一些理解及網路上的一些資料收集，對其進行了一個漫談式的彙總,以此與各位看官共勉。

目錄：

1、概要介紹
2、與傳統開發模式、SOA的區別
3、特性
4、優點
5、缺點
6、微服務框架應具備的功能
7、實踐

下面基於自己的理解，系統性的漫談了下微服務架構。

在此基礎上基於Angular、Typescript、.Net(WCF)技術棧，一體化的打造了一套輕量級的微服務研發框架CFCFrame，目前已經開源。

框架具體應用可參考：http://www.codefc.cn。

框架應用交流QQ群：706224870，群檔案裡有相關技術點的例項原始碼，供大家參考

GitHub開源地址：https://github.com/mqg007/CFCFrame

學習資源請參考：http://www.cnblogs.com/maotou/

一、概要介紹

微服務定義：
微服務是指開發一個單個小型的但有業務功能的服務，每個服務都有自己的處理和輕量通訊機制，可以部署在單個或多個伺服器上。
微服務也指一種種鬆耦合的、有一定的有界上下文的面向服務架構。也就是說，如果每個服務都要同時修改，那麼它們就不是微服務，因為它們緊耦合在一起；
如果你需要掌握一個服務太多的上下文場景使用條件，那麼它就是一個有上下文邊界的服務，這個定義來自DDD領域驅動設計。

微服務架構：
微服務架構（Microservice Architecture）是一種架構概念，旨在通過將功能分解到各個離散的服務中以實現對解決方案的解耦。它的主要作用是將功能分解到離散的各個服務當中，從而降低系統的耦合性，並提供更加靈活的服務支援。

微服務的目的：
微服務的目的是有效的拆分應用，實現敏捷開發和部署。

關於微服務的一個形象表達見下圖：

X軸：執行多個負載均衡器之後的執行例項

Y軸：將應用進一步分解為微服務（分庫）

Z軸：大資料量時，將服務分割槽（分表）

二、與傳統開發模式的區別

a、微服務 vs SOA

SOA喜歡重用(通過ESB整合系統)，微服務喜歡重寫

SOA喜歡水平服務，微服務喜歡垂直服務

SOA喜歡自上而下，微服務喜歡自下而上

其中：SOA更關注企業規模範圍，微服務架構則更關注應用規模範圍

b、微服務vs單體開發

兩者比較重要的不同是元件的服務邊界：

單體開發:通常注重的是業務邏輯及UI，不整合資料，依賴於主服務程式，不能獨立部署。整個應用整體打包部署。

微服務元件：通常注重的是UI、業務邏輯、資料集成於一體，可以獨立部署。

三、特性
1、元件化(Componentizationvia Services)：
微服務架構中將元件定義為可被獨立替換和升級的軟體單元，在應用架構設計中通過將整體應用切分成可獨立部署及升級的微服務方式進行元件化設計。

2、圍繞業務能力組織服務(Organizedaround Business Capabilities)：
微服務架構採取以業務能力為出發點組織服務的策略，因此微服務團隊的組織結構必須是跨功能的（如：既管應用，也管資料庫）、強搭配的DevOps開發運維一體化團隊。

3、產品而非專案模式(Productsnot Projects)：
傳統的應用模式是一個團隊以專案模式開發完整的應用，開發完成後就交付給運維團隊負責維護；微服務架構則倡導一個團隊應該如開發產品般負責一個“微服務”完整的生命週期，倡導“誰開發，
誰運營”的開發運維一體化方法。

4、智慧端點與管道扁平化(Smartendpoints and dumb pipes)：
微服務架構主張將元件間通訊的相關業務邏輯/智慧放在元件端點側而非放在通訊元件中，通訊機制或元件應該儘量簡單及鬆耦合。RESTful HTTP協議和僅提供訊息路由功能的輕量級非同步機制是微服務架構中最常用的通訊機制。

5、“去中心化”治理(DecentralizedGovernance)：
整體式應用往往傾向於採用單一技術平臺，微服務架構則鼓勵使用合適的工具完成各自的任務，每個微服務可以考慮選用最佳工具完成(如不同的程式語言)。
微服務的技術標準傾向於尋找其他開發者已成功驗證解決類似問題的技術。

6、“去中心化”資料管理(DecentralizedData Management)：
微服務架構倡導採用多樣性持久化(PolyglotPersistence)的方法，讓每個微服務管理其自有資料庫，並允許不同微服務採用不同的資料持久化技術。

7、基礎設施自動化(InfrastructureAutomation)：雲化及自動化部署等技術極大地降低了微服務構建、部署和運維的難度，通過應用持續整合和持續交付等方法有助於達到加速推出市場的目的。

8、故障處理設計(Designfor failure)：微服務架構所帶來的一個後果是必須考慮每個服務的失敗容錯機制。因此，微服務非常重視建立架構及業務相關指標的實時監控和日誌機制。

9、演進式的設計(EvolutionaryDesign)：微服務應用更注重快速更新，因此係統的計會隨時間不斷變化及演進。微服務的設計受業務功能的生命週期等因素影響。
如某應用是整體式應用，但逐漸朝微應用架構方向演進，整體式應用仍是核心，但新功能將使用應用所提供的API構建。
再如在某微服務應用中，可替代性模組化設計的基本原則，在實施後發現某兩個微服務經常必須同時更新，則這很可能意味著應將其合併為一個微服務。

四、優點
1、複雜度可控：
將整體應用程式分解成一組服務，服務粒度按需可控，而每個服務是針對一個單一職責的業務能力的封裝，專注做好一件事情。

2、獨立開發和演化：
技術選型靈活，不受遺留系統技術約束。合適的業務問題選擇合適的技術可以獨立演化。服務與服務之間採取與語言無關的API進行整合。
開發人員可以自由選擇任何有用的技術，可以獨立的開發和演化所負責的服務，因為服務相對較小，使使用新技術重寫服務變得可能。

3、獨立部署：
每個微服務獨立的部署。開發者不再需要協調其它服務部署對本服務的影響。這種改變可以加快部署速度。UI團隊可以採用AB測試，快速的部署變化。微服務架構模式使得持續化部署成為可能。

4、獨立按需擴充套件：
每個服務獨立擴充套件。你可以根據每個服務的規模來部署滿足需求的規模。甚至於，你可以使用更適合於服務資源需求的硬體。
比如，你可以在EC2 Compute Optimized instances上部署CPU敏感的服務，而在EC2 memory-optimized instances上部署記憶體資料庫。

5、技術選型靈活：
微服務可通過最佳及最合適的不同的程式語言與工具進行開發，能夠做到有的放矢地解決針對性問題。

6、容錯及高可用：
通過負載均衡配置，可以實現微服務容錯。
微服務架構方式是鬆耦合的，可以提供更高的靈活性。

微服務架構是持續交付(CD)的巨大推動力，允許在頻繁釋出不同服務的同時保持系統其他部分的可用性和穩定性。

五、缺點
1、運維開銷及成本增加：
整體應用可能只需部署至一小片應用服務區叢集，而微服務架構可能變成需要構建/測試/部署/執行數十個獨立的服務，並可能需要支援多種語言和環境。這導致一個整體式系統如果由20個微服務組成，可能需要40~60個程序。

2、必須有堅實的DevOps開發運維一體化技能：
開發人員需要熟知運維與投產環境，開發人員也需要掌握必要的資料儲存技術如NoSQL，具有較強DevOps技能的人員比較稀缺，會帶來招聘人才方面的挑戰。

3、隱式介面及介面匹配問題：
把系統分為多個協作元件後會產生新的介面，這意味著簡單的交叉變化可能需要改變許多元件，並需協調一起釋出。
在實際環境中，一個新品釋出可能被迫同時釋出大量服務，由於整合點的大量增加，微服務架構會有更高的釋出風險。

4、程式碼重複：
某些底層功能需要被多個服務所用，為了避免將“同步耦合引入到系統中”，有時需要向不同服務新增一些程式碼，這就會導致程式碼重複。

5、分散式系統的複雜性：
作為一種分散式系統，微服務引入了複雜性和其他若干問題，例如跟蹤問題困難、網路延遲、容錯性、訊息序列化、不可靠的網路、非同步機制、版本化、差異化的工作負載等，
開發人員需要考慮以上的分散式系統問題。

6、非同步機制：
微服務往往使用非同步程式設計、訊息與並行機制，如果應用存在跨微服務的事務性處理，其實現機制會變得複雜化。

7、可測性的挑戰：
在動態環境下服務間的互動會產生非常微妙的行為，難以視覺化及全面測試。經典微服務往往不太重視測試，更多的是通過監控發現生產環境的異常，進而快速回滾或採取其他必要的行動。
但對於特別在意風險規避監管或投產環境錯誤會產生顯著影響的場景下需要特別注意。

8、數量大管理複雜：

當服務數量增加，管理服務的複雜度大幅提升，需要合理、科學的建立服務的註冊、發現、監控等機制。

六、微服務框架應具備的功能
1、API Gateway：
實現一個API閘道器作為所有客戶端的唯一入口。API閘道器有兩種方式來處理請求。有些請求被簡單地代理/路由到合適的服務上，其他的請求被轉給到一組服務
相比於提供普適的API，API閘道器根據不同的客戶端開放不同的API。比如，Netflix API閘道器執行著客戶端特定的介面卡程式碼，會向客戶端提供最適合其需求的API。
API閘道器也可以實現安全性，比如驗證客戶端是否被授權進行某請求。

2、負載均衡：
同時部署多套對等微服務和資料庫，科學規劃負載均衡演算法，支援在API Gateway層對請求進行分發處理。

3、認證和鑑權：
支援統一認證和鑑權機制，通過管理和應用Token來實現認證和鑑權。

4、日誌和審計：
框架一方面要記錄重要的框架層日誌、metrics和呼叫鏈資料，還要將日誌、metrics等介面暴露出來，讓業務層能根據需要記錄業務日誌資料。在執行環境中，所有日誌資料一般集中落地到企業後臺日誌系統，做進一步分析和處理

5、統一錯誤處理：
對於框架層和服務的內部異常，如果框架層能夠統一處理並記錄日誌，對服務監控和快速問題定位有很大幫助。

6、REST/RPC和序列化（通訊方式）：
框架層要支援將業務邏輯以HTTP/REST或者RPC方式暴露出來，HTTP/REST是當前主流API暴露方式，在效能要求高的場合則可採用Binary/RPC方式。
針對當前多樣化的裝置型別(瀏覽器、普通PC、無線裝置等)，框架層要支援可定製的序列化機制，例如，對瀏覽器，框架支援輸出Ajax友好的JSON訊息格式，而對無線裝置上的Native App，框架支援輸出效能高的Binary訊息格式。

7、配置：
除了支援普通配置檔案方式的配置，框架層還可整合動態執行時配置，能夠在執行時針對不同環境動態調整服務的引數和配置。

8、安全處理封裝：
安全和訪問控制邏輯可以在框架層統一進行封裝，可做成外掛形式，具體業務服務根據需要載入相關安全外掛。

9、訊息匯流排：
輕量級的MQ或HTTP。

10、監控和告警：
主要是監控每個服務的狀態，必要時產生告警

11、分散式管理(包括微服務和資料庫)：
對微服務和資料庫均支援分散式處理，微服務和資料庫之間支援多對多組合應用。

12、微服務CI/CD流水線：
支援持續整合和持續部署，能夠到DevOps一體化運維標準。

13、服務治理：
按需伸縮：部署與監控運維成本 
獨立部署：機器數量與部署成本 
業務獨立：服務依賴、治理，版本管理、事務處理 
技術多樣性：環境部署成本、約定成本
執行狀態治理：監控、限流、SLA、LB、日誌分析 
部署：快速、複製、擴容；單機開發 
呼叫：安全、容錯、服務降級、呼叫延時

14、服務註冊及發現：
提供服務註冊及發現相應管理功能。
服務註冊（客戶端發現）：
提供統一服務註冊中心，可以對所有服務進行跟蹤及管理。



服務發現：



15、管理介面：
框架整合管理介面，一方面可以線上檢視框架和服務內部狀態，同時還可以動態調整內部狀態，對除錯、監控和管理能提供快速反饋。Spring Boot微框架的Actuator模組就是一個強大的管理介面。

16、限流和容錯：
框架整合限流容錯元件，能夠在執行時自動限流和容錯，保護服務，如果進一步和動態配置相結合，還可以實現動態限流和熔斷。

17、事件排程機制：處理事件機制。

18、資源管理：
提供相關的資源管理功能。如：底層的虛擬機器，物理機和網路管理。

19、統一程式碼框架：
提供統一框架，支援多種語言的運用。

20、統一服務構建和打包：
提供統一的管理機制對微服務進行構建和打包。使微服務的構建和打包標準化進行，也便於微服務間的互動。

21、統一服務測試：
提供統一的測試機制及工具，遮蔽服務內部的差異，可對微服務進行標準化測試。

22、服務依賴關係管理：
提供統一的管理機制及功能，採用科學、合理的管理策略來管理眾多服務及相互依賴。例如分組、分層等。

23、統一問題跟蹤除錯框架，俗稱呼叫鏈：
提供統一跟蹤除錯微服務的工具，可以方便的對呼叫鏈上的微服務進行跟蹤和除錯。

24、灰度釋出：
支援產品釋出的平滑演進，逐步擴大覆蓋範圍，通常也叫灰度放量。

25、藍綠部署：
支援新舊版本的線上切換。

七、實踐

具體參見: http://www.codefc.cn