Nuestro grupo de redactores ha pasado horas buscando la respuesta a tu pregunta, te dejamos la soluciones por esto deseamos que sea de mucha ayuda.
Solución:
OSGi y los microservicios comparten el mismo estilo arquitectónico pero difieren en su granularidad. De hecho, solíamos llamar microservicios a los servicios OSGi hasta que la web robó ese nombre. Ahora a veces los llamamos nanoservicios.
El principio de los (micro|nano)servicios es tunelizar las comunicaciones entre módulos a través de un portón con un bien definido API. Dado que una API es, o al menos debería ser, independiente de las implementaciones, puede cambiar un módulo sin afectar a los otros módulos. Uno de los beneficios más importantes es que los diseños de incluso los sistemas más grandes pueden seguir siendo comprensibles cuando se observa el diagrama de servicio. En cierto modo, un diseño basado en servicios captura la esencia del sistema, dejando los detalles para los módulos.
Con servicios web/micro, el portón es un punto final de comunicación (host:puerto por ejemplo) y protocolo (REST por ejemplo). La API se define de manera informal o con algo como Swagger/OpenAPI o SOAP.
OSGi define un (nano) servicio como un objeto que se pone a disposición de otros módulos (paquetes) para su uso. Java se utiliza para definir la API.
Dado que los nanoservicios son la primitiva de diseño más importante de OSGi, hay mucho soporte para que sea fácil trabajar con ellos. Curiosamente, dado que el registro de servicios es dinámico y reflexivo, es bastante sencillo asignar un nanoservicio a un microservicio y viceversa. OSGi Alliance estandarizó esto en su modelo para OSGi distribuido, el “Administrador del servicio remoto”. Esta especificación le permite tomar un nanoservicio OSGi y asignarlo a REST, SOAP u otros protocolos.
Por lo tanto, elegir OSGi le permite no solo aplazar la decisión de admitir microservicios, sino que también le permite agregar microservicios a su sistema posteriormente. Tener un estilo arquitectónico unificado para las funciones más básicas, así como las funciones de más alto nivel, hace que los sistemas sean más fáciles de entender y escalar.
No creo que estés comparando manzanas con manzanas aquí. OSGI es un solicitud arquitectura, mientras microservices es un sistemas distribuidos concepto.
En mi experiencia, los microservicios ofrecen una serie de beneficios:
- Los microservicios individuales son fáciles de implementar, probar y mantener.
- Los microservicios son independientes del idioma. Eso significa que podría escribir un microservicio en python, otro en javascript, un tercero en go y otro en java.
- Los microservicios son fáciles de escalar individualmente. Eso significa que si un tipo de solicitud se realiza con más frecuencia que otras, puede escalar el microservicio que necesita, sin escalar nada más en el sistema.
- Cada microservicio en su sistema posee sus propios datos. Esto asegura límites claros y separación de preocupaciones.
Sin embargo, también tienen algunos inconvenientes:
- Hay más preocupaciones de infraestructura cuando se implementa.
- Es difícil mantener la mensajería entre microservicios limpia y eficiente.
- Es más difícil realizar pruebas de extremo a extremo en un sistema con muchas partes móviles.
- Hay más gastos generales en la mensajería. En lugar de que una llamada a otro servicio sea una llamada de método directo, necesita usar HTTP o alguna otra forma de comunicación de red.
Hay un buen artículo que describe algunas de las diferencias aquí.
Acuérdate de que tienes la opción de aclarar si te fue de ayuda.