什麽是微服務？

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

單體架構的應用一般有以下特點：

設計、開發、部署為一個單獨的單元。

會變得越來越復雜，最後導致維護、升級、新增功能變得異常困難

很難以敏捷研發模式進行開發和發布

部分更新，都需要重新部署整個應用

水平擴展：必須以應用為單位進行擴展，在資源需求有沖突時擴展變得比較困難（部分服務需要更多的計算資源，部分需要更多內存資源）

可用性：一個服務的不穩定會導致整個應用出問題

創新困難：很難引入新的技術和框架，所有的功能都構建在同質的框架之上

運維困難：變更或升級的影響分析困難，任何一個小修改都可能導致單體應用整體運行出現故障。

微服務設計

那我們在微服務中應該怎樣設計呢。以下是微服務的設計指南：

職責單一原則（Single Responsibility Principle）：把某一個微服務的功能聚焦在特定業務或者有限的範圍內會有助於敏捷開發和服務的發布。

設計階段就需要把業務範圍進行界定。

需要關心微服務的業務範圍，而不是服務的數量和規模盡量小。數量和規模需要依照業務功能而定。

於SOA不同，某個微服務的功能、操作和消息協議盡量簡單。

項目初期把服務的範圍制定相對寬泛，隨著深入，進一步重構服務，細分微服務是個很好的做法。

API-網關方式

API網關方式的核心要點是，所有的客戶端和消費端都通過統一的網關接入微服務，在網關層處理所有的非業務功能個。通常，網關也是提供REST/HTTP的訪問API。服務端通過API-GW註冊和管理服務。

所有的業務接口通過API網關暴露，是所有客戶端接口的唯一入口。微服務之間的通信也通過API網關。\

采用網關方式有如下優勢：

有能力為微服務接口提供網關層次的抽象。比如：微服務的接口可以各種各樣，在網關層，可以對外暴露統一的規範接口。

輕量的消息路由、格式轉換。

統一控制安全、監控、限流等非業務功能。

每個微服務會變得更加輕量，非業務功能個都在網關層統一處理，微服務只需要關註業務邏輯

目前，API網關方式應該是微服務架構中應用最廣泛的設計模式。

微服務架構的優點：

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

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

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

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

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

微服務架構的缺點：

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

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

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

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

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

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

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

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

微服務架構