轉載自??為什么選擇微服務架構？如何取舍？

微服務是什么 ??? ? ? ? ? ?

微服務是一種架構風格，一個大型復雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注于完成一件任務并很好地完成該任務。在所有情況下，每個任務代表著一個小的業務能力。

微服務的概念源于2014年3月Martin Fowler所寫的一篇文章“Microservices”。

?盡管“微服務”這種架構風格沒有精確的定義，但其具有一些共同的特性，如圍繞業務能力組織服務、自動化部署、智能端點、對語言及數據的“去集中化”控制等等。

微服務架構的思考是從與整體應用對比而產生的。

其中，對應用組件封裝的方式是整體架構與微服務架構的主要差異，微服務架構將相關聯的業務邏輯及數據放在一起形成獨立的邊界，其目的是能在不影響其他應用組件(微服務)的情況下更快地交付并推出市場。

?

為什么需要微服務架構? ?

傳統IT架構的問題

“微服務”架構是近期軟件應用領域非常熱門的概念。讓我們先來看看傳統IT架構面臨的一些問題：

使用傳統的整體式架構(Monolithic Architecture)應用開發系統，如CRM、ERP等大型應用，隨著新需求的不斷增加，企業更新和修復大型整體式應用變得越來越困難；

隨著移動互聯網的發展，企業被迫將其應用遷移至現代化UI界面架構以便能兼容移動設備，這要求企業能實現應用功能的快速上線；

許多企業在SOA投資中得到的回報有限，SOA可以通過標準化服務接口實現能力的重用，但對于快速變化的需求，受到整體式應用的限制，有時候顯得力不從心；

新應用的出現

隨著應用云化的日益普及，生于云端的應用具有與傳統IT不同的技術基因和開發運維模式。

此外，從技術方面看，云計算及互聯網公司大量開源輕量級技術不停涌現并日漸成熟：

互聯網/內聯網/網絡更加成熟；

輕量級運行時技術的出現(node.js, WAS Liberty等)；

新的方法與工具(Agile, DevOps, TDD, CI, XP, Puppet, Chef…)；

新的輕量級協議(RESTful API接口, 輕量級消息機制)；

簡化的基礎設施：操作系統虛擬化(hypervisors), 容器化(e.g. Docker), 基礎設施即服務 (IaaS), 工作負載虛擬化(Kubernetes,Spark…)等；

服務平臺化(PaaS)： 云服務平臺上具有自動縮放、工作負載管理、SLA 管理、消息機制、緩存、構建管理等各種按需使用的服務；

新的可替代數據持久化模型：如NoSQL, MapReduce, BASE, CQRS等；

標準化代碼管理：如Github等。

這一切都催生了新的架構設計風格 – 微服務架構的出現。

微服務通用特性?

根據MartinFowler的分析，微服務架構有以下的一些通用特性，但并非所有微服務架構應用都必須具備所有這些特性：

1.組件化

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

2.跨功能

圍繞業務能力組織服務(Organizedaround Business Capabilities)：微服務架構采取以業務能力為出發點組織服務的策略，因此微服務團隊的組織結構必須是跨功能的（如：既管應用，也管數據庫）、強搭配的DevOps開發運維一體化團隊，通常這些團隊不會太大（如：亞馬遜的“Two pizzateam”- 不超過12人）。

?

3.產品模式

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

4.扁平化

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

5.去中心化

去中心化治理

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

去中心化數據管理

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

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

6.故障處理設計

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

7.演進式設計

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

?

微服務常見誤解?? ? ? ? ? ?

一些比較概念的澄清

在同一范疇內比較才有意義：

微服務架構 vs. SOA– 兩者都是架構風格范疇，但其關注領域與涉及范圍不同。SOA更關注企業規模范圍，微服務架構則更關注應用規模范圍。

微服務組件 vs. 服務組件 – 兩者都是描述業務功能的具體實現，其區別在于粒度不同，此外還有在可管理性、靈活性上的差異。

概念混淆的不恰當比較

微服務 vs. SOA – 不恰當的比較。微服務是組件范疇，而SOA是一種架構設計風格。因此應該比較的是微服務架構與SOA。

微服務 vs. API – 不恰當的比較。 API是接口，是業務功能暴露的一種機制。微服務架構是用于實施業務功能的組件架構。因此直接比較它們是沒有意義的。

微服務 vs. 服務– 不恰當的比較?！胺铡痹诓煌膱鼍跋掠胁煌暮x，需要進一步澄清其描述的語境，是指服務實施、服務暴露、服務定義還是其

他？微服務亦是如此，需要有特定語境才可判斷比較是否有意義。

收益應用?? ? ? ? ? ?

哪些應用會從微服務收益 ？

記錄型系統(System of Record)將從微服務方法中獲益最多。例如可將大型應用按相對獨立的業務功能分解成若干個微服務實現。

交互型系統(System of Engagement)也將受益于微服務方法，例如渠道應用可以應用“后端服務前端”的模式實現。

分析型系統(System of Insight)則可能對微服務受益不多。其他架構模式如管道及過濾模式可能更適用于分析型系統。

?

微服務架構的優點? ??

1.每個服務都比較簡單，只關注于一個業務功能。

2.微服務架構方式是松耦合的，可以提供更高的靈活性。

3.微服務可通過最佳及最合適的不同的編程語言與工具進行開發，能夠做到有的放矢地解決針對性問題。

4.每個微服務可由不同團隊獨立開發，互不影響，加快推出市場的速度。

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

?

微服務架構的缺點?? ? ? ? ? ?

微服務的一些想法在實踐上是好的，但當整體實現時也會呈現出其復雜性。

缺點一

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

缺點二

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

隱式接口及接口匹配問題：把系統分為多個協作組件后會產生新的接口，這意味著簡單的交叉變化可能需要改變許多組件，并需協調一起發布。在實際環境中，一個新品發布可能被迫同時發布大量服務，由于集成點的大量增加，微服務架構會有更高的發布風險。

缺點三

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

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

缺點四

異步機制：微服務往往使用異步編程、消息與并行機制，如果應用存在跨微服務的事務性處理，其實現機制會變得復雜化。

缺點五

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

?

關于微服務架構的取舍?

在合適的項目，合適的團隊，采用微服務架構收益會大于成本。

微服務架構有很多吸引人的地方，但在擁抱微服務之前，也需要認清它所帶來的挑戰。

需要避免為了“微服務”而“微服務”。

微服務架構引入策略 – 對傳統企業而言，開始時可以考慮引入部分合適的微服務架構原則對已有系統進行改造或新建微服務應用，逐步探索及積累微服務架構經驗，而非全盤實施微服務架構。

總結

以上是生活随笔為你收集整理的为什么选择微服务架构？如何取舍？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。