大家好，我是Z哥。

這次分享給大家的是一篇與技術(shù)相關(guān)的文章，但是我想表達(dá)的核心觀點(diǎn)并不僅限于技術(shù)范圍。

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

很多事物的發(fā)展都逃不開這個規(guī)律。如今，這件事也正在分布式、微服務(wù)概念大行其道的軟件開發(fā)領(lǐng)域里發(fā)生。

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

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

istio是一種以sidecar模式為應(yīng)用程序建立網(wǎng)絡(luò)通信的技術(shù)框架，基于其搭建的通信網(wǎng)絡(luò)具有負(fù)載均衡、服務(wù)間認(rèn)證、監(jiān)控等功能。這些功能都是微服務(wù)系統(tǒng)中必不可少的。

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

這個框架的設(shè)計非常整潔，各個模塊的職責(zé)清晰，被不少人視作“高內(nèi)聚、低耦合”的范本。但是它的每個模塊都是單獨(dú)維護(hù)的，其中Mixer的模塊甚至是單獨(dú)一個進(jìn)程來運(yùn)行。

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

此時，作為Service Mesh的領(lǐng)頭羊宣布回歸單體應(yīng)用，雖然對它自身來說只是一個架構(gòu)調(diào)整而已，但間接給國內(nèi)各種炒作微服務(wù)概念的人敲了一下警鐘。

身邊有不少人或者企業(yè)其實在盲目的追求微服務(wù)架構(gòu)，覺得少了這個就不好意思說自己在互聯(lián)網(wǎng)企業(yè)做技術(shù)一樣。

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

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

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

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

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

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

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

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

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

是否經(jīng)常費(fèi)很大勁才能確定問題的根源在哪一個服務(wù)上？如果是，可能是過度拆分。

當(dāng)然，拆分的好處是顯而易見的，分而治之，成就“高內(nèi)聚、低耦合”的終極目標(biāo)。

但其實單體應(yīng)用做好模塊化劃分和管理，也能成就“高內(nèi)聚、低耦合”這個目標(biāo)，同樣不會成為“Mud Ball”。

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

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

• 單一職責(zé)原則

• 里氏替換原則

• 依賴倒置原則

• 迪米特法則

• 開閉原則

• 接口隔離原則

• 合成復(fù)用原則

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

istio團(tuán)隊已經(jīng)深刻認(rèn)識到了這個問題，所以他們喊出了一個口號：

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

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

推薦閱讀：

• 聊聊面試的事（應(yīng)聘方）
  

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

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

如果你有關(guān)于軟件架構(gòu)、分布式系統(tǒng)、產(chǎn)品、運(yùn)營的困惑

可以試試點(diǎn)擊「閱讀原文」

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。