2
votes

Utilisation d'Apache Camel dans une architecture de microservice

J'ai observé une tendance croissante de personnes utilisant Apache Camel dans une architecture de microservice. Par exemple, sur OpenShift Container Platform.

J'ai beaucoup de mal à comprendre pourquoi un Enterprise Service Bus, un monolithique fondamental, peut être utilisé dans une architecture de microservices.

Peut-être qu'Apache Camel est utilisé à des fins d'orchestration? Mais cela va à l'encontre de l'esprit des microservices.

Quelqu'un peut-il m'éclairer à ce sujet, s'il vous plaît? Je ne peux pas comprendre ça.


4 commentaires

Apache Camel n'est pas un ESB mais un framework d'intégration (en gros, Camel n'est qu'un ensemble de JAR que vous ajoutez à votre application existante et que vous les intégrez ensemble). Il existe de nombreux articles, vidéos, blogs, etc. sur l'utilisation de Camel avec l'architecture de microservices et les technologies de conteneurs. Vous pouvez supposer que Camel est un ESB ou un soft de celui-ci, car Camel a été créé il y a 11 ans - mais malgré cela, il a toujours été conçu pour un cadre d'intégration léger. Et il a été utilisé comme moteur dans certains ESB comme ServiceMix et certains produits de fournisseurs commerciaux.


merci, je suppose qu'Apache Camel fonctionnera dans un conteneur et servira de routage pour d'autres microservices déployés dans d'autres conteneurs?


Vous pouvez exécuter des itinéraires de chameaux dans vos conteneurs pour les intégrer à d'autres technologies. Par exemple, faire une conversion SOAP en REST serait facile.


Yeah Camel fonctionne avec votre microservice - (tout comme un ensemble de JAR supplémentaires sur le chemin de classe) et avec Camel, vos microservices peuvent facilement faire l'intégration, le routage et les fonctionnalités fournies par Camel.


3 Réponses :


2
votes

J'ai beaucoup de mal à comprendre pourquoi un Enterprise Service Bus, un monolithique fondamental, peut être utilisé dans une architecture de microservices.

ESB dispose de plusieurs fonctionnalités utiles pour l'architecture de microservices. Il permet:

  • médiation et transformation des messages, voir Modèles d'intégration d'entreprise
  • Application des règles interservices (par exemple, sécurité au niveau des messages, autorisation, ..)
  • découplage du point de terminaison de service de son implémentation (gestion des versions de service)
  • fournit des services de base tels que la messagerie, la gestion des événements, la surveillance, la gestion des exceptions, ..
  • atténuer la communication point à point
  • .. encore plus ..

En effet, l'ESB fonctionne généralement comme une application séparée (ou un conteneur dans votre cas) et après avoir implémenté toutes les fonctionnalités, ce n'est pas toujours l'application la plus légère (comparée à de simples microservices à usage unique). S'il est mis en œuvre correctement, ESB devrait avoir un impact minimal sur la latence de réponse ou la charge de l'infrastructure.

Fournissant des services de base et des capacités interservices À mon humble avis, vous pouvez considérer ESB non pas comme un service séparé, mais comme une partie des services d'infrastructure utilisables par les implémentations de microservices.

Peut-être qu'Apache Camel est utilisé à des fins d'orchestration? Mais cela va à l'encontre de l'esprit des microservices.

Apache Camel est un framework, il peut être utilisé dans une application, autonome ou aussi il existe des produits ESB construits sur Apache Camel (RedHat Fuse ESB, Talend ESB, Apache ServiceMix, ..).


0 commentaires

2
votes

Apache Camel n'est pas un ESB . Au lieu de cela, il s'agit d'un cadre d'intégration léger avec de nombreux connecteurs pour les bases de données, les files d'attente de messages, les plates-formes de streaming et les API populaires. Il prend également en charge près de 50 formats de données et prend en charge plusieurs environnements d'exécution, y compris Springboot et la prise en charge de Quarkus avec Camel 3. < / p>

Pourquoi est-ce idéal pour les microservices?

  • Prise en charge de Springboot et prise en charge de Quarkus (impossible d'obtenir un micro que cet atm).
  • Chaque microservice doit communiquer avec d'autres services ou avec le monde extérieur et la boîte à outils d'intégration de Camel avec plusieurs composants, les formats de données facilitent les choses.
  • Le REST DSL facilite la création d'une interface REST
  • Les composants JMS et Kafka facilitent le développement de microservices événementiels.
  • La prise en charge d'OpenTracing permet le traçage distribué.
  • Les métriques exportées via JMX (peuvent être utilisées avec l'exportateur prometheus jmx) aident à instrumenter vos applications chameaux.

J'espère que cela vous aidera.


0 commentaires

0
votes

Camel a un DSL java / kotlin pour écrire des flux et des services d'orchestration.

Camel dispose d'un ensemble de composants d'intégration qui permet de s'intégrer à différents points de terminaison / protocoles.

Le DSL vous donne un "langage" standard pour écrire des flux d'orchestration - en utilisant le modèle fluide.

Camel dispose également d'un cadre de test qui facilite l'écriture de tests de flux et de simulations de points de terminaison.

Camel prend en charge comment gérer les exceptions, réessayer, idempontent consommateur ( https : //camel.apache.org/components/latest/eips/idempotentConsumer-eip.html )

Camel implémente un ensemble de modèles d'intégration d'entreprise, voir https://camel.apache.org/components/latest /eips/enterprise-integration-patterns.html

Lors de la création de nombreux microservices, sans regrouper les services, cela peut devenir un peu compliqué ...

Camel vous offre un outil supplémentaire qui relie tous ensemble.

Il ne faut pas mélanger cela avec le streaming ou la programmation réactive, l'API de streaming Kafka et donc weiter .... c'est une couche sur ce truc ....


0 commentaires