1. 程式人生 > >微服務架構潔介紹及開源框架

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

周期 動態配置 交互 rip Y軸 分布式 基本原則 PE 物理

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

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

微服務到底有什麽好呢?微服務在2013年才被提出,短短幾年就有這麽快速的發展。

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

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

目錄:

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

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

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

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

一、概要介紹

微服務定義:
微服務是指開發一個單個小型的但有業務功能的服務,每個服務都有自己的處理和輕量通訊機制,可以部署在單個或多個服務器上。
微服務也指一種種松耦合的、有一定的有界上下文的面向服務架構。也就是說,如果每個服務都要同時修改,那麽它們就不是微服務,因為它們緊耦合在一起;
如果你需要掌握一個服務太多的上下文場景使用條件,那麽它就是一個有上下文邊界的服務,這個定義來自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、藍綠部署:
支持新舊版本的在線切換。

七、實踐

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

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