Comment choisir un microservice open source ? Comparaison détaillée de Spring Cloud, Dubbo, gRPC et Istio

Auteur : Liu Jun

Que vous soyez développeur, architecte ou CTO, si vous avez été profondément impliqué dans le développement de microservices, je pense que vous devez avoir des questions sur la sélection de frameworks ou de systèmes de microservices open source : Apache Dubbo, Spring Cloud, gRPC et Service. Produits de système maillé tels qu’Istio, lequel dois-je choisir ? Cet article fournit une description détaillée de ces frameworks et donne quelques conseils sur la sélection de modèles, qui, je pense, peuvent aider les développeurs de microservices.

Il convient de noter que l'auteur de cet article a une expérience approfondie de la participation à la communauté Apache Dubbo, donc l'intégralité de l'article est basée sur Dubbo. En montrant de manière objective et transparente les connexions et les différences entre Dubbo et d'autres composants, Présentez aux lecteurs les avantages et les scénarios applicables de plusieurs produits open source. Une partie de l'article entier met en évidence les avantages du projet Apache Dubbo. Veuillez garder cela à l'esprit pendant le processus de lecture, mais cela n'affecte pas notre compréhension globale de chaque produit et la sélection des options précieuses du guide.

Dubbo 与 Nuage de printemps

D'après la figure ci-dessus, nous pouvons voir que Dubbo et Spring Cloud présentent de nombreuses similitudes, ils sont tous deux dans la même position dans l'ensemble du diagramme d'architecture et fournissent des fonctions similaires.

Dubbo et Spring Cloud se concentrent tous deux sur l'abstraction des modèles de problèmes courants dans les systèmes distribués (tels que la découverte de services, l'équilibrage de charge, la configuration dynamique, etc.) et fournissent des implémentations de composants de support pour chaque problème, formant un ensemble de solutions globales de microservices. permet aux utilisateurs utilisant Dubbo et Spring Cloud de se concentrer sur le développement de la logique métier lors du développement d'applications de microservices.
Dubbo et Spring Cloud sont tous deux entièrement compatibles avec le modèle de développement d'applications du système Spring. Dubbo a fait une bonne adaptation au cadre de développement d'applications Spring et au cadre de microservices Spring Boot. Puisque Spring Cloud vient du système Spring, il n'est pas nécessaire pour en savoir plus sur ce point, expliquez.

Bien qu'il existe de nombreuses similitudes entre les deux, en raison des énormes différences dans leur contexte de naissance et leur conception architecturale, ils sont très différents en termes de performances, d'échelle de cluster de microservices applicable, de garantie de stabilité de production, de gouvernance des services, etc.

Les avantages de Spring Cloud sont :

Bien que les deux prennent en charge le système de développement Spring, Spring Cloud bénéficie d'un support plus natif.
Certains modèles de microservices couramment utilisés sont résumés, tels que la découverte de services, la configuration dynamique, les messages asynchrones, etc., et certaines tâches par lots, tâches de synchronisation, accès aux données persistantes et autres domaines sont également couverts.
Le modèle de communication basé sur HTTP+JSON est plus convivial et moins cher pour le développement, les tests, l'accès au système en amont et en aval, etc.
Spring Cloud propose officiellement des documents d'introduction relativement complets, des démonstrations et des démarreurs, y compris des livres et du matériel, etc., ce qui facilite le démarrage des développeurs.

Les problèmes avec Spring Cloud sont :

Il fournit uniquement la définition de modèles abstraits et ne fournit pas d'implémentations stables officielles. Les développeurs ne peuvent rechercher des suites d'implémentation que auprès de différents fournisseurs tels que Netflix, Alibaba et Azure, et chaque fournisseur prend en charge différents degrés d'exhaustivité, de stabilité et d'activité.
Il existe un Family Bucket de microservices, mais ce n'est pas un Family Bucket qui peut être utilisé immédiatement. La démo est facile à démarrer, mais le coût de mise en œuvre et d'utilisation à long terme n'est pas faible.
Manque de capacités de gouvernance des services, en particulier dans la gestion et le contrôle du trafic tels que l'équilibrage de charge et le routage du trafic.
Le modèle de programmation et le protocole de communication sont liés au HTTP, ce qui présente des obstacles en termes de performances et d'interopérabilité avec d'autres systèmes RPC.
L'architecture globale et la mise en œuvre sont plus adaptées à la pratique de clusters de microservices à petite échelle. Lorsque la taille du cluster augmente, divers goulots d'étranglement tels que l'efficacité du push d'adresses et l'utilisation de la mémoire seront rencontrés, mais il est difficile de migrer vers d'autres systèmes pour le moment. .
Les problèmes de haut niveau dans les scénarios de pratique des microservices doivent être résolus par les utilisateurs eux-mêmes, tels que l'arrêt progressif, le préchauffage du démarrage, les tests de service, le double enregistrement, le double abonnement, l'enregistrement retardé, l'isolement du service par groupe, la tolérance aux pannes de cluster, etc.

