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

解析微服務架構系列文章將分幾篇描述微服務的定義、特點、應用場景、企業整合架構的演進以及微服務轉型思路和技術決策考慮等內容，並以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. 微服務架構引入策略 – 對傳統企業而言，開始時可以考慮引入部分合適的微服務架構原則對已有系統進行改造或新建微服務應用，逐步探索及積累微服務架構經驗，而非全盤實施微服務架構。