微服務是根據具體業務領域邊界劃分出來的能獨立執行的程式，並且可以獨立部署，可以根據業務量橫向擴充套件，修改不會影響其他程式正常執行。簡單一句話：微服務是有一定邊界的有自己上下文的服務架構理念。

1. 微服務更容易的擴充套件，它基本上是獨立的。應對網際網路應用中大併發的系統可以做到自動彈性應對。

2. 每個微服務可以由不同的團隊，採用不同的技術棧開發，只要遵循約定的協議即可，每個微服務的修改不會影響到其他服務的正常執行。

3. 微服務的架構思想摒棄了中心化的架構風格，進一步降低了系統間的耦合度，無論是在開發階段或部署階段都是獨立的。

4. 微服務由於可以快速開發和交付，所以在新技術的接收能力上要遠遠高於其他系統，例如：將一個傳統的系統修改微服務可以快速上雲，可以快速採用k8s部署。

5. 每個微服務都遵循相同的協議標準，所以再團隊之間的溝通上可以減少很多不必要的麻煩。

微服務雖好，但也並非完美。

微服務從字面意思就可以知道強調服務的“微”，但是這個微的粒度，多數人都理解錯誤，有人說：微到不能再微是微服務劃分的理念。我不這樣認為，微服務的領域邊界是根據具體業務來劃分，過度的劃分，只會導致微服務的數量急劇增加，團隊的效率急劇下降。有的團隊只有5~6個人，然而卻拆分出幾十個微服務系統，平均每個人要維護5~10個微服務，這樣做給團隊帶來的只有負面效應。無論是開發，測試，還是運維都需要在多個微服務之間不停的切換。

當微服務上線之後，幾十個微服務需要啟動幾十個程序，在加入了負載均衡與訊息中介軟體後，程序的數量還會持續新增。運維與編排全部這些服務是個“令人望而卻步的任務”。

當微服務粒度過細，會造成程式碼複用度進一步降低，一些通用的程式碼你可能需要在多個服務間進行copy，如果某段程式碼有問題，你同時需要修改多個服務程式碼，當然同種語言可以使用程式碼共享庫來解決，但是在多語言的情況下是行不通的。

無論微服務怎麼樣劃分邊界，業務上無法避免在多個服務間的事務性操作。最簡單的下單場景：很多情況下訂單和使用者資產是不同的微服務，當用戶支付成功，扣除使用者資產和更改訂單狀態（還有減少商品庫存）應該是一個原子性操作，如果在以前的單體應用公用一個數據庫的情況下，用DB的事務很容易實現原子性操作，但是在微服務環境下，實現事務有一定的難度，尤其是當服務間採用非同步操作的時候，這就很複雜了，這要求我們得“管理好相關聯的ID以及分散式事務，將各種動作繫結在一起”。

服務劃分過細，單個服務的複雜度確實下降了，但整個系統的複雜度卻上升了，因為微服務將系統內的複雜度轉移為系統間的複雜度了。從理論的角度來計算，n 個服務的複雜度是n×(n-1)/2，整體系統的複雜度是隨著微服務數量的增加呈指數級增加的。下圖形象了說明了整體複雜度：

服務間的通訊都採用標準的Http或者Rpc協議，只要是通過網路的呼叫，就會耗費資源，就會花費更多的執行時間。如果一個請求需要順序的呼叫N層服務，那麼這個請求所花費的時間是不容忽視的，這在大併發的系統中是致命的效能損耗存在，系統的吞吐量會大幅下降。雖然增加硬體在一定程度上會緩解這種問題，但是卻在根本上解決不了問題，而且在成本上會大幅度上升。

另外，服務的呼叫鏈太長，定位系統問題很難。一個業務請求會經過N個微服務，任何一個服務有問題，都有可能會導致業務失敗。由於呼叫的微服務過多，而且異常有擴散的屬性，快速定位服務問題對於開發以及測試來說，是一件很複雜並且很難的事情。如下圖所示：

如果服務C發生故障，開發定位問題的時候需要從服務A開始追蹤，然後追蹤服務B，然後是服務C，如果呼叫鏈更長的話，還需要繼續追蹤。當定位到問題之後，可能已經過去了幾個小時，這在一些敏感的系統中是不允許的。如果服務的複雜性如下圖所示，該怎麼辦呢？

如果沒有相應的自動化系統進行支撐，都是靠人工去操作，那麼微服務不但達不到快速交付的目的，甚至還不如一個大而全的系統效率高。

1. 沒有自動化測試支撐，每次測試時需要測試大量介面。

2. 沒有自動化部署支撐，每次部署 6 ~ 7 個服務，幾十臺機器，運維人員敲 shell 命令逐臺部署，手都要敲麻。

3. 沒有自動化監控，每次故障定位都需要人工查幾十臺機器幾百個微服務的各種狀態和各種日誌檔案。

當服務的數量到達一定程度，假如如上圖所示，服務的治理難度就會被提上日程。當微服務的種類和數量越來越多，如果沒有微服務的治理系統去支撐，微服務的優勢就會變為劣勢，包括每個服務的註冊和發現，每個服務的部署，每個服務的隔離，甚至每個服務的路由。

如果還是人工去幹預這些，最終服務系統將會變的一片混亂，微服務推重的快速交付，橫向擴充套件等特性也將變的複雜。