我是一個著迷於產品和運營的技術人，樂於跨界的終身學習者。歡迎關注我喲～
每週五早6點 按時送達～
大家好，我是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.
不知道你是怎麼看待「單應用模塊化」和「分佈式服務化」兩者的利弊的呢？歡迎留言給我一起討論哦。
也可以「關注」我，帶你以技術思維看世界～
想更進一步和我一起玩耍，歡迎「搜索微信公號：跨界架構師」。
內容包括：架構設計丨分佈式系統丨產品丨運營丨個人深度思考。
閱讀更多 跨界架構師 的文章
