Quelle est la méthode de conception globale de l’architecture Java Dubbo ?

1. Description de la relation d'appel Dubbo

1.1 Composants

Ici, elle se compose principalement de quatre parties :

weight Fournisseur : le fournisseur de services qui expose le service
Protocole : responsable des fournisseurs et consommateurs Données d'interaction de protocole entre les fournisseurs
Service : informations de service métier réelles, qui peuvent être comprises comme des interfaces et des implémentations
Conteneur : l'environnement d'exploitation de Dubbo
weight Consommateur : le consommateur de services qui appelle les services distants
Protocole : responsable de la relation entre le fournisseur et les données d'interaction du protocole consommateur entre
Cluster : perçoit les informations de liste du côté du fournisseur
Proxy : il peut être compris comme le proxy d'appel de service du fournisseur, qui reprend la logique d'appel de l'interface dans le consommateur
Quantity Register : centre d'enregistrement, utilisé pour découverte et routage des services Configuration et autres travaux, les fournisseurs et les consommateurs s'enregistreront ici
● Moniteur : utilisé pour les statistiques de données sur les fournisseurs et les consommateurs, telles que la fréquence des appels, le nombre de réussites et d'échecs, etc.

1.2 Description du processus de démarrage et d'exécution

● Le côté fournisseur est démarré et le conteneur est responsable du chargement des informations sur le service et de leur enregistrement dans le centre d'enregistrement via le protocole.
● Le côté consommateur est démarré, détectant les informations du fournisseur en écoutant la liste des fournisseurs et lorsque le côté fournisseur est démarré. les changements de fournisseur seront notifiés via le centre d'enregistrement en temps opportun. Informer le consommateur
Quantity Le consommateur initie une demande via le module Proxy
weight Le consommateur utilise le module Cluster pour sélectionner le véritable fournisseur à appeler ; le consommateur utilise le protocole dans le consommateur pour envoyer des informations au fournisseur ;
Quantity Les informations du consommateur du fournisseur sont traitées via le module Protocole
Quantity ; Enfin, elles sont traitées par le service du fournisseur

2. Lien d'appel global

Description ; : Le vert clair représente la portée du producteur du service, le bleu clair représente le consommateur du service La portée de l'appelant, la flèche rouge représente la direction de l'appel : couche de logique métier -> couche RPC (appel de procédure distante) -> Remoting (appel de procédure distante) transmission de données)

Le processus d'appel global est le suivant :

Quantity Les consommateurs l'effectuent via l'interface. Les appels de méthode sont uniformément transmis au proxy du côté du consommateur et les objets proxy sont créés via la technologie javassist de ProxyFactory. jdk est utilisé ici

Quantity et transmis au module Filter pour effectuer des requêtes de filtrage unifiées
Quantity Vient ensuite la logique d'appel de l'invoker la plus importante
○ Lisez les informations de la configuration via l'annuaire, et enfin obtenez tous les invokers via la méthode de liste
○ Grâce le module Cluster, sélectionnez la liste des Invokers en fonction des règles de routage spécifiques sélectionnées
○ Via le module LoadBalance, sélectionnez un Invoker spécifique en fonction de la politique d'équilibrage de charge. Traitement de la requête
○ Si une erreur se produit lors de l'exécution et que le mécanisme de nouvelle tentative est configuré à l'étape Consommateur, l'exécution sera réessayée
Quantity Continuez à passer par le filtre pour encapsuler la fonction d'exécution avant et après, et l'invoker sélectionne le protocole d'exécution spécifique
gip Le client effectue l'encodage et le séquençage, puis envoie les données
● Atteignez la couche Serveur dans le Fournisseur pour décoder et sérialiser les données reçues
Quantity Utilisez l'Exportateur pour sélectionner l'exécuteur
● Laissez le Filtre effectuer un filtrage côté fournisseur et atteindre l'exécuteur de l'Invoker
● Pass Invoker appelle l'implémentation spécifique du interface, puis renvoie le résultat

3. Conception globale de Dubbo

Description de la légende :

● Le fond bleu clair à gauche sur l'image est l'interface utilisée par le consommateur du service, et la lumière fond vert à droite L'interface utilisée par le prestataire L'interface située sur l'axe central est utilisée par les deux parties.

Quantity La figure est divisée en dix couches de haut en bas. Chaque couche a des dépendances unidirectionnelles. La flèche noire à droite représente la relation de dépendance entre les couches. Chaque couche peut être supprimée de la couche supérieure et réutilisée. Les couches de configuration sont des API. , toutes les autres couches sont des SPI
● Les blocs verts dans la figure sont des interfaces d'extension et les blocs bleus sont des classes d'implémentation. La figure montre uniquement les classes d'implémentation utilisées pour associer chaque couche
● La ligne pointillée bleue dans. La figure est le processus d'initialisation, c'est-à-dire la chaîne d'assemblage au démarrage. La ligne continue rouge est le processus d'appel de la méthode, c'est-à-dire la chaîne d'appel d'exécution. La flèche violette est l'héritage. la classe parente. Le texte sur la ligne est la méthode appelante.

La conception globale du code source de Dubbo est très similaire au lien appelant. Cependant, vous pouvez voir ici quelques implémentations spécifiques de l'interface et une division hiérarchique plus détaillée sur la gauche. Nous nous concentrerons également sur les implémentations de modules les plus importantes dans l'analyse ultérieure du code source.

Les éléments suivants seront introduits par couches

1. Couche de logique métier
Quantity Couche métier de service : y compris le code métier tel que les interfaces et les classes d'implémentation
2 Couche RPC : couche d'appel de procédure à distance
weight Couche de configuration de configuration, qui fournit la configuration au monde extérieur. le noyau, il peut être directement Initialiser la classe de configuration, et également analyser le fichier de configuration
● Couche proxy du service proxy, qu'il s'agisse d'un producteur ou d'un consommateur, le framework générera une classe proxy L'ensemble du processus est transparent pour la couche supérieure. , et la couche métier est indifférente aux appels à distance
● Couche du centre d'enregistrement d'enregistrement , encapsule l'enregistrement et la découverte des adresses de service, centrées sur l'URL du service
● Couche de routage de cluster (couche de tolérance aux pannes du cluster), assure le routage et l'équilibrage de charge de plusieurs fournisseurs, et il relie le centre d'enregistrement avec Invoker comme centre
● Couche de surveillance, les informations relatives aux appels RPC, telles que le nombre d'appels, les situations de panne, l'heure de l'appel et d'autres informations statistiques seront collectées au niveau de cette couche
●. La couche d'appel à distance du protocole encapsule les appels RPC, qu'il s'agisse d'une exposition de service ou d'une référence de service. Il s'agit de l'entrée de fonction principale dans Protocol et est responsable de l'ensemble du cycle de vie d'Invoker. Tous les modèles de Dubbo sont plus proches de la couche Invoker
3. : couche de transmission de données à distance
Quantity Couche d'échange d'informations d'échange, qui encapsule le mode de requête et de réponse et convertit les requêtes de synchrone en asynchrone
Quantity La couche de transmission du réseau de transport unifie les interfaces de transmission réseau, telles que Netty et Mina unifiées en une seule interface de transmission réseau
● Couche de sérialisation des données sérialisées, chargée de gérer la sérialisation et la désérialisation de la transmission des données dans l'ensemble du framework Changement

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!