模組化與微服務比較

模組化的選擇
我們是否要麼使用混亂的monolith整體單片架構，要麼就會被微服務複雜性淹沒呢？模組化其實是另外一個選擇。重要的是透過模組化我們可以在開發過程中有效地繪製和執行邊界，這當然需要我們積極擁抱程式語言和開發工具以支援模組化。

在java中有幾種模組系統，OSGi是最著名的一個，但隨著java 9本地模組系統釋出並新增到java平臺本身中。模組現在是語言和平臺的一部分，作為一等公民而構建。java模組可以表達對其他模組的依賴，並公開匯出介面而同時實現類可進行強大的內部封裝。即使是java平臺本身（一個巨大的程式碼庫）也已經被模組化。

其他語言提供了類似的機制。例如，JavaScript在ES2015有模組系統。在這之前，Node.js已經提供了一個標準的JavaScript後端模組系統。然而，作為一個動態語言，JavaScript在模組之間支援較弱（型別）介面和封裝。微軟的.NET框架有類似Java較強的型別，但是它沒有等同於java即將推出的模組系統。然而，一個好的模組架構可以利用.net標準的反轉控制模式實現。即使C++正在考慮增加模組化。

當你有意識地使用開發平臺的模組化功能時，可以使用模組化獲得微服務一樣的好處。從本質上講，更好的模組系統更能在開發過程中幫助你。不同的團隊可以工作在不同部位，這些部位之間只透過定義良好的介面呼叫，在部署時這些模組能一起部署在單一單元。這樣可以防止遷移到精衛帶來開發和管理相關的巨大複雜性和成本。

模組化設計
建立好的模組同樣需要設計嚴謹的良好的微服務。一個模組應該基於有界上下文（bounded context）建模。選擇微服務邊界是架構重大決策，一旦選擇錯誤會帶來昂貴的代價。在一個模組化的應用中模組的界限更容易改變。跨模組重構通常由型別系統和編譯器支援。重新劃分微服務邊界包含很多內部個人交流以確保不會失敗，誠實點，你能第一次就正確劃分你的服務邊界，或者第二次就可以？

在許多方面，靜態型別語言模組透過定義良好的介面提供更好的構建。直接呼叫另一模組暴露的介面方法比呼叫另外一個微服務REST端點會更健壯，但是REST+JSON是無處不在的，但它由於缺乏（編譯器檢查）等結構在互動性上會差一點，再加上穿越網路包括序列化資料也不是免費。

模組是程式碼所有權的自然單位，團隊可以負責一個或多個模組的系統。與其他團隊共享的唯一事情是他們的公共API模組。在執行時，相比微服務模組之間有較少的隔離，而一切都在同一個程式中執行。

模組之間也可以透過定義良好介面和訊息共享資料，沒有必要共享一個資料庫，模組化和微服務最大區別是模組的一切發生在同一個程式內。最終一致性問題可不容小覷。使用模組化架構最終一致性可以是主動的策略選擇。對於微服務，最終一致性是沒有選擇：是註定的，你只有適應。

微服務適合你的公司嗎？
當你的公司達到谷歌或Netflix的規模，擁抱微服務也許有意義。你要有建立自己的平臺和工具的能力。但大多數公司達不到這個規模。即使你認為你的公司會有一天成為十億美元的獨角獸，在一開始實現模組化整體架構(modularized monolith )不會有多大傷害。

使用微服務的一個好處是，不同的服務可採取不同的技術棧。然後，你必須吸引這些不同棧的人才並保持這些平臺的建立和執行。

微服務能獨立部署，不同的微服務可以部署到相匹配的硬體上。模組化(modularized monolith)可以水平縮放，但你需要將模組捆在一起擴充，不能獨立擴充套件。