Java 模塊（在 Java 9 中）、OSGi 包和微服務之間的具體區別是什么？ 他們每個人的具體目的是什么？

Question

我已經使用了所有三種技術，我認為這三種技術或多或少只是解決相同或常見問題的不同方法 例如

常見問題：假設有一個非常大的企業應用程序，隨着時間的推移，該應用程序通過添加新功能、更新現有功能、錯誤修復等（單體架構風格）變得越來越大和越來越復雜，其后果很難維護代碼，如果任何事情中斷可能會破壞整個應用程序，對應用程序所做的更改需要重建並重新測試和重新部署整個應用程序（redeploy.Ear、.War 等），這是一個耗時的過程，並且應用程序停機時間很長。

常見解決方案：將大型企業應用程序分解為“小塊”，這些“小塊”以不同的名稱調用 Java 9：稱為“Module”或 JMPS（Java 模塊平台系統）在 OSGi 中：稱為在基於微服務的架構中作為“Bundle”：它被稱為微服務或只是服務

讓這些小塊執行單個function，使它們獨立工作，獨立部署，獨立啟動和停止，然后提供這些小塊之間的依賴關系，以便它們可以與其他小塊通信，使整個應用程序無縫工作。 如果任何小塊失敗不應該對整個應用程序產生重大影響，特定的 function 只會受到影響，但整個應用程序會繼續運行 易於維護小塊塊（稱為模塊、捆綁包、微服務） 更快的開發，易於部署和裝運它。

除此之外，如果有人非常了解所有 3 種技術並且可以為它們中的每一種提供特定的區別和特定的目的，那就太好了。

問候， Gokul

Answer 1

Stackoverflow 上已經有許多答案指出了不同的技術。 但是，我認為沒有明確的比較。 我從一開始就參與了 OSGi，並且自 2004 年以來一直參與 JPMS 開發。

遺憾的是，JPMS 對模塊系統的印象出奇地差。 它像一個模塊系統一樣行走，它像一個模塊系統一樣說話，但它絕對不是，因為它缺乏模塊的內在屬性：信息隱藏。 它給人的印象非常好，但只是嘗試在兩個不相關的模塊中使用相同的 class 名稱。 例如，您需要有 2 個版本的相同 class。 這違反了模塊化的主要目的，即您可以在模塊的私有區域中做任何您想做的事情； 它不應該影響整體。

這聽起來像是一個牽強附會的抱怨，但它實際上是 OSGi 中非常常見的用例。 您無需依賴外部模塊，而是在內部使用 package 模塊來簡化整體操作。 在 JPMS 中，您將不得不使您的構建和陰影復雜化。 然后仍然有人可能與您的私有命名空間發生沖突。

對我來說，這足以取消 JPMS 的資格。 您還詢問了微服務。 然而，微服務不是模塊。 然而，它們是模塊化思維的一個絕對必要的方面。 模塊系統的一個關鍵方面是依賴關系。 流行的構建系統maven使用一個模塊到模塊的依賴關系 model，它非常簡單且非常強大，但對於較大的系統，它將創建一個非常難以控制的傳遞依賴關系 model，往往有大量的粉絲。 也許是人們為了一個簡單的hello world下載了互聯網，但是模塊到模塊的依賴確實讓大型復雜應用程序很容易造成混亂。

微服務將模塊到模塊的依賴關系更改為模塊到服務的依賴關系。 微服務的巨大成功很大程度上是因為它允許模塊在模塊進化時通過為微服務提供相同的 API 來獨立進化。 這打破了傳遞依賴並顯着簡化了系統的整體復雜性。 雖然 JPMS 有 Service Loader model，但這是一個非常糟糕的微服務實現，幾乎不值得一提。 它是 static 並在依賴項 model 中完全忽略。

到目前為止，我對微服務的表述相對模糊； 基本上它們是模塊之間的管道。 然而，在外面的大世界中，微服務通常被理解為類似於 REST 服務。 然而，它們的架構優勢（打破傳遞依賴模型）並不取決於它們的通信技術。 好處是有一個明確的端點來與之通信，該端點具有一個內聚的 API。

自 2000 年代初以來，OSGi 創造了 µservices 一詞。 OSGi中的核心編程model是創建注冊服務和獲取服務的模塊。 一個好的 OSGi 系統只通過這些服務進行通信。 由於 OSGi 服務是普通的舊 Java object，因此（最小）開銷僅限於設置。

