微服務架構介紹及開源框架

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

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

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

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

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

目錄：

一、概要介紹
二、與傳統開發模式、SOA的區別
三、特性
四、優勢
五、缺點
六、微服務框架應具有的功能
七、實踐

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

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

具體可參考：https://github.com/mqg007/CFCFrame。

 

1、概要介紹

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

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

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

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

 

X軸：運行多個負載均衡器以後的運行實例

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

Z軸：大數據量時，將服務分區（分表）

 

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

a、微服務 vs SOA

SOA喜歡重用(經過ESB集成系統)，微服務喜歡重寫

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

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

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

b、微服務vs單體開發

 

 

二者比較重要的不一樣是組件的服務邊界：

單體開發:一般注重的是業務邏輯及UI，不集成數據，依賴於主服務程序，不能獨立部署。整個應用總體打包部署。

微服務組件：一般注重的是UI、業務邏輯、數據集成於一體，能夠獨立部署。

3、特性
一、組件化(Componentizationvia Services)：
微服務架構中將組件定義爲可被獨立替換和升級的軟件單元，在應用架構設計中經過將總體應用切分紅可獨立部署及升級的微服務方式進行組件化設計。

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

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

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

五、「去中心化」治理(DecentralizedGovernance)：
總體式應用每每傾向於採用單一技術平臺，微服務架構則鼓勵使用合適的工具完成各自的任務，每一個微服務能夠考慮選用最佳工具完成(如不一樣的編程語言)。
微服務的技術標準傾向於尋找其餘開發者已成功驗證解決相似問題的技術。

六、「去中心化」數據管理(DecentralizedData Management)：
微服務架構倡導採用多樣性持久化(PolyglotPersistence)的方法，讓每一個微服務管理其自有數據庫，並容許不一樣微服務採用不一樣的數據持久化技術。

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

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

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

4、優勢
一、複雜度可控：
將總體應用程序分解成一組服務，服務粒度按需可控，而每一個服務是針對一個單一職責的業務能力的封裝，專一作好一件事情。

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

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

四、獨立按需擴展：
每一個服務獨立擴展。你能夠根據每一個服務的規模來部署知足需求的規模。甚至於，你可使用更適合於服務資源需求的硬件。
好比，你能夠在EC2 Compute Optimized instances上部署CPU敏感的服務，而在EC2 memory-optimized instances上部署內存數據庫。

五、技術選型靈活：
微服務可經過最佳及最合適的不一樣的編程語言與工具進行開發，可以作到有的放矢地解決針對性問題。

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

微服務架構是持續交付(CD)的巨大推進力，容許在頻繁發佈不一樣服務的同時保持系統其餘部分的可用性和穩定性。

5、缺點
一、運維開銷及成本增長：
總體應用可能只需部署至一小片應用服務區集羣，而微服務架構可能變成須要構建/測試/部署/運行數十個獨立的服務，並可能須要支持多種語言和環境。這致使一個總體式系統若是由20個微服務組成，可能須要40~60個進程。

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

三、隱式接口及接口匹配問題：
把系統分爲多個協做組件後會產生新的接口，這意味着簡單的交叉變化可能須要改變許多組件，並需協調一塊兒發佈。
在實際環境中，一個新品發佈可能被迫同時發佈大量服務，因爲集成點的大量增長，微服務架構會有更高的發佈風險。

四、代碼重複：
某些底層功能須要被多個服務所用，爲了不將「同步耦合引入到系統中」，有時須要向不一樣服務添加一些代碼，這就會致使代碼重複。

五、分佈式系統的複雜性：
做爲一種分佈式系統，微服務引入了複雜性和其餘若干問題，例如跟蹤問題困難、網絡延遲、容錯性、消息序列化、不可靠的網絡、異步機制、版本化、差別化的工做負載等，
開發人員須要考慮以上的分佈式系統問題。

六、異步機制：
微服務每每使用異步編程、消息與並行機制，若是應用存在跨微服務的事務性處理，其實現機制會變得複雜化。

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

八、數量大管理複雜：

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

6、微服務框架應具有的功能
一、API Gateway：
實現一個API網關做爲全部客戶端的惟一入口。API網關有兩種方式來處理請求。有些請求被簡單地代理/路由到合適的服務上，其餘的請求被轉給到一組服務
相比於提供普適的API，API網關根據不一樣的客戶端開放不一樣的API。好比，Netflix API網關運行着客戶端特定的適配器代碼，會向客戶端提供最適合其需求的API。
API網關也能夠實現安全性，好比驗證客戶端是否被受權進行某請求。

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

三、認證和鑑權：
支持統一認證和鑑權機制，經過管理和應用Token來實現認證和鑑權。

四、日誌和審計：
框架一方面要記錄重要的框架層日誌、metrics和調用鏈數據，還要將日誌、metrics等接口暴露出來，讓業務層能根據須要記錄業務日誌數據。在運行環境中，全部日誌數據通常集中落地到企業後臺日誌系統，作進一步分析和處理

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

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

七、配置：
除了支持普通配置文件方式的配置，框架層還可集成動態運行時配置，可以在運行時針對不一樣環境動態調整服務的參數和配置。

八、安全處理封裝：
安全和訪問控制邏輯能夠在框架層統一進行封裝，可作成插件形式，具體業務服務根據須要加載相關安全插件。

九、消息總線：
輕量級的MQ或HTTP。

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

十一、分佈式管理(包括微服務和數據庫)：
對微服務和數據庫均支持分佈式處理，微服務和數據庫之間支持多對多組合應用。

十二、微服務CI/CD流水線：
支持持續集成和持續部署，可以到DevOps一體化運維標準。

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

1四、服務註冊及發現：
提供服務註冊及發現相應管理功能。
服務註冊（客戶端發現）：
提供統一服務註冊中心，能夠對全部服務進行跟蹤及管理。



服務發現：



1五、管理接口：
框架集成管理接口，一方面能夠在線查看框架和服務內部狀態，同時還能夠動態調整內部狀態，對調試、監控和管理能提供快速反饋。Spring Boot微框架的Actuator模塊就是一個強大的管理接口。

1六、限流和容錯：
框架集成限流容錯組件，可以在運行時自動限流和容錯，保護服務，若是進一步和動態配置相結合，還能夠實現動態限流和熔斷。

1七、事件調度機制：處理事件機制。

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

1九、統一代碼框架：
提供統一框架，支持多種語言的運用。

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

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

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

2三、統一問題跟蹤調試框架，俗稱調用鏈：
提供統一跟蹤調試微服務的工具，能夠方便的對調用鏈上的微服務進行跟蹤和調試。

2四、灰度發佈：
支持產品發佈的平滑演進，逐步擴大覆蓋範圍，一般也叫灰度放量。

2五、藍綠部署：
支持新舊版本的在線切換。

7、實踐

具體參見: https://github.com/mqg007/CFCFrame

 

********轉載：https://www.cnblogs.com/maotou/p/CodeFC.html