À l'époque, j'étais développeur IBM Integration Bus (IIB) - alors connu sous le nom d'IBM WebSphere Message Broker. Je développerais des flux de messages pour connecter divers nœuds d'entrée, de sortie et de traitement. Ce style de développement, bien sûr, s'étend également à d'autres fournisseurs ESB; donc, cette question ne perd pas sa généralité.
Le moteur de messagerie pour IIB est WebSphere MQ (WMQ) qui fournit la communication sous forme de messages dans une file d'attente ou sous forme de rubriques. Avec la logique interne dans IIB, les nœuds communiquent entre eux en passant des messages. Un IIB / WMQ typique possède également un mécanisme d'installation HA bien documenté. De plus, si un flux de messages expose un point de terminaison HTTP (S), il pourrait également le faire derrière un équilibreur de charge.
De même, on peut parler d'autres technologies qui ont fait partie de l'ère SOA. Par conséquent, ma question est, si je
Alors, pourquoi ai-je besoin d'Istio - à part une «architecture basée sur des conteneurs purs»?
3 Réponses :
Istio implémente le modèle side-car à coupler à chaque microservice. Les microservices (pas nécessairement mais généralement) sont déployés dans des infrastructures qui permettent une mise à l'échelle élastique, dans laquelle le système se voit déléguer la tâche d'ajuster le nombre d'instances de chaque microservice en fonction de la stratégie de mise à l'échelle configurée. Cela signifie que le nombre de conteneurs à un moment donné est prévisible et en même temps inconnu à court terme.
Istio résout le problème de l'abstraction des microservices des tâches purement d'infrastructure et les laisse se concentrer uniquement sur le plan fonctionnel, et en même temps, il est capable de s'adapter de manière élastique avec les conteneurs auxquels il est attaché.
Déléguer cette tâche à un ESB n'est pas impossible, mais à mon avis, cela introduirait un facteur de complexité assez élevé. Peut-être avez-vous trouvé une opportunité commerciale ;-)
IIB avait auparavant une architecture monolithique et les liens associés à IIB fournis aideraient à créer une architecture haute disponibilité. Les offres récentes d'ESB (tout fournisseur) a consisté à déployer l'ESB en tant que microservices. Plus précisément, en ce qui concerne IIB, nous pouvons exécuter chaque groupe d'exécution (serveur d'intégration) en tant que conteneur. Avec cela, vous avez toutes sortes d'avantages d'une architecture de microservices. Bien sûr, comme mentionné, vous pouvez également avoir ces microservices ESB pour faire de l'orchestration.
Mais pour toute entreprise qui a une architecture basée sur des microservices à travers ses diverses applications et pas seulement ESB en tant que conteneurs, c'est très difficile à gérer, sécuriser, observer, etc. Surtout lorsque les microservices continuent de croître avec des milliers de ceux-ci en cours d'exécution dans une entreprise. C'est là qu'Istio pourrait aider.
Avec les groupes d'exécution IIB comme conteneurs, qui effectue l'orchestration? IIB lui-même?
Oui, IIB continuerait à faire ce qu'il fait, juste la façon dont il exécute les changements au lieu d'un grand monolithe qu'il exécute maintenant en tant que microservice. Ci-dessous un lien pour plus de détails: developer.ibm.com/integration/blog/2018/01/12/...
La réponse TLDR est qu'istio est plus flexible et n'essaie pas de rendre les microservices entièrement dépendants d'istio, alors que la pile IIB était principalement "une fois que vous êtes entré, vous ne pouvez pas sortir sans projet de migration".