微服務是什麼？帶你簡單瞭解微服務
By: fly_zhyu-CSDN
微服務是一種架構風格，一個大型複雜軟體應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是鬆耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。在所有情況下，每個任務代表著一個小的業務能力。
微服務的概念源於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構建。再如在某微服務應用中，可替代性模組化設計的基本原則，在實施後發現某兩個微服務經常必須同時更新，則這很可能意味著應將其合併為一個微服務。
    哪些應用會從微服務收益 ？
10. 記錄型系統(System of Record)將從微服務方法中獲益最多。例如可將大型應用按相對獨立的業務功能分解成若干個微服務實現。
11. 互動型系統(System of Engagement)也將受益於微服務方法，例如渠道應用可以應用“後端服務前端”的模式實現。
12. 分析型系統(System of Insight)則可能對微服務受益不多。其他架構模式如管道及過濾模式可能更適用於分析型系統。
     微服務架構的優點：
13. 每個服務都比較簡單，只關注於一個業務功能。
14. 微服務架構方式是鬆耦合的，可以提供更高的靈活性。
15. 微服務可通過最佳及最合適的不同的程式語言與工具進行開發，能夠做到有的放矢地解決針對性問題。
16. 每個微服務可由不同團隊獨立開發，互不影響，加快推出市場的速度。
17. 微服務架構是持續交付(CD)的巨大推動力，允許在頻繁釋出不同服務的同時保持系統其他部分的可用性和穩定性。
     微服務架構的缺點：
    微服務的一些想法在實踐上是好的，但當整體實現時也會呈現出其複雜性。
18. 運維開銷及成本增加：整體應用可能只需部署至一小片應用服務區叢集，而微服務架構可能變成需要構建/測試/部署/執行數十個獨立的服務，並可能需要支援多種語言和環境。這導致一個整體式系統如果由20個微服務組成，可能需要40~60個程序。
19. 必須有堅實的DevOps開發運維一體化技能：開發人員需要熟知運維與投產環境，開發人員也需要掌握必要的資料儲存技術如NoSQL，具有較強DevOps技能的人員比較稀缺，會帶來招聘人才方面的挑戰。
20. 隱式介面及介面匹配問題：把系統分為多個協作元件後會產生新的介面，這意味著簡單的交叉變化可能需要改變許多元件，並需協調一起釋出。在實際環境中，一個新品釋出可能被迫同時釋出大量服務，由於整合點的大量增加，微服務架構會有更高的釋出風險。
21. 程式碼重複：某些底層功能需要被多個服務所用，為了避免將“同步耦合引入到系統中”，有時需要向不同服務新增一些程式碼，這就會導致程式碼重複。
22. 分散式系統的複雜性：作為一種分散式系統，微服務引入了複雜性和其他若干問題，例如網路延遲、容錯性、訊息序列化、不可靠的網路、非同步機制、版本化、差異化的工作負載等，開發人員需要考慮以上的分散式系統問題。
23. 非同步機制：微服務往往使用非同步程式設計、訊息與並行機制，如果應用存在跨微服務的事務性處理，其實現機制會變得複雜化。
24. 可測性的挑戰：在動態環境下服務間的互動會產生非常微妙的行為，難以視覺化及全面測試。經典微服務往往不太重視測試，更多的是通過監控發現生產環境的異常，進而快速回滾或採取其他必要的行動。但對於特別在意風險規避監管或投產環境錯誤會產生顯著影響的場景下需要特別注意。
    想了解更多微服務知識，歡迎登陸華為雲學院（https://edu.huaweicloud.com/courses/）
    微服務精品課程免費學！