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