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

• 為什么需要微服務架構

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

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

• 隨著移動互聯(lián)網的發(fā)展，企業(yè)被迫將其應用遷移至現(xiàn)代化UI界面架構以便能兼容移動設備，這要求企業(yè)能實現(xiàn)應用功能的快速上線；

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

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

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

• 互聯(lián)網/內聯(lián)網/網絡更加成熟；

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

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

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

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

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

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

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

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

• 什么是微服務

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

    微服務的概念源于2014年3月Martin Fowler所寫的一篇文章“Microservices”(http:///articles/microservices.html)。

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

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

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

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

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

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

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

    

    

    

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

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

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

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

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

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

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

• 微服務的一些常見誤解

關于一些比較概念的澄清：

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

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

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

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

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

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

   • 微服務 vs. 服務– 不恰當的比較?！胺铡痹诓煌膱鼍跋掠胁煌暮x，需要進一步澄清其描述的語境，是指服務實施、服務暴露、服務定義還是其他？微服務亦是如此，需要有特定語境才可判斷比較是否有意義。

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

• 一個簡單的微服務應用例子：航班預訂應用

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

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

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

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

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

• 微服務架構的優(yōu)點：

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

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

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

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

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

• 微服務架構的缺點：

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

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

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

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

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

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

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

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

• 關于微服務架構的取舍

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

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

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

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