有人說：使用多個獨立的微服務組合成一個複雜的業務系統。如此的話，業務系統整體的複雜度並沒有降低。如果極限情況下，每個public函式都是一個獨立執行的服務，如此一來反倒是增加系統的複雜度。如此看來，微服務只不過是解決了部分功能的擴充套件性的問題。和SOA架構或者monolic相比，並沒有根本性的改變。

事實並非如此。

分散式意味著複雜性的挑戰，以靜止的觀點來看，也就是系統長期沒什麼大變化這種情況，採用微服務架構通常會增加系統整體的複雜度，得不償失。

然而有個詞叫做“架構腐化”，系統不可能靜止不動，隨著業務的成長，市場的變化，系統總要不斷增加新的能力，時間長了，最初簡單高效的架構，往往就會變得極其複雜，臃腫不堪，即便最初的規範、分層都合理了，可擴充套件性、可用性、效能帶來的複雜性也是難以避免的，祖傳程式碼牽一髮而動全身，改一行修半年該有多可怕。這也是熵增原理的一種體現。

而採用微服務架構，邊界和職責明確了，模組高內聚低耦合，系統熵增就可以變慢，而且系統分拆之後，對於負責單個微服務的小團隊來說，工作也變得很簡單多了。這都是強調服務匯流排（ESB）的 SOA 和單體架構所不能的。

誠然微服務架構的正常運轉需要做很多事情，比如：

• 服務註冊/發現：服務例項的網路地址是動態分配的，服務例項的配置也經常變化，沒有這個就不好玩了。

• 持續部署：功能越多，構建和部署時間越多，再小的修改都需要部署，要是手動部署的話，這人生就看到頭了。

• 異常定位與修復：服務眾多鏈路複雜的時候，這和在茫茫人海中找到那個他/她有一拼了。

• 高可用：服務之間確實相對獨立，資源也隔離，減少區域性故障對整體的影響，但是有呼叫和依賴，不做好每一個服務的高可用，就要等著雪崩了。

但這些是基礎設施層面的工作，只要有一個好的微服務基礎設施，業務侵入性很小，儘可能支援自動化，就不是問題了。網易雲輕舟微服務的設計，就是希望解決微服務應用生命週期的一切問題。

所以，微服務架構也不僅僅解決部分功能擴充套件性的問題，對於系統可用性的保證，溝通成本的減少，支援技術選擇的多樣性，到研發效率的提升，微服務可以發揮的作用還是非常巨大的。

優化業務系統的複雜度，應該在於保證業務響應能力、業務創新能力，同時提升 IT 效率，很多網際網路公司以及傳統企業都在搞微服務，當然是因為搞微服務是有這種好處的。

相關文章：
【推薦】 終於有人把雲端計算、大資料和人工智慧講明白了！（1）