大家好，我是Z哥。

這次分享給大家的是一篇與技術相關的文章，但是我想表達的核心觀點并不僅限于技術范圍。

我們中國有句古話，分久必合，合久必分。

很多事物的發展都逃不開這個規律。如今，這件事也正在分布式、微服務概念大行其道的軟件開發領域里發生。

就在這個月5號，在近些年大熱的Service Mesh中被熱炒的istio宣布回歸到單體應用架構。

可能有的人對istio不是很了解，我稍作下介紹。

istio是一種以sidecar模式為應用程序建立網絡通信的技術框架，基于其搭建的通信網絡具有負載均衡、服務間認證、監控等功能。這些功能都是微服務系統中必不可少的。

它亮點就在sidecar模式的無代碼侵入上，配合上“黃金搭檔”——docker，讓它成為了近兩年火熱的Service Mesh概念的帶頭大哥之一。

這個框架的設計非常整潔，各個模塊的職責清晰，被不少人視作“高內聚、低耦合”的范本。但是它的每個模塊都是單獨維護的，其中Mixer的模塊甚至是單獨一個進程來運行。

就這些簡單的分離，其實也是“分布式”、“微服務”的「分治」思想的體現。

此時，作為Service Mesh的領頭羊宣布回歸單體應用，雖然對它自身來說只是一個架構調整而已，但間接給國內各種炒作微服務概念的人敲了一下警鐘。

身邊有不少人或者企業其實在盲目的追求微服務架構，覺得少了這個就不好意思說自己在互聯網企業做技術一樣。

并且有一些還在追求更細粒度的微服務拆分上樂此不疲。原本一個應用程序就能搞定的一件事，非得拆成4個、5個程序相互協調才能完成。這樣真的劃算嗎？要打上一個大大的問號。

其實類似這樣的事情在我們的生活中很常見，但是在生活中我們卻理性得多。

想象一下，假如現在你要去倒垃圾，那么需要做以下這幾件事。換上衣服、給垃圾分類、下樓走到垃圾桶前倒掉。

你會請3個人分別幫你換衣服、做垃圾分類以及下樓去倒掉嗎？我想肯定不會，這不是搞笑么。

別笑，過度的服務化拆分就是這么變扭的一件事。一個叫ChangeClothesService、一個叫WasteSortingService，一個叫DumpRubbishService……

那么，如何判斷當下的系統是否過度拆分？你可以試著回答以下幾個問題。

各個部分是否支持單獨部署和更新？如果不能，就是過度拆分。

是否可以由不同的開發人員維護不同的部分？如果不能，就是過度拆分。

是否存在不同的運維策略。比如，不同的安全策略、部署策略等。如果不存在，可能是過度拆分。

是否經常費很大勁才能確定問題的根源在哪一個服務上？如果是，可能是過度拆分。

當然，拆分的好處是顯而易見的，分而治之，成就“高內聚、低耦合”的終極目標。

但其實單體應用做好模塊化劃分和管理，也能成就“高內聚、低耦合”這個目標，同樣不會成為“Mud Ball”。

不過，為了在同一個項目里達到“高內聚、低耦合”的效果，這必然會比使用服務化的拆分方式付出更多的代碼管理成本。畢竟后者對代碼進行了硬性的隔離，而單體應用的模塊化拆分全靠每一位參與編碼的程序員是否共同遵守了一些共識。

比如，我們在編碼的時候要盡可能的共同遵守以下這些原則：

• 單一職責原則

• 里氏替換原則

• 依賴倒置原則

• 迪米特法則

• 開閉原則

• 接口隔離原則

• 合成復用原則

為了確保大家遵守統一的規則，對codereview的要求就會提高，所以代碼管理成本是實實在在會增加的。但是這些額外的成本相比過度微服務化后增加的復雜度所帶來的隱性成本，哪個劃算還真得好好算算。

istio團隊已經深刻認識到了這個問題，所以他們喊出了一個口號：

Complexity?is?the?root?of?all?evil?or:?How?I?Learned?to?Stop?Worrying?and?Love?the?Monolith.

不知道你是怎么看待「單應用模塊化」和「分布式服務化」兩者的利弊的呢？歡迎留言給我一起討論哦。

推薦閱讀：

• 聊聊面試的事（應聘方）
  

• 新的一年，程序員如何讓自己更值錢？
  

原創不易，如果你覺得這篇文章還不錯，就「在看」或者「分享」一下吧。鼓勵我的創作 ：）

如果你有關于軟件架構、分布式系統、產品、運營的困惑

可以試試點擊「閱讀原文」

總結

以上是生活随笔為你收集整理的istio回归「单体应用」对我们的启发的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。