OSGi 服务和 REST 微服务之间的区别 [关闭]

Posted 2023-02-22

【中文标题】OSGi 服务和 REST 微服务之间的区别 [关闭]

【英文标题】：Difference between OSGi services and REST microservices [closed]

【发布时间】：2018-09-01 17:59:18

【问题描述】：

OSGi 谈论微服务，媒体谈论微服务。但是，它们似乎并不相同。这些微服务有什么区别。

【问题讨论】：

“有什么我可以用微服务做而我不能用 OSGI 模块做的吗”：您可以解决许多非常复杂的问题（事务、会话处理、来自节点之间的通信的性能问题等），如果您没有选择微服务，您将不会拥有。

这个问题对我来说似乎很好，我认为应该重新打开它。

【参考方案1】：

OSGi 和微服务共享相同的架构风格，但它们的粒度不同。我们实际上曾经将 OSGi 服务称为微服务，直到网络窃取了该名称。我们现在有时称它们为 nanoservices。

（微|纳米）服务的原理是通过具有良好定义的API 的门 隧道模块之间的通信。由于 API 独立于或至少应该独立于实现，因此您可以更改一个模块而不影响其他模块。最重要的好处之一是即使是大型系统的设计在查看服务图时也可以保持可理解性。在某种程度上，基于服务的设计抓住了系统的本质，将细节留给了模块。

对于网络/微服务，gate 是一个通信端点（例如主机：端口）和协议（例如 REST）。 API 是非正式定义的，或者使用 Swagger/OpenAPI 或 SOAP 之类的东西定义。

OSGi 将（纳米）服务定义为可供其他模块（捆绑包）使用的对象。 Java 用于定义 API。

由于纳米服务是 OSGi 最重要的设计原语，因此有很多支持使它们易于使用。有趣的是，由于服务注册表是动态的和反射的，因此将纳米服务映射到微服务非常简单，反之亦然。 OSGi 联盟在他们的分布式 OSGi（“远程服务管理员”）模型中对此进行了标准化。此规范允许您获取 OSGi 纳米服务并将其映射到 REST、SOAP 或其他协议。

因此，选择 OSGi 不仅可以让您推迟决定是否支持微服务，还可以让您事后将微服务添加到您的系统中。为最基本的功能和***别的功能提供统一的架构风格，使系统更易于理解和扩展。

【讨论】：

你的意思是在OSGI的帮助下“对最基本的功能有一个统一的架构风格”和在微服务的帮助下“通过***别的功能”？

将一切都变成微服务需要网络调用开销，因此我们应该借助 OSGI 将高级功能分解为微服务和低级基本功能。因此我们可以使用混合方法来避免网络调用开销

正确。 OSGi 不仅允许您使用一种范例，还允许您使用相同的代码结构来完成低级和高级的工作。 IE。 REST API 成为一种选择。

err ... 这不是一个好的旧 RPC 系统的描述吗？将“nano service”替换为“remote procedure”……“gate”存在的原因似乎不清楚？这是一个逻辑单元，又名微服务集群还是技术必需品？顺便说一句，我喜欢您的抽象级别和一致的定义。以防万一我没有。

实际上这也可能是对 SmallTalk 运行时环境的描述，但术语不同。对象 + 消息，SmallTalk 概念，对我来说似乎很像微/纳米服务.. 嗯，再次了解支持您的架构的历史是件好事。

【参考方案2】：

我不认为您在这里将苹果与苹果进行比较。 OSGI 是一个应用程序 架构，而microservices 是一个分布式系统 概念。

根据我的经验，微服务提供了许多好处：

单个微服务易于部署、测试和维护。 微服务与语言无关。这意味着您可以用 python 编写一个微服务，用 javascript 编写另一个微服务，用 go 编写第三个微服务，然后再用 java 编写另一个。 微服务易于单独扩展。这意味着，如果一种类型的请求比其他类型的请求更频繁，您可以扩展所需的微服务，而无需扩展系统中的任何其他内容。 系统中的每个微服务都拥有自己的数据。这确保了清晰的边界和关注点的分离。

但是，它们也有一些缺点：

部署时存在更多基础架构问题。 很难保持微服务之间的消息传递干净高效。 在具有许多移动部件的系统上进行端到端测试更加困难。 消息传递的开销更大。它需要使用 HTTP 或其他某种形式的网络通信，而不是对另一个服务的调用是直接的方法调用。

有一篇很好的文章描述了here 的一些差异。

【讨论】：

我想说，从您的好处列表中，只有第 2 个（语言不可知论）实际上是 OSGi 微服务与进程微服务的限制。 OSGi 微服务可以独立部署、独立扩展，可以拥有自己的数据。它们目前仅限于 JVM 和在 JVM 上运行的语言：Java、Scala、Groovy、Closure、JR​​uby 等。