對于網絡服務來說，首先，前提條件就是要有一個由100+共享庫組成的企業級平臺，才能確保有能力來運行網絡服務，還能夠讓有權限的網絡客戶共同討論構建更強大的微服務（Microservices）。Ben Christensen在最近舉辦的Microservices Practitioner Summit峰會上分享構建分布式系統經驗和微服務趨勢的時候如此解釋網絡服務的要點，尤其是在當前這種對二進制依賴比較強烈的系統正在翻倍增長的情況下，更要搞懂微服務是什么！
不妨在這里簡單介紹一下Monolith！網上對微服務進行介紹的文章常常以Monolith作為開頭，這里也不例外。原因是，知道了Monolith的不便之后才能更容易地理解微服務架構模式所具有的各種優點。
我們所開發的服務應該都是什么樣子呢？通常情況下，這個服務所對應的代碼由多個項目所組成，各個項目會根據自身所提供功能的不同具有一個明確的邊界。在編譯時，這些項目將被打包成為一個個JAR包，并最終合并在一起形成一個WAR包。接下來，我們需要將該WAR包上傳到Web容器中進行解壓，并重新啟動服務器。在執行完這一系列操作之后，我們對服務的編譯及部署就已經完成了。
由于按照Monolith組織的代碼來運行的話，將只產生一個包含了所有功能的WAR包，因此在對服務的容量進行擴展的時候，我們只能選擇重復地部署這些WAR包來擴展服務能力，而不是僅僅擴展出現系統瓶頸的組成。
但是這種擴展方式極大地浪費了資源。比如（上圖）：在一個服務中，某個組成的負載已經達到了90%，也就是到了不得不對服務能力進行擴容的時候了。而同一服務的其它三個組成的負載還沒有到其處理能力的20%。由于Monolith服務中的各個組成是打包在同一個WAR包中的，因此通過添加一個額外的服務實例雖然可以將需要擴容的組成負載降低到了45%，但是也使得其它各組成的利用率更為低下。可以說，所有的不便都是由于Monolith服務中一個WAR包包含了該服務的所有功能所導致的。而解決該問題的方法就是微服務架構模式。
言歸正傳，Christensen或許對一些人來說并不陌生，他是Facebook的軟件工程師。共享庫是運行網絡服務必不可少的重要部分，這兩者結合起來就被稱之為“平臺”。比較常見通用的類庫包含Spring和Guava，兩者通常被用在路由和日志里面。所以說，最后這一系統還是得依靠那100多個類庫才能把微服務運行起來。如果一個服務不能和系統進行互動的話，只能說明所有的類庫都是可用的，Christensen將這種現象稱之為分布式的Monolith。基本上，你在推廣所使用的分布式系統的時候，會丟掉很多關于微服務架構的有價值的東西，這些有價值的東西包括“多語言編程”，用Christensen自己的話來說就是，這會讓網絡服務加大錯失接受不同技術、組織結構以及技術解藕的可能性，這樣也會阻礙團隊在技術層面上的改進升級。
Don’t Repeat Yourself的字母縮寫DRY對很多人來說都不陌生，尤其是對開發者。在共享代碼的業務邏輯中，孤立的去部署變化條件正在被摒棄，因為這種做法會直接影響服務執行代碼的效果。Christensen強調共享代碼在服務邊界里面是相當完美的，可是一旦泄漏的話，就會有潛在的耦合可能性。Sam Newman在他的新書《Building Microservices》里提到：
服務之間太多的耦合所帶來的弊端遠超多簡簡單單復制代碼所帶來的問題還要嚴重很多倍。
Christensen認為可替換的方案就是采用契約和協議，服務應該隱藏所有的實現細節，而只將數據契約和網絡協議暴露出來。在不依賴服務實現的前提下，用戶能夠使用任何技術和編程語言，并以自己的速度來發展，這才是網絡該做的事情。他指出，雖然在如日志記錄，分布式跟蹤，路由等領域沒有強制的標準化需求，但還是應該啟用獨立的類庫，這樣消費者才有權選擇是否使用這些網絡服務。
Christensen認為，經常性犯這樣低級的錯誤是很容易的，因為我們都知道如何使用使用共享類庫，我們也常常在短期內進行優化來達到更高的產出，問題也就是在這個時候產生的。他還指出，雖然推遲解藕的成本較高，可是解決方案也是有的，動動腦經努力在剛開始的時候就把合適的工具放在合適的地方，這樣才能物盡所能發揮最大效果。
在最后的問答過程中他認為，使用一個大的框架無可厚非，只要它被當作內部一個獨立的服務使用就行，但如果整個系統的架構不采用的話就算了，因為這會導致一個長期的耦合。
微架構或者甚至SOA架構真正發揮所長的地方在于，根據彼此獨立部署的邏輯服務，這些邏輯服務可以獨立于其他服務進行擴展，而且能夠實現獨立的故障切換。
紅帽公司中間件部門工程副總裁Mark Little博士說：“我在微服務方面擔心的問題之一就是，你有一個整體式系統(monolith)，假設你開始把它分解成多個服務，可是分解時很隨意，到頭來就會分解得過細，最后會有10個、100個甚至1000個微服務。”
“但是這些微服務又彼此高度依賴，以至于如果某一個服務出現故障，其余服務很有可能也會出現故障。這種情況下，你一無所獲。你有999個服務就在那里干等著另一個服務恢復正常運行。”
最后，Little認為，那些開始使用微服務的人應該找出未能實現其功能的軟件，而不是就因為使用年限而把那些舊軟件挑出來。
查看英文原文：Microservices Ending up as a Distributed Monolith
京公網安備 11010502049343號