table des matières
Configuration du service local Spring
Configuration de Spring de service à distance
Adresse officielle: https://dubbo.apache.org/zh/
Dubbo prend en charge la configuration de SpringXML et la configuration du client. Le registre prend en charge Zookeeper et Redis. Le registre par défaut est Zookeeper. La dernière version est 2.7 et 3.0 est en cours de développement.
Contexte
Cet article présente l'évolution des applications de site Web
Avec le développement d'Internet, l'échelle des applications de site Web continue de s'étendre et les architectures d'applications verticales conventionnelles ne peuvent plus y faire face. Une architecture de service distribuée et une architecture informatique mobile sont impératives, et un système de gouvernance est nécessaire de toute urgence pour assurer une évolution ordonnée de l'architecture.
Architecture d'application unique
Lorsque le trafic du site Web est très faible, une seule application est nécessaire et toutes les fonctions sont déployées ensemble pour réduire les nœuds de déploiement et les coûts. À l'heure actuelle, le cadre d'accès aux données (ORM) utilisé pour simplifier la charge de travail d'ajout, de suppression, de modification et de vérification est la clé.
Architecture d'application verticale
Lorsque le nombre de visites augmente progressivement, l'accélération provoquée par l'ajout d'une seule application à la machine devient de plus en plus petite. L'un des moyens d'améliorer l'efficacité consiste à diviser l'application en plusieurs applications indépendantes pour améliorer l'efficacité. À l'heure actuelle, le framework Web (MVC) utilisé pour accélérer le développement des pages frontales est la clé.
Architecture de service distribuée
Lorsqu'il y a de plus en plus d'applications verticales, l'interaction entre les applications est inévitable. Le cœur de métier est extrait en tant que service indépendant, et un centre de service stable est progressivement formé, afin que les applications frontales puissent répondre plus rapidement aux demandes changeantes du marché. À l'heure actuelle, le cadre de service distribué (RPC) pour améliorer la réutilisation et l'intégration de l'entreprise est la clé.
Architecture informatique mobile
Lorsqu'il y a de plus en plus de services, des problèmes tels que l'évaluation de la capacité et le gaspillage de petites ressources de services apparaissent progressivement. À ce stade, un centre de répartition doit être ajouté pour gérer la capacité du cluster en temps réel en fonction de la pression d'accès afin d'améliorer l'utilisation du cluster. À l'heure actuelle, le centre de planification et de gouvernance des ressources (SOA) utilisé pour améliorer l'utilisation de la machine est la clé.
demande
Cet article présente les besoins que Dubbo veut résoudre
Avant la maintenance à grande échelle, les applications peuvent simplement exposer et référencer des services distants via des outils tels que RMI ou Hessian, les appeler en configurant l'adresse URL du service et effectuer un équilibrage de charge via du matériel tel que F5.
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 de point unique de l'équilibreur de charge matérielle F5 augmente également. À ce stade, un centre d'enregistrement de services est nécessaire pour enregistrer et découvrir de manière dynamique les services afin de rendre la localisation des services transparente. Et en obtenant une liste d'adresses de fournisseurs de services côté consommateur, il peut réaliser un équilibrage de charge souple et un basculement, réduire la dépendance à l'égard des équilibreurs de charge matériels F5 et également réduire une partie des coûts.
Lors du développement ultérieur, la dépendance entre les services devient mal gérée et compliquée, et il est même difficile de savoir quelle application doit être lancée avant quelle application.Les architectes ne peuvent pas décrire complètement la relation architecturale de l'application. À ce stade, il est nécessaire de dessiner automatiquement un graphe de dépendance entre les applications pour aider l'architecte à clarifier la relation.
Ensuite, le nombre d'appels au service devient de plus en plus important et le problème de la capacité du service est exposé. De combien de support machine ce service a-t-il besoin? Quand faut-il ajouter la machine? Afin de résoudre ces problèmes, la première étape consiste à compter le volume d'appels quotidien et le temps de réponse du service comme indicateur de référence pour la planification de la capacité. Deuxièmement, il est nécessaire d'ajuster dynamiquement le poids. En ligne, augmentez le poids d'une certaine machine et enregistrez le changement du temps de réponse pendant le processus d'augmentation, jusqu'à ce que le temps de réponse atteigne le seuil, enregistrez le nombre de visites à ce moment, puis utilisez ce Multipliez le nombre de visites par le nombre de machines pour inverser la capacité totale.
Ce qui précède sont les exigences les plus élémentaires de Dubbo.
Architecture
Architecture Dubbo
Description du rôle du nœud
| nœud | Description du rôle |
|---|---|
Provider |
Fournisseur de services qui expose le service |
Consumer |
Service client appelant le service à distance |
Registry |
Registre pour l'enregistrement et la découverte de services |
Monitor |
Centre de surveillance qui compte le nombre d'appels de service et le temps d'appel |
Container |
Conteneur en cours d'exécution de service |
Description de la relation d'appel
- Le conteneur de services est responsable du démarrage, du chargement et de l'exécution du fournisseur de services.
- Lorsque le fournisseur de services démarre, il enregistre le service qu'il fournit auprès du centre d'enregistrement.
- Lorsqu'un consommateur de services est démarré, il s'abonne au registre pour le service dont il a besoin.
- Le centre d'enregistrement renvoie la liste des adresses des fournisseurs de services au consommateur. En cas de modification, le centre d'enregistrement transmet les données de modification au consommateur en fonction de la longue connexion.
- Les consommateurs de services, dans la liste d'adresses des fournisseurs, en fonction de l'algorithme d'équilibrage de charge logicielle, sélectionnez un fournisseur à appeler et, si l'appel échoue, sélectionnez-en un autre à appeler.
- Les consommateurs et prestataires de services accumulent le nombre d'appels et la durée des appels dans la mémoire, et envoient des données statistiques au centre de télésurveillance toutes les minutes.
L'architecture Dubbo présente les caractéristiques suivantes: connectivité, robustesse, évolutivité et évolutivité vers la future architecture.
Connectivité
- Le centre d'enregistrement est responsable de l'enregistrement et de la recherche de l'adresse de service, ce qui équivaut à un service d'annuaire. Les fournisseurs de services et les consommateurs n'interagissent avec le centre d'enregistrement qu'au démarrage, et le centre d'enregistrement ne transmet pas les demandes, la pression est donc moindre
- Le centre de surveillance est chargé de compter le nombre d'appels de chaque service, le temps d'appel, etc. Les statistiques sont d'abord collectées en mémoire et envoyées au serveur du centre de surveillance toutes les minutes, et affichées dans des rapports
- Le fournisseur de services enregistre les services qu'il fournit auprès du centre d'enregistrement et signale la durée de l'appel au centre de surveillance. Cette heure n'inclut pas la surcharge du réseau
- Le consommateur de services obtient la liste d'adresses du fournisseur de services auprès du centre d'inscription et appelle directement le fournisseur en fonction de l'algorithme de chargement, et en même temps signale l'heure d'appel au centre de surveillance. Cette durée comprend la surcharge du réseau
- Le centre d'enregistrement, le fournisseur de services et le consommateur de services sont tous des connexions de longue durée, à l'exception du centre de surveillance
- Le registre perçoit l'existence du fournisseur de services grâce à la longue connexion, et le fournisseur de services est en panne, le registre va immédiatement pousser l'événement pour informer le consommateur
- Le centre d'enregistrement et le centre de surveillance sont tous hors service, ce qui n'affecte pas les fournisseurs et les consommateurs déjà en cours d'exécution. Les consommateurs mettent en cache la liste des fournisseurs localement
- Le centre d'enregistrement et le centre de surveillance sont facultatifs et les consommateurs de services peuvent se connecter directement au fournisseur de services
Robustesse
- Le temps d'arrêt du centre de surveillance n'affectera pas l'utilisation, mais certaines données d'échantillonnage seront perdues
- Une fois la base de données arrêtée, le registre peut toujours fournir des requêtes de liste de services via le cache, mais ne peut pas enregistrer de nouveaux services
- Cluster peer-to-peer du centre d'enregistrement, après que l'un d'entre eux tombe en panne, il passera automatiquement à l'autre
- Une fois le registre complètement arrêté, les fournisseurs de services et les consommateurs de services peuvent toujours communiquer via le cache local
- Le fournisseur de services est sans état, après que l'un d'entre eux soit en panne, cela n'affectera pas l'utilisation
- Une fois que les fournisseurs de services seront tous arrêtés, les applications de consommation de services seront indisponibles et se reconnecteront indéfiniment et attendront que le fournisseur de services se rétablisse.
Évolutivité
- Le registre est un cluster peer-to-peer, qui peut ajouter dynamiquement des instances de déploiement de machine, et tous les clients découvriront automatiquement le nouveau registre
- Le fournisseur de services est sans état et peut ajouter dynamiquement des instances de déploiement de machine, et le registre transmettra les nouvelles informations du fournisseur de services aux consommateurs
Évolutivité
Lorsque l'échelle des grappes de services sera encore étendue et que la structure de gouvernance informatique sera encore améliorée, un déploiement dynamique et une informatique mobile seront nécessaires. L'architecture de service distribuée existante n'apportera pas de résistance. La figure suivante est une architecture possible dans le futur:
Description du rôle du nœud
| nœud | Description du rôle |
|---|---|
Deployer |
Agent local pour les services de déploiement automatique |
Repository |
L'entrepôt est utilisé pour stocker les packages de version d'application de service |
Scheduler |
Le centre de répartition augmente ou diminue automatiquement les fournisseurs de services en fonction de la pression d'accès |
Admin |
Console de gestion unifiée |
Registry |
Registre pour l'enregistrement et la découverte de services |
Monitor |
Centre de surveillance qui compte le nombre d'appels de service et le temps d'appel |
usage
Une introduction simple et pratique à Dubbo
Configuration du service local Spring
local.xml:
<bean id=“xxxService” class=“com.xxx.XxxServiceImpl” />
<bean id=“xxxAction” class=“com.xxx.XxxAction”>
<property name=“xxxService” ref=“xxxService” />
</bean>
Configuration de Spring de service à distance
Sur la base du service local, il suffit de faire une configuration simple pour terminer la télécommande:
local.xmlDivisez la configuration ci - dessus en deux parties, placez la partie de définition de service sur le fournisseur de servicesremote-provider.xmlet placez la partie de référence de service sur le consommateur de serviceremote-consumer.xml.- Et augmentez la configuration de service exposée du côté du fournisseur
<dubbo:service>et augmentez la configuration du service de référence du côté du consommateur<dubbo:reference>.
remote-provider.xml:
<!-- 和本地服务一样实现远程服务 -->
<bean id=“xxxService” class=“com.xxx.XxxServiceImpl” />
<!-- 增加暴露远程服务配置 -->
<dubbo:service interface=“com.xxx.XxxService” ref=“xxxService” />
remote-consumer.xml:
<!-- 增加引用远程服务配置 -->
<dubbo:reference id=“xxxService” interface=“com.xxx.XxxService” />
<!-- 和本地服务一样使用远程服务 -->
<bean id=“xxxAction” class=“com.xxx.XxxAction”>
<property name=“xxxService” ref=“xxxService” />
</bean>