Analyse des principes et des exemples du cadre de services distribués basé sur Java Dubbo

Avant-propos

Avant de présenter Dubbo, comprenons les concepts de base :

Dubbo est un framework RPC, RPC, c'est-à-dire Procédure à distance Appel (appel de procédure à distance), à ​​l'opposé est l'appel de procédure locale. Avant l'architecture distribuée, l'architecture d'application unique et l'architecture d'application verticale utilisaient des appels de procédure locale. Il permet à un programme d'appeler une procédure ou une fonction dans un autre espace d'adressage (généralement une autre machine partagée sur un réseau) sans que le programmeur ait à coder explicitement les détails de l'appel à distance. <code>RPC框架，RPC，即Remote Procedure Call（远程过程调用），相对的就是本地过程调用，在分布式架构之前的单体应用架构和垂直应用架构运用的都是本地过程调用。它允许程序调用另外一个地址空间（通常是网络共享的另外一台机器）的过程或函数，并且不用程序员显式编码这个远程调用的细节。

而分布式架构应用与应用之间的远程调用就需要RPC框架来做，目的就是为了让远程调用像本地调用一样简单。

Dubbo框架有以下部件

Consumer

即调用远程服务的服务消费方，消费者需要面向接口编程，知道了哪些接口可以调用了，具体实现需要框架提供一个代理类来为接口提供具体实现，让消费者只管调用什么接口，而具体实现的获取由代理类来处理。

消费者还需要提供调用方法名以及方法的参数值。

但是代理类此时还不知道需要调用哪个服务器上的远程方法，此时需要一个注册中心，通过注册中心获取可以调用的远程服务列表。

远程服务器一般都是集群部署，那么调用哪个服务器则需要通过负载均衡来选择一个最合适的服务器来调用。

同时还需要有集群容错机制，因为各种原因，可能远程调用会失败，此时需要容错机制来重试调用，保证远程调用的稳定性。

同时与服务提供方约定好通信协议和序列化格式，方便通信以及数据传输。

Provider

即暴露服务的服务提供方，服务提供方内部实现具体的接口，然后将接口暴露出去，再将服务注册到注册中心，服务消费方调用服务，提供者接收到调用请求后，通过约定好的通信协议来处理该请求，然后做反序列化，完成后，将请求放入线程池中处理，某个线程接收到这个请求然后找到对应的接口实现进行调用，然后将调用结果原路返回。

Registry

即服务注册与发现的注册中心，注册中心负责服务地址的注册与查找，相当于服务目录，服务提供者和消费者只会再启动时与注册中心交互，注册中心不转发请求，压力小。

注册中心还可以集中化处理配置以及动态地将变更通知订阅方。

但是为什么需要注册中心呢？没有注册中心不可以吗？

在没有注册中心，各服务之间的调用关系是这样的：

当服务越来越多时，服务URL配置管理变得非常困难，硬件负载均衡器的单点压力也越来越大，而有了注册中心之后，就可以实现服务的统一管理，并且实现软负载均衡，降低硬件成本，以下为注册中心示意图：

Monitor

即统计服务调用次数和调用时间的监控中心，面对众多服务，精细化的监控和方便的运维是不可或缺的，对后期维护相当重要。

Container

即服务运行的容器。

架构

图中的各个节点充当的角色已经介绍过了，以下是各节点之间调用关系：

Container服务容器负责启动，加载以及运行

Provider服务提供者Provider服务提供者启动时，需要将自身暴露出去让远程服务器可以发现，同时向Registry注册中心注册自己提供的服务

Consumer服务消费者启动时，向Registry注册中心订阅所需要的服务

Registry

Les appels à distance entre applications d'architecture distribuée nécessitent le framework RPC pour rendre les appels à distance aussi simples que les appels locaux. 🎜🎜🎜 🎜 Le framework Dubbo comporte les composants suivants : 🎜

Consommateur

