Java 模块（在 Java 9 中）、OSGi 捆绑包和微服务之间有什么具体区别？它们各自的具体目的是什么？

Question

我已经了解了所有三种技术，我认为这三种技术或多或少都只不过是解决相同或常见问题的不同方法而已

常见问题：假设有一个非常大的企业应用程序，随着时间的推移，该应用程序通过添加新功能、更新现有功能、修复错误等（以整体架构风格）变得越来越大、越来越复杂，其后果是很难解决的。维护代码，如果任何事情破坏都会破坏整个应用程序，对应用程序所做的更改需要重建和重新测试并重新部署整个应用程序（重新部署.Ear、.War 等），这是一个耗时的过程，并且应用程序停机时间很长。

常见解决方案：将大型企业应用程序分成“小块”，这些“小块”以不同的名称进行调用 在 Java 9 中：它被称为“模块”或 JMPS（Java 模块平台系统） 在 OSGi 中：它被称为作为基于微服务的架构中的“捆绑”：它被称为微服务或只是服务

让这些小块执行单一功能，让它们独立工作、独立部署、独立启动和停止，然后在这些小块之间提供依赖关系，以便它们可以与其他小块进行通信，使整个应用程序无缝工作。如果任何小块发生故障，不应对整个应用程序产生重大影响，该特定功能只会受到影响，但整个应用程序仍保持运行 易于维护小块（称为模块、捆绑包、微服务） 开发速度更快，易于部署和部署装运它。

除此之外，如果有人非常了解这三种技术，并且能够为每一种技术提供具体的差异和具体的用途，那就太好了。

问候， 戈库尔

Answer 1

Stackoverflow 上已经有很多答案指出了不同的技术。但是，我认为没有明显的比较。我从一开始就参与了 OSGi，并且自 2004 年以来一直参与 JPMS 开发。

\n

遗憾的是，JPMS 给模块系统留下了令人惊讶的坏印象。它像模块系统一样行走，像模块系统一样说话，但它绝对不是，因为它缺乏模块的内在属性：信息隐藏。它给人留下了令人钦佩的印象，但只是尝试在两个不相关的模块中使用相同的类名。例如，您需要拥有同一类的 2 个版本。这违反了模块化的主要目的，即您可以在模块的私有区域中做任何您想做的事情；不应该影响整体。

\n

这听起来可能是一个牵强的抱怨，但它实际上是 OSGi 中非常常见的用例。不依赖外部模块，而是将模块封装在内部以简化整体操作。在 JPMS 中，您必须使构建和着色变得复杂。然后仍然有人可能与您的私有命名空间发生冲突。

\n

对我来说，这足以取消 JPMS 的资格。您还询问了微服务。然而，微服务不是模块。然而，恕我直言，它们是模块化思维绝对必要的一个方面。模块系统的一个重要方面是依赖性。流行的构建系统maven使用模块到模块的依赖模型，该模型非常简单且功能强大，但对于较大的系统，它将创建一个非常难以控制的传递依赖模型，该模型往往具有大量扇出。也许人们只是为了简单的目的而在互联网上下载hello world但模块之间的依赖关系确实使得大型复杂应用程序变得一团糟。

\n

微服务将模块到模块的依赖关系更改为模块到服务的依赖关系。微服务的巨大成功很大程度上是因为它允许模块在模块发展时通过向微服务提供相同的API 来独立发展。这打破了传递依赖并显着简化了系统的整体复杂性。尽管 JPMS 具有 Service Loader 模型，但这是一种非常糟糕的微服务实现，几乎不值得一提。它是静态的并且在依赖模型中完全被忽略。

\n

到目前为止，我对微服务的描述相对模糊。基本上它们是模块之间的管道。然而，在广阔的世界中，微服务通常被理解为类似于 REST 服务。然而，它们的架构优势（打破传递依赖模型）并不依赖于它们的通信技术。这些好处是由于有一个清晰的端点进行通信，并且具有内聚的 API。

\n

OSGi 自 2000 年初以来就创造了术语 \xc2\xb5services。OSGi 中的核心编程模型是创建注册服务和获取服务的模块。一个好的 OSGi 系统仅通过这些服务进行通信。由于 OSGi 服务是一个普通的旧 Java 对象，因此（最小）开销仅限于设置。

\n

由于我们从第一天起就将 OSGi 设计为反射性的，因此可以将适用的 OSGi 服务映射到通信端点，例如 REST 服务或 MQTT 主题。这种映射可以在不了解实际服务的情况下完成。这在远程 OSGi 服务中都是标准化的。OSGi 的动态特性提供了良好的基础，因为它为处理分布式计算的谬误提供了基础。

\n

主要的软件法则之一是内聚力。在 OSGi 中，您可以保持模块、包、类和方法的最大内聚性。

\n

为了提供锦上添花的服务，OSGi 在其本机依赖模型中集成了 \xc2\xb5services。OSGi 应用程序由数百个模块组成，这些模块通过数百个服务相互交互。模块仅依赖于明确定义的服务。服务可以由不同的模块提供，这可能很快就会变得混乱。幸运的是，OSGi 因此提供了一个解析器来选择程序集满足所有模块要求（包括服务）的模块组合

\n

总结一下。JPMS 和微服务都不是合适的模块系统。只有使用 OSGi，您才能获得真正的具有私有性并与微服务原生集成的模块系统。

\n

另请参见OSGi 服务和 REST 微服务之间的区别

\n