模塊化與微服務(wù)比較 MircoService VS OSGI

本文比較了微服務(wù)和模塊化整體架構(gòu)(modularized monolith )的區(qū)別?，F(xiàn)在大家一股腦從整體單片monolith遷移到微服務(wù)，但是這種轉(zhuǎn)變真的適合你公司嗎?整體單片monolith確實有很多問題，但是模塊化(modularized monolith)作為微服務(wù)競爭對手是否被忽視了？

模塊化能夠帶來以下特點：

1. 強大的封裝：隱藏實現(xiàn)細節(jié)在組件內(nèi)部，實現(xiàn)不同部分之間的低耦合。

2.良好的接口：組件之間依賴的是穩(wěn)定API，一個組件可以被任何實施符合接口規(guī)范的其他組件更換。

3.顯式依賴：模塊化系統(tǒng)需要將不同組件組合一起工作，因此你需要有一個明確表達它們（驗證）關(guān)系的好途徑。

這些原則也都可以使用微服務(wù)實現(xiàn)。一個微服務(wù)可以以任何方式實現(xiàn)，只要它暴露了一個定義明確的接口（通常一個REST API）給其他服務(wù)。它的實現(xiàn)細節(jié)是服務(wù)內(nèi)部自身事情，你可以改變這些細節(jié)而不影響整個系統(tǒng)。微服務(wù)之間的依賴關(guān)系通常在開發(fā)時間如果不十分明確，可能在運行時導致服務(wù)的業(yè)務(wù)流程失敗，因此，最后一條模塊原則勝過微服務(wù)一點。

微服務(wù)也包含了模塊化的重要原則，有以下實實在在的好處：

1.團隊可以獨立工作和擴展規(guī)模。

2.微服務(wù)小而聚焦，能降低復雜性。

3.服務(wù)可以在不影響全局情況下內(nèi)部進行改變或整體替換。

但是微服務(wù)缺點是，你已經(jīng)從一個單一的方式（盡管有些輕微肥胖）過度到微服務(wù)的分布式系統(tǒng)，這帶來了表操作的巨大復雜性。突然，你需要不斷地部署許多不同的（可能是使用容器包裝）的服務(wù)。新的問題會出現(xiàn)：服務(wù)發(fā)現(xiàn)、分布式日志記錄、跟蹤等。版本控制接口和配置管理也會成為一個大問題。

微服務(wù)之間連接的復雜性是因為所有微服務(wù)個體需要聯(lián)合起來實現(xiàn)業(yè)務(wù)邏輯。

模塊化的選擇

我們是否要么使用混亂的monolith整體單片架構(gòu)，要么就會被微服務(wù)復雜性淹沒呢？模塊化其實是另外一個選擇。重要的是通過模塊化我們可以在開發(fā)過程中有效地繪制和執(zhí)行邊界，這當然需要我們積極擁抱編程語言和開發(fā)工具以支持模塊化。

在java中有幾種模塊系統(tǒng)，OSGi是最著名的一個，但隨著java 9本地模塊系統(tǒng)發(fā)布并添加到j(luò)ava平臺本身中。模塊現(xiàn)在是語言和平臺的一部分，作為一等公民而構(gòu)建。java模塊可以表達對其他模塊的依賴，并公開導出接口而同時實現(xiàn)類可進行強大的內(nèi)部封裝。即使是java平臺本身（一個巨大的代碼庫）也已經(jīng)被模塊化。

其他語言提供了類似的機制。例如，JavaScript在ES2015有模塊系統(tǒng)。在這之前，Node.js已經(jīng)提供了一個標準的JavaScript后端模塊系統(tǒng)。然而，作為一個動態(tài)語言，JavaScript在模塊之間支持較弱（類型）接口和封裝。微軟的.NET框架有類似Java較強的類型，但是它沒有等同于java即將推出的模塊系統(tǒng)。然而，一個好的模塊架構(gòu)可以利用.net標準的反轉(zhuǎn)控制模式實現(xiàn)。即使C++正在考慮增加模塊化。

當你有意識地使用開發(fā)平臺的模塊化功能時，可以使用模塊化獲得微服務(wù)一樣的好處。從本質(zhì)上講，更好的模塊系統(tǒng)更能在開發(fā)過程中幫助你。不同的團隊可以工作在不同部位，這些部位之間只通過定義良好的接口調(diào)用，在部署時這些模塊能一起部署在單一單元。這樣可以防止遷移到精衛(wèi)帶來開發(fā)和管理相關(guān)的巨大復雜性和成本。

模塊化設(shè)計

創(chuàng)建好的模塊同樣需要設(shè)計嚴謹?shù)牧己玫奈⒎?wù)。一個模塊應該基于有界上下文（bounded context）建模。選擇微服務(wù)邊界是架構(gòu)重大決策，一旦選擇錯誤會帶來昂貴的代價。在一個模塊化的應用中模塊的界限更容易改變?？缒K重構(gòu)通常由類型系統(tǒng)和編譯器支持。重新劃分微服務(wù)邊界包含很多內(nèi)部個人交流以確保不會失敗，誠實點，你能第一次就正確劃分你的服務(wù)邊界，或者第二次就可以？

在許多方面，靜態(tài)類型語言模塊通過定義良好的接口提供更好的構(gòu)建。直接調(diào)用另一模塊暴露的接口方法比調(diào)用另外一個微服務(wù)REST端點會更健壯，但是REST+JSON是無處不在的，但它由于缺乏（編譯器檢查）等結(jié)構(gòu)在交互性上會差一點，再加上穿越網(wǎng)絡(luò)包括序列化數(shù)據(jù)也不是免費。

模塊是代碼所有權(quán)的自然單位，團隊可以負責一個或多個模塊的系統(tǒng)。與其他團隊共享的唯一事情是他們的公共API模塊。在運行時，相比微服務(wù)模塊之間有較少的隔離，而一切都在同一個進程中運行。

模塊之間也可以通過定義良好接口和消息共享數(shù)據(jù)，沒有必要共享一個數(shù)據(jù)庫，模塊化和微服務(wù)最大區(qū)別是模塊的一切發(fā)生在同一個進程內(nèi)。最終一致性問題可不容小覷。使用模塊化架構(gòu)最終一致性可以是主動的策略選擇。對于微服務(wù)，最終一致性是沒有選擇：是注定的，你只有適應。

微服務(wù)適合你的公司嗎？

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

使用微服務(wù)的一個好處是，不同的服務(wù)可采取不同的技術(shù)棧。然后，你必須吸引這些不同棧的人才并保持這些平臺的建立和運行。

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

        原文鏈接 https://www.jdon.com/48797