🎜C'est-à-dire le consommateur de services qui appelle les services distants. Les consommateurs doivent avoir une programmation orientée interface pour savoir quelles interfaces peuvent être appelées. L'implémentation spécifique nécessite que le framework soit fourni. une classe proxy pour l'interface fournit une implémentation spécifique, permettant aux consommateurs d'appeler simplement quelle interface, et l'acquisition de l'implémentation spécifique est gérée par la classe proxy. 🎜🎜Les consommateurs doivent également fournir le nom de la méthode appelante et les valeurs des paramètres de la méthode. 🎜🎜Mais la classe proxy ne sait pas encore quelle méthode distante sur le serveur doit être appelée à ce stade, un centre d'enregistrement est nécessaire pour obtenir une liste des services distants pouvant être appelés. 🎜🎜Les serveurs distants sont généralement déployés en clusters, de sorte que le serveur à appeler nécessite un équilibrage de charge pour sélectionner le serveur le plus approprié à appeler. 🎜🎜Dans le même temps, un mécanisme de tolérance aux pannes du cluster est également requis. Pour diverses raisons, les appels à distance peuvent échouer. À ce stade, un mécanisme de tolérance aux pannes est nécessaire pour réessayer l'appel afin de garantir la stabilité de l'appel à distance. . 🎜🎜Parallèlement, convenez du protocole de communication et du format de sérialisation avec le prestataire de services pour faciliter la communication et la transmission des données. 🎜

Fournisseur

🎜C'est-à-dire le fournisseur de services qui expose le service. Le fournisseur de services implémente une interface spécifique en interne, puis expose l'interface, puis enregistre le service dans le centre d'enregistrement. Le service et le fournisseur la reçoivent.Une fois la demande d'appel reçue, la demande est traitée via le protocole de communication convenu, puis désérialisée.Une fois terminée, la demande est placée dans le pool de threads pour être traitée.Un certain thread reçoit la demande. trouve l'implémentation d'interface correspondante à appeler. Renvoie ensuite le résultat de l'appel au chemin d'origine. 🎜

Registre

🎜Il s'agit du centre d'enregistrement pour l'enregistrement et la découverte des services. Le centre d'enregistrement est responsable de l'enregistrement et de la recherche des adresses de service, ce qui équivaut à l'annuaire de services. Les fournisseurs de services et les consommateurs n'interagiront que. avec le centre d'inscription au démarrage. Le centre d'inscription ne transmet pas les demandes, il y a donc peu de pression. 🎜🎜🎜 🎜 Le centre d'enregistrement peut également gérer la configuration de manière centralisée et informer dynamiquement les abonnés des modifications. 🎜🎜Mais pourquoi avons-nous besoin d’un centre d’inscription ? N'est-ce pas possible sans centre d'inscription ? 🎜🎜En l'absence de centre d'inscription, la relation d'appel entre services est la suivante : 🎜🎜🎜🎜Lorsqu'il y a de plus en plus de services, la gestion de la configuration des URL de service devient très difficile et la pression en un seul point sur l'équilibreur de charge matériel augmente également, et Avec le centre d'enregistrement, une gestion unifiée des services peut être obtenue, un équilibrage de charge logiciel peut être réalisé et les coûts matériels peuvent être réduits. Voici un schéma schématique du centre d'enregistrement : 🎜🎜🎜

Moniteur

🎜C'est-à-dire, le centre de surveillance qui compte le nombre d'appels de service et la durée des appels, Face à de nombreux services, une surveillance raffinée et un fonctionnement et une maintenance pratiques sont indispensables et sont très importants pour la maintenance ultérieure. 🎜

Conteneur

🎜Le conteneur sur lequel le service s'exécute. 🎜🎜Architecture🎜🎜🎜🎜Les rôles joués par chaque nœud dans la figure ont été introduits. Voici la relation d'appel entre chaque nœud : 🎜🎜ConteneurLe conteneur de service est responsable du démarrage, du chargement et de l'exécution🎜🎜Provider Service ProviderProviderLorsque le fournisseur de services démarre, il doit s'exposer pour que le serveur distant puisse le découvrir, et en même temps enregistrer les services qu'il fournit avec le Centre d'enregistrement🎜 🎜Lorsque le consommateur du service Consommateur démarre, il s'abonne au centre d'enregistrement Registre pour les services requis 🎜🎜Registre Le centre d'enregistrement renvoie la liste des fournisseurs de services au consommateur. Dans le même temps, si des changements surviennent, le centre d'enregistrement transmettra des données en temps réel aux consommateurs en fonction des longues connexions🎜<p>Lorsque le consommateur du service a besoin d'appeler un service distant, il sélectionnera un serveur fournisseur dans la liste d'adresses du fournisseur en fonction de l'algorithme d'équilibrage de charge à appeler. Si l'appel échoue, l'appel sera réessayé en fonction de la stratégie de tolérance aux pannes du cluster</p>. <p>Consommation du service L'opérateur et le fournisseur compteront le nombre d'appels et la durée des appels en mémoire, puis enverront les données au centre de surveillance <code>Monitor via des tâches planifiéesMonitor监控中心

