大家好，歡迎來到萬貓學社，跟我一起學，你也能成為微服務專家。

沒有「銀彈」

在一些電影中，「銀彈」被視作能迅速殺死狼人的武器，是殺死狼人的靈丹妙藥。「銀彈」常被比喻為解決複雜問題的良方或高招。

由於軟體的複雜性本質，而使真正的「銀彈」並不存在。同樣的，架構設計是一門權衡、取捨的藝術，沒有十全十美的架構，微服務架構為我們帶來了如：可延伸性、靈活性等諸多優點。我們收穫這些好處的同時，也一定會帶來一些新的問題與不足。當我們完全瞭解了微服務的優勢和不足，就可以在應用它的時候揚長避短。

微服務的優勢

微服務架構有很多重要的優勢，我們來主要看以下幾個：

複雜問題簡單化

首先就是，複雜問題簡單化。微服務架構能有效解決系統複雜性的問題，將大型單體應用拆解為一組服務，雖然功能總量不變，但應用已被分解為可實現、可管理的模組或服務。

高內聚低耦合

微服務架構中，每個服務都可以由專注於此服務的團隊獨立開發。服務間定義了明確的API邊界，責任劃分清晰，同時內部設計和實現細節都被隔離開，相互之間沒有強依賴。

獨立自治

各服務可以各自獨立的發展自己的系統，選擇合適的技術棧和研發模式，包括開發語言、工具以及中介軟體等技術，這也有助於試驗和引入更先進和創新的技術。

從一些邊緣服務開始嘗試，技術、工具、中介軟體、研發模式，孵化成熟以後，再逐步大範圍推廣，實現技術和研發能力的持續更新換代，讓研發組織保持長期的優勢和活力，充分獲得技術發展的紅利。

持續交付

服務範例獨立部署，也便於利用自動化測試和自動化部署來加速功能的迭代，配合 CI/CD 等基礎設施，實現業務功能的持續交付，保障研發能夠緊跟業務發展變化的節奏。

靈活擴充套件

每個服務都可獨立擴充套件。既可以按照服務的實際負載進行區域性的擴充套件伸縮，比如擴容某個服務的範例數；或者按照服務要求的設定、容量等條件進行調整資源使用，比如我們可以在計算優化範例上部署CPU密集型服務，在記憶體優化範例上部署記憶體資料型服務。

一句話概括來說，微服務架構支援快速、頻繁和可靠地交付大型、複雜的應用程式。它還使組織能夠不斷演化發展其技術堆疊。

文章持續更新，微信搜尋「萬貓學社」第一時間閱讀，關注後回覆「電子書」，免費獲取12本必讀技術書籍。

微服務的不足

微服務架構同樣也會面臨一些問題和不足，我們來主要看以下幾個：

服務拆分

微服務強調了服務大小，但實際上這並沒有一個統一的標準。業務邏輯應該按照什麼規則劃分為微服務，這本身就是一個經驗工程。

雖然建立小型服務是微服務架構崇尚的，但要記住，微服務是達到目的的手段，而不是目標。微服務的目標是充分分解應用程式，以促應用的持續迭代和演進。

分散式複雜度

開發人員需要基於RPC或者訊息實現呼叫和通訊，任何一次遠端呼叫都有可能失敗，如何保障服務之間的可靠互動。

資料一致性，非中心化的架構下，由於CAP原理的約束，強一致性的要求可能需要轉向最終一致性方面考慮。

分散式場景下的資源競爭、主從選舉、狀態同步也是非常棘手的問題。

測試運維成本

對微服務進行整合測試，需要有相關服務的配合，部署對應的服務，很有可能是多個，甚至有可能存在級聯的關係。

微服務架構體系中服務治理的能力往往需要一系列基礎服務（比如註冊中心、設定中心、APM系統等等）提供支援，這無疑也是增加了運維的成本。

問題定位排查

微服務之間的拓撲關係十分複雜，一個請求可能跨越好幾個服務、中介軟體，出現業務bug或是線上問題時，排查或定位會很困難，需要有完善的機制和方案。

對於上面的問題，任何一個微服務開發人員都不能繞過去的，因此大部分的微服務產品都針對每一個問題提供了相應的元件來解決它們。

最後，感謝你這麼帥，還給我點贊。

微信公眾號：萬貓學社

微信掃描二維條碼

關注後回覆「電子書」

獲取12本必讀技術書籍