OSGi 服务和 REST 微服务之间的区别

本文介绍了OSGi 服务和 REST 微服务之间的区别的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

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

OSGi talks about microservices and the press talks about microservices. However, they do not seem to be the same. What is the difference between these microservices.

推荐答案

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

OSGi and microservices share the same architectural style but differ in their granularity. We actually used to call OSGi services microservices until the web stole that name. We now sometimes call them nanoservices.

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

The principle of (micro|nano)services is to tunnel the communications between modules through a gate with a well defined API. Since an API is, or at least should be, independent of the implementations you can change one module without affecting the other modules. One of the most important benefits is that designs of even large systems can remain understandable when looking at the service diagram. In a way, a service based design captures the essence of the system, leaving the details for the modules.

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

With web/micro services the gate is a communication endpoint (host:port for example) and protocol (REST for example). The API is defined informally or with something like Swagger/OpenAPI or SOAP.

OSGi 将(纳米)服务定义为可供其他模块(包)使用的对象.使用 Java 来定义 API.

OSGi defines a (nano) service as an object that is made available to other modules (bundles) to use. Java is used to define the API.

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

Since nanoservices are OSGi most important design primitive there is a lot of support to make them easy to work with. Interestingly, since the service registry is dynamic and reflective, it is quite straightforward to map a nanoservice to a microservice and vice versa. The OSGi Alliance standardized this in their model for distributed OSGi, the "Remote Service Admin". This specification allows you to take an OSGi nanoservice and map it to REST, SOAP, or other protocols.

因此，选择 OSGi 不仅可以让您推迟支持微服务的决定，还可以让您事后向系统添加微服务.对最基本的功能和最高级别的功能采用统一的架构风格，使系统更易于理解和扩展.

Therefore, choosing OSGi allows you not only to defer the decision to support microservices, it also allows you to add microservices to your system afterwards. Having a unified architectural style for the most basic functions as well as the highest level functions makes systems easier to understand as well scale.