Au vu des points ci-dessus, voici les avantages de Dubbo :

Il prend entièrement en charge le modèle de développement Spring & Spring Boot et fournit des fonctionnalités équivalentes à Spring Cloud dans des modèles de base tels que la découverte de services et la configuration dynamique.
Il s'agit du résultat global du plan de pratique des microservices au niveau de l'entreprise. Dubbo prend en compte divers problèmes rencontrés dans la pratique des microservices d'entreprise, tels que l'élégance en ligne et hors ligne, les centres d'enregistrement multiples, la gestion du trafic, l'isolement anormal des instances, etc. son utilisation à long terme dans l'environnement de production Les coûts de maintenance sont inférieurs.
Le choix des protocoles de communication et des encodages est plus flexible, y compris les protocoles de couche de communication RPC tels que Triple (gRPC, compatible HTTP/1), le protocole binaire TCP, REST, etc., les protocoles d'encodage de sérialisation Protobuf, JSON, Hessian2, etc., et prend en charge le multiprotocole à port unique.
La conception de Dubbo met en évidence les capacités de gouvernance des services, telles que l'ajustement dynamique du poids, le routage des étiquettes, le routage conditionnel, etc., et prend en charge plusieurs modes tels que Sidecar et Proxyless pour accéder au système Service Mesh.
Codage et mise en œuvre du protocole RPC hautes performances.
Dubbo est un cadre développé dans le cadre d'un scénario pratique de clusters de microservices à très grande échelle. Il peut réaliser une expansion horizontale de clusters à l'échelle de millions d'instances et faire face à divers problèmes causés par la croissance des clusters.
Dubbo fournit des implémentations multilingues autres que Java, permettant de créer des systèmes de microservices hétérogènes multilingues tels que Java, Go, Node.js, Rust et Web.

Si votre objectif est de créer des applications de niveau entreprise et que vous espérez être plus serein et plus stable lors des futures maintenances à long terme, nous vous recommandons de mieux comprendre l'utilisation de Dubbo et les fonctionnalités qu'il offre.

Dubbo dans gRPC

Concernant les différences entre ces deux produits open source, on peut partir de deux aspects : le positionnement du produit et la comparaison des protocoles :

Différences de positionnement des produits

La plus grande différence entre Dubbo et gRPC réside dans leur positionnement :

gRPC se positionne comme un framework RPC . Google l'a lancé avec pour objectif principal de définir les spécifications de communication RPC et la mise en œuvre standard à l'ère du cloud natif ;
Dubbo se positionne comme un cadre de développement de microservices , qui se concentre sur la résolution des problèmes de pratique des microservices depuis la définition des services, le développement, la communication jusqu'à la gouvernance. Par conséquent, Dubbo fournit également la communication RPC, l'adaptation au cadre de développement d'applications, la gouvernance des services et d'autres capacités.

Dubbo n'est pas lié à un protocole de communication spécifique, c'est-à-dire que les services Dubbo peuvent communiquer via divers protocoles RPC et prendre en charge une commutation flexible. Par conséquent, vous pouvez choisir la communication gRPC dans le microservice développé par Dubbo. Dubbo peut être entièrement compatible avec gRPC via le protocole Triple, et le protocole de communication gRPC est l'un des protocoles de support natifs intégrés.

Différences de protocole

Le triple protocole est une spécification de protocole de communication RPC basée sur HTTP conçue par Dubbo3. Il est entièrement compatible avec le protocole gRPC, prend en charge les modèles de requête-réponse, de streaming et d'autres modèles de communication, et peut fonctionner simultanément sur HTTP/1 et HTTP/2.

Le framework Dubbo fournit des implémentations multilingues du protocole Triple, qui peuvent vous aider à créer des interfaces API HTTP compatibles avec les navigateurs et gRPC : il vous suffit de définir un service au format Protocol Buffer standard et d'implémenter une logique métier, et Dubbo est chargé d'aider à générez un stub de serveur et un stub de client liés au langage et connectez de manière transparente l'ensemble du processus d'appel aux systèmes Dubbo tels que le routage et la découverte de services. Les implémentations de triple protocole dans des langages tels que Go et Java prennent en charge nativement la communication de la couche de transport HTTP/1. Par rapport à l'implémentation officielle de gRPC, l'implémentation de protocole fournie par le framework Dubbo est plus simple et plus stable, vous aidant à développer et à gérer des microservices. applications plus facilement.

Pour certaines versions du langage, le framework Dubbo fournit également un mode de programmation plus conforme aux caractéristiques du langage, c'est-à-dire un mode de définition et de développement de services qui ne lie pas IDL. Par exemple, dans Dubbo Java, vous pouvez choisir d'utiliser Java Interface et classe Pojo pour définir les services Dubbo et les publier en tant que microservice basé sur la communication triple protocole.

