在最近的Microservices Practitioner Summit峰會上，來自Facebook的工程師Ben Christensen就目前正在普遍快速增長的分布式系統與二進制依賴關系的一種反面模式發表了自己的看法。

\\

Christensen談到說，共享類庫是整個服務運行過程中最需要的部分；另一方面，這些類庫總的來說也可以被認為是“一種平臺”。包括像Spring、Guava和那些通常被用在路由消息和日志記錄里的類庫。在最后，一個系統的性能優劣取決于是否具備100+類庫的組合。如果一個服務不能和系統進行互動的話，只能說明這些類庫的可用性有問題，Christensen稱這種情況為分布式單體架構。本質上來講，你所做的那些將成本花在分布式系統上的事情，其實只是在網絡上推廣單體架構，但是并沒有從微服務架構里面獲得任何好處。至于丟失的這些好處就包括多語言特點，也就意味著你所開發的這個服務錯過了利用最好的技術來解決特殊問題的可能性，包含組織上和技術解藕方面的問題。解決處理了這些問題有助于團隊進行技術升級，而不需要在第一時間去獲得授權。

\\

\\

不妨在這里簡單介紹一下單體架構應用（Monolith），網上對微服務進行介紹的文章常常以單體架構開始。這里也不例外，只有在知道了單體架構的不便之后才能更容易地理解微服務架構模式所具備的各種優點。

\\

開發出來的服務應該是什么樣子呢？通常情況下，這個服務所對應的代碼是由多個項目所組成，各個項目會根據自身所提供功能的不同具有一個明確的邊界。在編譯時，這些項目會被打包成為一個個JAR包，并最終合并在一起形成一個WAR包。接下來，開發者需要將該WAR包上傳到Web容器中進行解壓，并重新啟動服務器。在執行完這一系列操作之后，對服務的編譯及部署流程也就完成了。如果按照單體架構組織的代碼來運行的話，會生成一個包含了所有功能的WAR包，因此在對服務的容量進行擴展的時候，我們只能選擇重復部署這些WAR包來擴展服務能力，而不是僅僅擴展系統瓶頸的組成。

\\

\\

但是這種擴展方式極大地浪費了資源。比如（上圖）：在一個服務中，某個組成的負載已經達到了90%，也就是到了不得不對服務能力進行擴容的時候了。而同一服務的其它三個組成的負載還沒有到其處理能力的20%。由于單體架構服務中的各個組成是打包在同一個WAR包中的，因此通過添加一個額外的服務實例，可以將需要擴容的負載降低到45%，但是也使得其它各組成的利用率更為低下。可以說，所有的不便都是由于單體架構服務中一個WAR包包含了該服務的所有功能所導致的。而解決該問題的方法就是微服務架構模式。

\\

Don’t Repeat Yourself的字母縮寫DRY對很多人來說都不陌生，意即不要重復造輪子。在共享代碼的業務邏輯中，孤立的去部署變化條件的方式正在被摒棄，因為這種做法會直接影響服務執行代碼的效果。Christensen強調共享代碼在服務邊界里面是相當完美的，可是一旦泄漏的話，就會有潛在的耦合可能性。Sam Newman在他的新書《Building Microservices》里提到：

\\\

The evils of too much coupling between services are far worse than the problems caused by code duplication。

\\

服務之間太多的耦合所帶來的弊端，遠比簡簡單單復制代碼所帶來的問題還要嚴重很多倍。

\\\

Christensen認為可替代的解決方案就是采用穩定的協議，隱藏所有的實現細節，只將數據契約和網絡協議暴露出來，在不依賴服務實現的前提下，用戶都能夠使用任何技術和編程語言，這才是網絡該做的事情。Christensen還指出，雖然在如日志記錄、分布式跟蹤、路由等領域沒有強制的標準化需求，但還是應該啟用獨立的類庫，這樣用戶才有權選擇是否使用這些網絡服務。

\\

Christensen認為，這樣的低級錯誤是很容易經常性犯的，因為我們都知道如何使用共享類庫，我們也常常在短期內進行優化來達到更高效率。他還說，雖然推遲解藕的成本較高，可是解決方案也是有的，努力在剛開始的時候就把合適的工具用在合適的地方，物盡所用才能發揮最大效果。

\\

在最后的問答過程中他提到，使用一個大的框架無可厚非，只要這個框架被當作內部一個獨立的服務使用就行，但如果整個系統的架構不采用這個大的框架也并無大礙，因為這會避免出現長期耦合。微架構或者SOA架構真正發揮所長的地方在于，根據彼此獨立部署的邏輯服務，這些邏輯服務可以獨立于其他服務進行擴展，而且能夠實現獨立的故障切換。

\\

紅帽公司中間件部門工程副總裁Mark Little博士也曾說過：“我在微服務架構方面擔心的問題之一就是，你有一個整體式單體架構應用，假設你隨意把它分解成多個服務，到頭來就會分解得過細，最后會有10個、100個甚至1000個微服務。但是這些微服務又彼此高度依賴，以至于如果某一個服務出現故障，其余服務很有可能也會出現故障。這種情況下，你將一無所獲。你有999個服務就在那里干等著另一個服務恢復正常運行之后才能工作。”

\\

查看英文原文：Microservices Ending up as a Distributed Monolith

總結

以上是生活随笔為你收集整理的微服务架构会和分布式单体架构高度重合吗的全部內容，希望文章能夠幫你解決所遇到的問題。

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