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

創(chuàng)新互聯(lián)成都網(wǎng)站建設定制開發(fā)，是成都網(wǎng)站設計公司,為成都水電改造提供網(wǎng)站建設服務,有成熟的網(wǎng)站定制合作流程，提供網(wǎng)站定制設計服務：原型圖制作、網(wǎng)站創(chuàng)意設計、前端HTML5制作、后臺程序開發(fā)等。成都網(wǎng)站設計熱線：028-86922220

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

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

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

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

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

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

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

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

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

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

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

模塊化的選擇

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

在java中有幾種模塊系統(tǒng)，OSGi是最著名的一個，但隨著java 9本地模塊系統(tǒng)發(fā)布并添加到java平臺本身中。模塊現(xiàn)在是語言和平臺的一部分，作為一等公民而構建。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)。然而，一個好的模塊架構可以利用.net標準的反轉(zhuǎn)控制模式實現(xiàn)。即使C++正在考慮增加模塊化。

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

模塊化設計

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

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

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

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

微服務適合你的公司嗎？

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

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

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

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

分享文章：模塊化與微服務比較MircoServiceVSOSGI
分享地址：http://chinadenli.net/article40/jgjiho.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站制作、外貿(mào)網(wǎng)站建設、品牌網(wǎng)站設計、移動網(wǎng)站建設、品牌網(wǎng)站建設、網(wǎng)站設計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)