高可用性

• 监控中心宕机后不会对服务造成影响，只是丢失部分统计数据

• 注册中心集群后，任意一台宕机后，将自动切换到其他注册中心

• 当所有注册中心均宕机后，服务提供者和消费者之间仍然能通过本地记录了彼此信息的缓存进行通讯，但是如果一方产生变更，另外一方无法感知

• 服务提供者无状态，任意一台服务器宕机后不影响使用，会有其他服务提供者提供服务

• 当所有服务提供者宕机后，服务消费者无法正常使用，将进行无限次重连等待服务提供者重新连线恢复

框架设计

大的分层为Business（业务逻辑层）、RPC层和Remoting层。

再细分下来，Dubbo一共有十层架构，作用分别如下：

Service，业务层，即日常开发中的业务逻辑层

Config，配置层，对外配置接口，以ServiceConfig 和ReferenceConfig为中心，可以直接初始化配置类，也可以通过Spring解析配置生成配置类

Proxy，服务代理层，服务接口透明代理，生成服务的客户端Stub和客户端Skeleton，负责远程调用和返回结果

Registry，注册中心层，封装服务地址的注册与发现，以服务URL为中心，拓展接口为RegistryFactory，Registry，RegistryService

Cluster路由和集群容错层，封装了多个提供者的路由、负载均衡以及集群容错，并桥接注册中心，负责通过负载均衡选取调用具体的节点，处理特殊调用请求和负责远程调用失败的容错措施

Monitor，监控层，负责监控统计RPC调用次数和调用时间

Portocol，远程调用层，主要封装RPC远程调用方法

Exchange，信息交换层，用于封装请求响应模型

Transport，网络传输层，抽象化网络传输统一接口，有Mina和Netty可供使用

Serialize，序列化层，将数据序列化成二进制流进行传输，也可以反序列化接收数据

服务暴露过程

首先Provider启动，Protocal通过Proxy代理将需要暴露的接口封装成Invoker，是一个可执行体，然后通过Exporter包装并发送到注册中心完成注册，至此服务就暴露完成。

服务消费过程

注：上图中蓝色部分为服务消费者，绿色部分为服务提供者。

服务消费者启动时会向注册中心订阅并拉取所需服务提供者的信息，并保存到本地缓存，由此即使所有注册中心宕机后，服务提供者和服务消费者也可以通过本地缓存进行通讯，只是一方出现了信息变更，另一方无法感知，但并不影响服务的进行。

之后整个服务消费流程从图中的Proxy开始，由代理类完成处理，以此到达透明无感知。

ProxyFactory生成一个Proxy代理类，Proxy持有一个Invoker可执行对象，调用invoke之后需要通过Cluster从Directory中获取所有可调用的远程服务Invoker列表，如果配置了某些路由规则，还需要再过滤一遍Invoker列表。

剩下的Invoker再通过LoadBalance做负载均衡选取一个，还需要再通过Filter进行一些数据统计，之后将这些数据保存下来，定时发送给Monitor。

接下来用Client做数据传输，一般用Netty进行传输。

传输需要通过Codec接口进行协议构造，然后再通过Serialization

Haute disponibilité

• Après la panne du centre de surveillance, cela n'affectera pas le service, mais certaines données statistiques seront perdues🎜
• 🎜Après l'enregistrement du centre cluster, si l'un d'eux tombe en panne, il basculera automatiquement vers d'autres centres d'enregistrement🎜
• 🎜Lorsque tous les centres d'enregistrement sont en panne, les fournisseurs de services et les consommateurs peuvent toujours communiquer via des caches qui enregistrent localement les informations de chacun. si une partie change, l'autre partie ne peut pas détecter 🎜
• 🎜Le fournisseur de services est apatride. Si un serveur tombe en panne, cela n'affectera pas l'utilisation. Il y aura d'autres fournisseurs de services pour fournir des services🎜<.>
• 🎜Lorsque tous les services sont fournis Après la panne du fournisseur de services, le consommateur du service ne peut pas l'utiliser normalement et se reconnectera indéfiniment en attendant que le fournisseur de services se reconnecte et reprenne🎜

Conception du framework

