Différence entre OSGI et microservices
Quand souhaitez-vous choisir des modules OSGI plutôt que des micro-services et puis-je faire quelque chose avec des micro-services que je ne peux pas faire avec des modules OSGI?
OSGi et microservices partagent le même style architectural mais diffèrent par leur granularité. Nous avions l'habitude d'appeler les microservices des services OSGi jusqu'à ce que le Web vole ce nom. Nous les appelons maintenant parfois nanoservices.
Le principe des (micro | nano) services est de tunneler les communications entre les modules via un gate avec un bien défini API . Puisqu'une API est, ou du moins devrait être, indépendante des implémentations, vous pouvez modifier un module sans affecter les autres modules. L'un des avantages les plus importants est que les conceptions de systèmes même de grande taille peuvent rester compréhensibles lorsque l'on regarde le diagramme de service. D'une certaine manière, une conception basée sur les services capture l'essence du système, laissant les détails pour les modules.
Avec les services Web/micro, le gate est un point de terminaison de communication (hôte: port par exemple) et un protocole (REST par exemple). L'API est définie de manière informelle ou avec quelque chose comme Swagger/OpenAPI ou SOAP.
OSGi définit un (nano) service comme un objet mis à la disposition d'autres modules (bundles) à utiliser. Java est utilisé pour définir l'API.
Étant donné que les nanoservices sont la primitive de conception la plus importante d'OSGi, il y a beaucoup de support pour les rendre faciles à utiliser. Fait intéressant, étant donné que le registre de services est dynamique et réfléchi, il est assez simple de mapper un nanoservice à un microservice et vice versa. L'OSGi Alliance a normalisé cela dans son modèle pour OSGi distribué, le "Remote Service Admin". Cette spécification vous permet de prendre un nanoservice OSGi et de le mapper avec REST, SOAP ou d'autres protocoles.
Par conséquent, le choix d'OSGi vous permet non seulement de reporter la décision de prendre en charge les microservices, mais également d'ajouter des microservices à votre système par la suite. Le fait d'avoir un style architectural unifié pour les fonctions les plus élémentaires ainsi que les fonctions de plus haut niveau rend les systèmes plus faciles à comprendre et à mettre à l'échelle.
Je ne pense pas que vous compariez des pommes à des pommes ici. OSGI est une architecture d'application , tandis que microservices est un système distribué concept.
D'après mon expérience, les microservices offrent un certain nombre d'avantages:
- Les microservices individuels sont faciles à déployer, à tester et à entretenir.
- Les microservices sont indépendants de la langue. Cela signifie que vous pouvez écrire un microservice en python, un autre en javascript, un troisième en cours et un autre en Java.
- Les microservices sont faciles à mettre à l'échelle individuellement . Cela signifie que si un type de demande est effectué plus souvent que d'autres, vous pouvez faire évoluer le microservice dont vous avez besoin, sans faire évoluer quoi que ce soit d'autre dans le système.
- Chaque microservice de votre système possède ses propres données. Cela garantit des limites claires et une séparation des préoccupations.
Cependant, ils présentent également certains inconvénients:
- Il y a plus de problèmes d'infrastructure lors du déploiement.
- Il est difficile de garder la messagerie entre les microservices propre et efficace.
- Il est plus difficile d'effectuer des tests de bout en bout sur un système comportant de nombreuses pièces mobiles.
- Il y a plus de frais généraux dans la messagerie. Au lieu qu'un appel à un autre service soit un appel de méthode direct, il doit utiliser HTTP ou une autre forme de communication réseau.
Il y a un bon article décrivant certaines des différences ici .