Comme mentionné ci-dessus, Triple est entièrement compatible avec le protocole gRPC. Puisque gRPC fournit officiellement une implémentation de framework multilingue, pourquoi Dubbo le ré-implémente-t-il via Triple ? Il y a deux objectifs principaux :

Tout d'abord, en termes de conception de protocole, Dubbo a conçu un protocole Triple personnalisé en référence aux deux protocoles gRPC et gRPC-Web : Triple est un protocole RPC basé sur le protocole de couche de transport HTTP, il est entièrement compatible avec gRPC et peut s'exécuter sur HTTP/1, au-dessus de HTTP/2.
Deuxièmement, le framework Dubbo suit un concept de conception qui correspond au positionnement propre du framework dans le processus d'implémentation de chaque langage. Par rapport aux bibliothèques-framework telles que grpc-java et grpc-go, l'implémentation du protocole Dubbo est plus simple et plus pure, et tente d'éviter les problèmes de mise en œuvre. Une série de problèmes existent dans la bibliothèque officielle gRPC.

En utilisant le framework Dubbo et en activant le protocole Triple, la couche inférieure peut être compatible avec les microservices du protocole gRPC. Les développeurs développent des services basés sur l'API et la configuration fournies par Dubbo, et gèrent les services en fonction des capacités de gouvernance des services de Dubbo. Dans le même temps, par rapport au protocole gRPC natif, le protocole Triple facilite le débogage et l'accès frontal en prenant en charge cURL et l'accès direct au navigateur.

curl \
    --header "Content-Type: application/json" \
    --data '{"sentence": "Hello Dubbo."}' \
    https://host:port/org.apache.dubbo.sample.GreetService/sayHello

Dubbo et Istio

La grille de services Service Mesh est une architecture de microservices née dans le contexte du cloud natif ces dernières années. Sous le système Kubernetes, le maillage de services permet à davantage de capacités de développement de microservices, telles que l'interception du trafic et la gouvernance des services, de couler et de devenir la base des installations, ce qui en fait faciliter le développement et la mise à niveau des microservices. Istio est une implémentation open source représentative de Service Mesh. Elle est divisée en plan de données et plan de contrôle en termes d'architecture de déploiement. De ce point de vue, elle est fondamentalement cohérente avec l'architecture globale de Dubbo. Les principaux changements apportés par Istio sont :

Du côté des données, Istio parvient à une interception transparente du trafic de service en introduisant Sidecar. Sidecar est généralement déployé avec des composants de microservices traditionnels développés par Dubbo et d'autres.
Le plan de contrôle regroupe le centre de gouvernance des services auparavant abstrait en un composant spécifique avec une mise en œuvre unifiée et permet une adaptation transparente à l'infrastructure sous-jacente telle que Kubernetes.

Dubbo a obtenu un accès complet au système Istio et peut utiliser le plan de contrôle Istio pour gérer les services Dubbo. En termes d'architecture de déploiement du plan de données, Dubbo prend également en charge le mode sans agent sans proxy pour résoudre les problèmes de complexité et de performances introduits par Sidecar. De plus, le système Dubbo Mesh résout également de nombreux problèmes liés à la mise en œuvre de l'architecture Istio, notamment en fournissant une architecture de déploiement de plan de données plus flexible et des coûts de migration réduits.

Du point de vue du plan de données , Dubbo prend en charge les deux modes de développement et de déploiement suivants et peut mettre en œuvre la gouvernance des services de plan de données via des composants de plan de contrôle tels qu'Istio.

En mode proxy, Dubbo est déployé avec Envoy. Dubbo existe en tant que composant de cadre de programmation et de protocole de communication. Le contrôle du trafic est mis en œuvre par l'interaction entre Envoy et le plan de contrôle Istio.
En mode sans proxy, le processus Dubbo reste déployé indépendamment et Dubbo se connecte directement aux composants du plan de contrôle tels qu'Istio via le protocole xDS standard.

Du point de vue du plan de contrôle , Dubbo peut être connecté au plan de contrôle et au système de règles standard natifs d'Istio.Pour certains utilisateurs de l'ancienne version de Dubbo, la communauté travaillera avec les utilisateurs d'entreprise pour lancer conjointement un plan de migration fluide pour la version communautaire.

Résumer

Cet article prend Dubbo comme point de départ et présente en détail plusieurs produits-cadres tels que Spring Cloud, Dubbo, gRPC et Istio ainsi que leurs avantages et différences respectifs.Je pense que cela sera utile pour notre sélection de technologies de microservices. Mais comme nous l'avons mentionné au début, cet article extrait certains points essentiels d'Apache Dubbo, donc l'intégralité de l'article est basé sur Dubbo. Une partie de l'article met en évidence les avantages du projet Apache Dubbo. À l’avenir, nous continuerons à nous développer dans des dimensions plus différentes pour vous proposer des comparaisons de produits et des conseils plus dimensionnels.