🎜🎜🎜La grande couche est la couche Business (couche logique métier), la couche RPC et la couche Remoting. 🎜🎜Décomposé davantage, Dubbo a un total de dix couches d'architecture, et les fonctions sont les suivantes : 🎜🎜Service, couche métier, qui est la couche de logique métier dans le développement quotidien🎜🎜Config , couche de configuration, interface de configuration externe, centrée sur ServiceConfig et ReferenceConfig, la classe de configuration peut être initialisée directement, ou la classe de configuration peut être générée via Spring analysant la configuration🎜🎜Proxy , la couche proxy de service, le proxy transparent de l'interface de service, génère le client Stub et le client Squelette du service, et est responsable des appels à distance et du renvoi des résultats 🎜🎜 Registry, la couche du centre d'enregistrement, encapsule l'enregistrement et la découverte des adresses de service, avec l'URL du service comme centre, et les interfaces étendues sont RegistryFactory , Registry, RegistryService🎜🎜<code>ClusterLa couche de tolérance aux pannes de routage et de cluster encapsule le routage, l'équilibrage de charge et la tolérance aux pannes de cluster de plusieurs fournisseurs et relie le centre d'enregistrement, qui est responsable de la sélection et de l'appel de nœuds spécifiques via l'équilibrage de charge, et du traitement des demandes d'appel spéciales et des mesures de tolérance aux pannes pour les échecs d'appels à distance🎜🎜Moniteur, couche de surveillance, responsable de la surveillance et du comptage du nombre d'appels RPC et de la durée des appels🎜🎜Portocol, couche d'appel à distance, encapsule principalement la méthode d'appel à distance RPC 🎜🎜Exchange, couche d'échange d'informations, utilisé pour encapsuler le modèle de réponse aux requêtes 🎜🎜Transport, couche de transport réseau, résume l'interface unifiée de transmission réseau, avec Mina et Netty sont disponibles pour utilisez🎜🎜Serialize, la couche de sérialisation, sérialise les données dans un flux binaire pour la transmission, et peut également désérialiser et recevoir des données 🎜

Processus d'exposition du service

🎜Tout d'abord, le fournisseur est démarré Le protocole encapsule l'interface qui doit être exposée dans un invoker via l'agent proxy, puis le conditionne via l'exportateur et l'envoie au centre d'enregistrement pour terminer l'enregistrement. Exposition terminée. 🎜🎜🎜 Processus de consommation de services🎜🎜🎜Remarque : la partie bleue dans l'image ci-dessus est le consommateur du service et la partie verte est le fournisseur de services. 🎜🎜Lorsque le consommateur de services démarre, il s'abonne au centre d'enregistrement, extrait les informations requises sur le fournisseur de services et les enregistre dans le cache local. Par conséquent, même une fois que tous les centres d'enregistrement sont indisponibles, le fournisseur de services et le consommateur de services peuvent toujours y accéder. Le fournisseur de services local communique via le cache local, mais si une partie a des modifications d'informations, l'autre partie ne peut pas les détecter, mais cela n'affecte pas la progression du service. 🎜🎜Ensuite, l'ensemble du processus de consommation de services commence à partir du proxy dans la figure et est traité par la classe proxy pour assurer la transparence et aucune perception. 🎜🎜ProxyFactory génère une classe proxy Proxy. Proxy contient un objet exécutable Invoker. Après avoir appelé invoke, vous devez transmettre Cluster<. code>Obtenir la liste de tous les invokers de services distants appelables à partir du <code>Répertoire Si certaines règles de routage sont configurées, vous devez filtrer à nouveau la liste des invokers. 🎜🎜Les Invokers restants sont ensuite sélectionnés pour l'équilibrage de charge via LoadBalance. Ils doivent également effectuer certaines statistiques de données via Filter, puis enregistrer les données et les envoyer régulièrement à Monitor. . 🎜🎜Ensuite, utilisez Client pour la transmission de données, et utilisez généralement Netty pour la transmission. 🎜🎜La transmission nécessite la construction d'un protocole via l'interface Codec, puis la sérialisation via Serialization, et enfin le flux binaire sérialisé est envoyé au fournisseur de services correspondant. 🎜

Après avoir reçu le flux binaire, le fournisseur de services effectuera également le traitement du protocole Codec, puis désérialisera (le traitement ici est symétrique au traitement avant la transmission), puis placera la demande dans le pool de threads pour le traitement. Un certain thread trouvera le. correspondant Exporter selon la requête, puis filtrez-le couche par couche via Filter pour obtenir l'invoker, et enfin appelez la classe d'implémentation correspondante et renvoyez le résultat de la manière originale.

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!