由於我們從一開始就將 OSGi 設計為具有反射性，因此可以將適用的 OSGi 服務 map 應用於通信端點，例如 REST 服務或 MQTT 主題。 這種映射可以在沒有任何實際服務知識的情況下完成。 這在遠程 OSGi 服務中都是標准化的。 OSGi 的動態特性提供了良好的基礎，因為它為處理分布式計算的謬誤提供了基礎。

主要的軟件法則之一是凝聚力。 在 OSGi 中，您可以最大限度地保持模塊、包、類和方法的內聚性。

為了提供錦上添花，OSGi 將 µservices 集成到其本機依賴項 model 中。 一個 OSGi 應用程序由數百個模塊組成，這些模塊通過數百個服務相互交互。 模塊只依賴於定義明確的服務。 服務可以由不同的模塊提供，這些模塊很快就會變得混亂。 幸運的是，OSGi 因此為 select 提供了一個解析器，這是一個滿足所有模塊要求（包括服務）的模塊組合。

總結。 JPMS 和微服務都不是合適的模塊系統。 只有使用 OSGi，您才能獲得一個真正的模塊系統，該系統具有私有並與微服務本地集成。

另請參閱OSGi 服務和 REST 微服務之間的區別

Answer 2

“可悲的是，JPMS 對模塊系統的印象出人意料地糟糕”。 （非常正確）“對我來說，這足以取消 JPMS 的資格”。 （我同意）簡而言之，JPMS應該被限制在內部使用“JRE Restructuring Or Reorganizing”，以便它可以用於小型設備。所以我們假設JPMS暫時被排除在外。

現在我試圖找出 OSGi 和微服務之間的一些具體區別讓我們先看看 OSGi

1] OSGi 包導出和導入包並自行注冊 2] OSGi 包通過導入和導出所需包相互通信 3] 並且是 OSGi 包可以單獨安裝/部署/啟動/停止 4] 理想情況下，每個 OSGi 包應該執行單個 function。 5] 但是所有這些 OSGi 捆綁包練習都發生在應用程序中（部署在兩個不同環境中的兩個不同應用程序中的捆綁包之間沒有通信）並且 OSG 捆綁包直接與其他捆綁包通信 6] OSGi 捆綁包不是異構分布的（例如，使用不同的開發包開發 4 個捆綁包） programming languages like Java, C++, Python, .Net and make them work together I am not sure whether it is possible or not with OSGi bundles) 7] Well managed dependencies among OSGi bundles (As you mentioned it is "A crucial aspect of module系統是依賴關系”。）

另一方面，微服務

1] 微服務是小型自治服務。 2] 我理解的基本概念是每個微服務執行一個 function。 3] 微服務使用 RESTful 調用相互通信 4] 微服務可以是異構分布的（意味着如果有 4 個微服務，那么首先用“Java”開發，然后用“C++”開發，第三用“Python”開發，然后再開發在“.Net”中，所有四個都可以通過 RESTful 調用無縫通信）5] 由於微服務是松散耦合的，因此對其他微服務的依賴較少，但在一定程度上仍然依賴於微服務之間的良好管理依賴關系和通信。 正如您完美提到的 6] 微服務將模塊到模塊的依賴關系更改為模塊到服務的依賴關系。 微服務的巨大成功很大程度上是因為它允許模塊獨立發展

多個 OSGi 包之間的通信和多個微服務之間的通信
OSGi 不是 SOA 的變體，OSGi 包不使用 RESTful API 調用或通過任何其他方式與其他應用程序中的包通信（如果我不正確，請糾正我）而微服務是 SOA 的一種變體，並且可以與其他異構分布式通信使用 RESTful API 調用的微服務

負載平衡和可擴展性如果對一個特定微服務的請求負載很重，那么同一微服務的多個實例可以
被創建來平衡負載（我不確定這是否可能與相同的 OSGi 包的多個實例）

安全性（微服務堆之間的安全通信）使用 OAuth 可以使多個微服務之間的通信更加安全（我不確定這是否可以通過 OSGi 包實現）

因此，總結 OSGi 架構風格與上述方式中的微服務架構風格有點不同，乍一看，在我看來，基於微服務的架構比 OSGi 風格略占優勢。

如果我們嘗試同時使用這兩種技術來開發大型企業應用程序，這可能是一種混亂的情況（如果我在整篇文章中添加了任何不正確的東西，請糾正我）謝謝和問候，Gokul