解析微服務架構(一)：什麼是微服務

解析微服務架構系列文章將分幾篇描述微服務的定義、特色、應用場景、企業集成架構的演進以及微服務轉型思路和技術決策考慮等內容，並以IBM技術爲例介紹如何實現微服務架構轉型。

• 爲何須要微服務架構

「微服務」架構是近期軟件應用領域很是熱門的概念。讓咱們先來看看傳統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等。

 

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

 

• 什麼是微服務

微服務是一種架構風格，一個大型複雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是鬆耦合的。每一個微服務僅關注於完成一件任務並很好地完成該任務。在全部狀況下，每一個任務表明着一個小的業務能力。

    微服務的概念源於2014年3月Martin Fowler所寫的一篇文章「Microservices」(http://martinfowler.com/articles/microservices.html)。

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

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

 

   

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

 

• 微服務架構的一些通用特性

根據MartinFowler的分析，微服務架構有如下的一些通用特性，但並不是全部微服務架構應用都必須具有全部這些特性：

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

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

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. 在同一範疇內比較纔有意義：

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

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

2. 概念混淆的不恰當比較

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

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

   • 微服務 vs. 服務– 不恰當的比較。「服務」在不一樣的場景下有不一樣的含義，須要進一步澄清其描述的語境，是指服務實施、服務暴露、服務定義仍是其餘？微服務亦是如此，須要有特定語境纔可判斷比較是否有意義。

 

• 微服務架構與SOA架構的比較

 

將航班預訂應用劃分爲預訂航班、時間表查詢、計算票價、分配座位、管理獎勵、更新客戶、調整庫存七個微服務實施。

 

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

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

2. 交互型系統(System of Engagement)也將受益於微服務方法，例如渠道應用能夠應用「後端服務前端」的模式實現。

3. 分析型系統(System of Insight)則可能對微服務受益很少。其餘架構模式如管道及過濾模式可能更適用於分析型系統。

 

• 微服務架構的優勢：

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

2. 微服務架構方式是鬆耦合的，能夠提供更高的靈活性。

3. 微服務可經過最佳及最合適的不一樣的編程語言與工具進行開發，可以作到有的放矢地解決針對性問題。

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

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

 

• 微服務架構的缺點：

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

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

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

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

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

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

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

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

 

• 關於微服務架構的取捨

1. 在合適的項目，合適的團隊，採用微服務架構收益會大於成本。

2. 微服務架構有不少吸引人的地方，但在擁抱微服務以前，也須要認清它所帶來的挑戰。

3. 須要避免爲了「微服務」而「微服務」。

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

 

   下一篇微服務文章將介紹融入微服務的企業集成架構的演進，並介紹交互式系統的微服務模式及技術決策的例子。

 

——本文轉載自 IBM 雲計算華南團隊（微信號：IBMCloud_SC）