程序員修神之路--要想作好微服務架構，並不是易事！

菜菜哥，上次聽你講了微服務和SOA，明白了不少道理

看來面試用上了吧

呵呵，可是面試官問我微服務有什麼優勢和缺點...

看來還得給你詳細講一講微服務

概念

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

微服務是根據具體業務領域邊界劃分出來的能獨立運行的程序，而且能夠獨立部署，能夠根據業務量橫向擴展，修改不會影響其餘程序正常運行。簡單一句話：微服務是有必定邊界的有本身上下文的服務架構理念。

有點我就給菜菜哥你講講吧，看我講的如何

好呀，洗耳恭聽。

微服務優勢

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. 沒有自動化監控，每次故障定位都須要人工查幾十臺機器幾百個微服務的各類狀態和各類日誌文件。

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

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

微服務的重點不止在邊界的劃分，還有服務的治理。就像容器同樣，容器很重要，可是容器編排一樣重要。

哎呀，微服務原來有這麼多缺點，我再考慮要不要學呢？

整體來講，在適合微服務的場景下，仍是推薦使用微服務架構，在交付過程當中，優點仍是要大於劣勢的