Cet article est partagé par la communauté Huawei Cloud « Décryptage de la technologie JavaChassis3 : prise en charge facile à étendre de plusieurs centres d'enregistrement » par liubao68.
Les premières versions de Java Chassis reposaient sur Service Center et offraient de nombreuses compétitivités différenciées :
- Transfert au niveau de l’interface. Les métadonnées de chaque version du microservice sont gérées via le registre, notamment les données contractuelles. En combinaison avec les données contractuelles, des capacités de routage au niveau de la version peuvent être obtenues. Par exemple, un microservice a deux versions : v1 et v2. La version v1 possède les interfaces op1 et op2, et la version v2 possède les interfaces op1, op2 et op3. Dans un scénario en niveaux de gris, le châssis Java peut automatiquement transférer l'accès de op3 à la version v2. L'accès de op1 et op2 est équilibré en charge dans les versions v1 et v2.
- Sélection d'instance basée sur la règle de version. Le client peut configurer la règle de version, telle que la dernière, 2.0+, etc. De cette manière, le client peut filtrer la version de l'instance en fonction de la situation réelle.
Java Chassis s'appuie trop sur Service Center, ce qui entraîne des goulots d'étranglement dans le développement de produits. La promotion écologique du châssis Java repose sur la promotion écologique du Service Center, ce qui ne favorise pas l'utilisation du châssis Java par davantage d'utilisateurs. Avec le développement du cloud, de plus en plus de clients s'attendent également à un ensemble de codes pouvant s'exécuter dans différents environnements cloud. Certains fournisseurs de cloud ne fournissent pas d'environnement d'exploitation Service Center, les utilisateurs auront donc des inquiétudes lors du choix du châssis Java.
Sur la base des raisons ci-dessus, Java Chassis simplifie les dépendances de la découverte d'enregistrement, définit une interface simple et facile à implémenter et fournit une implémentation basée sur celle-ci, et d'autres implémentations seront fournies à l'avenir . Java Chassis adopte une série de nouveaux modèles de conception pour garantir que la fiabilité de l'application elle-même ne soit pas réduite sans réduire la dépendance fonctionnelle vis-à-vis du centre d'enregistrement. Nacos
zookeeper
Alternatives au transfert au niveau de l’interface
S'appuyant sur Service Center, Java Chassis assure le transfert au niveau de l'interface. L'un des premiers changements apportés à Java Chassis 3 est la suppression de la prise en charge du transfert au niveau de l'interface. De cette manière, la complexité de la dépendance à l'égard du centre d'enregistrement peut être réduite d'au moins 70 %. Cependant, les scènes en niveaux de gris restent importantes pour de nombreuses entreprises. Java Chassis 3 utilise la publication en niveaux de gris pour résoudre ce problème. L'avantage de l'utilisation de la publication en niveaux de gris est que vous n'avez pas besoin de compter sur le centre d'enregistrement pour fournir des fonctionnalités de gestion des métadonnées de version, et que chaque instance doit uniquement disposer d'informations de métadonnées simples telles que les numéros de version.
servicecomb : # activer le routeur pour le routeur de service Edge : type : routeur routeRule : business : | - priorité : 2 correspondance : apiPath : préfixe : "/business/v2" route : - poids : 100 tags : version : 2.0.0 - priorité : 1 correspondance : apiPath : préfixe : "/business/v1/dec" route : - poids : 50 balises : version : 1.1.0 - poids : 50 balises : version : 2.0.0
Interface de découverte d'inscription et sa mise en œuvre
Java Chassis 3 fournit une nouvelle prise en charge de la découverte d'enregistrement en utilisant uniquement des interfaces. Java Chassis appellera l'instance de requête. Si les instances suivantes changent, l'implémentation du centre d'enregistrement en informera Java Chassis. Discovery
findServiceInstances
InstanceChangedListener
/** * Il s'agit de l'interface de découverte de service principale. <br/> */ public interface Discovery<D extends DiscoveryInstance> extends SPIEnabled, SPIOrder, LifeCycle { interface InstanceChangedListener<D extends DiscoveryInstance> { /** * Appelé par les implémentations de Discovery lorsque la liste d'instances est modifiée. * @param RegistryName Nom de l'implémentation de découverte appelante * @param application Application de microservice * @param serviceName Nom du microservice * @param selectedInstances Les dernières instances mises à jour. */ void onInstanceChanged(String RegistryName, String application, String serviceName, List<D>mis à jourInstances); } Nom de la chaîne(); /** * Si cette implémentation est activée pour ce microservice. */ boolean activé (application String, String serviceName); /** * Recherche toutes les instances. * * Cycle de vie:Cette méthode est appelée à tout moment après <code>run</code>. * * @param application application * @param serviceName nom du microservice * @return toutes les instances correspondent aux critères. */ List<D> findServiceInstances(String application, String serviceName); /** * Discovery peut appeler InstanceChangedListener lorsque l'instance est modifiée. */ void setInstanceChangedListener(InstanceChangedListener<D> instanceChangedListener); }
Java Chassis 3 gère l'enregistrement. Le processus d'enregistrement est divisé en , , et un cycle de vie simple. Vous pouvez préparer les données d'enregistrement et exécuter l'enregistrement. Il sera exécuté lorsque l'enregistrement échoue ou que le système s'arrête. Registration
init
run
destroy
init
run
destroy
/** * Il s'agit de l'interface d'enregistrement du service principal. <br/> */ interface publique Registration<R extends RegistrationInstance> extends SPIEnabled, SPIOrder, LifeCycle { String name(); /** * obtenir MicroserviceInstance </br> * * Cycle de vie:Cette méthode est appelée à tout moment après <code>run</code>. */ RgetMicroserviceInstance(); /** * mettre à jour l'état du MicroserviceInstance </br> * * Cycle de vie:Cette méthode est appelée à tout moment après <code>run</code>. */ boolean updateMicroserviceInstanceStatus(Statut MicroserviceInstanceStatus); /** * ajout de schémas au microservice </br> * * Cycle de vie:Cette méthode est appelée après <code>init</code> et avant <code>run</code>. */ void addSchema (String schemaId, String content); /** * ajout de points de terminaison à MicroserviceInstance </br> * * Cycle de vie:Cette méthode est appelée après <code>init</code> et avant <code>run</code>. */ void addEndpoint (point final de chaîne); /** * ajout d'une propriété à MicroserviceInstance </br> * * Cycle de vie:Cette méthode est appelée après <code>init</code> et avant <code>run</code>. */ void addProperty (clé de chaîne, valeur de chaîne) ; }
Enregistrez les combinaisons découvertes
Java Chassis 3 peut implémenter indépendamment plusieurs sommes pour s'inscrire auprès de plusieurs centres d'enregistrement et découvrir des instances de plusieurs centres d'enregistrement. Chaque instance est identifiée de manière unique par son ID d'instance. Si les ID d'instance sont identiques, ils seront considérés comme la même instance ; s'ils sont différents, ils seront considérés comme des instances différentes. Comme mentionné dans l'article, Java Chassis nécessite que chaque enregistrement d'instance (nouveau processus) génère un ID d'instance unique afin de résoudre le problème des fausses instances hors ligne causées par l'isolement de la partition d'enregistrement. et les deux contiennent des informations de base définies par Java Chassis. Discovery
Registration
Java Chassis 3技术解密:注册中心分区隔离
Discovery
Registration
/** * Informations standard utilisées pour l'enregistrement et la découverte des instances de microservice. */ interface publique MicroserviceInstance { /** * Environnement (obligatoire) : utilisé pour la séparation logique de l'instance de microservice. Seules * les instances de microservice avec le même environnement peuvent se découvrir. */ String getEnvironment(); /** * Application (obligatoire) : utilisée pour la séparation logique de l'instance de microservice. Seules les * instances de microservice avec la même application peuvent se découvrir mutuellement. */ String getApplication(); /** * Nom du service (obligatoire) : identifiant unique du microservice. */ String getServiceName(); /** * Alias de nom de service (facultatif) : identifiant unique du microservice. * Cet alias est utilisé par l'implémentation du registre pour prendre en charge le changement de nom * d'un microservice, par exemple les anciens consommateurs qui utilisent l'ancien nom de service peuvent * trouver un service de microservice renommé. */ StringgetAlias(); /** * Version du service (obligatoire) : version de ce microservice. */ Chaîne getVersion(); /** * Informations sur le centre de données (facultatif). */ DataCenterInfogetDataCenterInfo(); /** * Description du service (Facultatif) */ String getDescription(); /** * Propriétés du service (Facultatif) */ Map<String, String> getProperties(); /** * Schémas de service (facultatif) : informations sur l'API ouverte. */ Map<String, String> getSchemas(); /** * Points de terminaison du service (facultatif). */ List<String> getEndpoints(); /** * ID d'instance de microservice (obligatoire). Cet identifiant peut être généré au démarrage de l'instance de microservice * ou attribué par l'implémentation du registre. * * Lorsque l'instance de microservice est redémarrée, cet identifiant doit être modifié. */ StringgetInstanceId(); /** * ID du service microservice (facultatif). Ceci est utilisé pour le centre de service, d'autres implémentations peuvent ne pas * prendre en charge l'ID de service. */ String par défaut getServiceId() { return ""; } }
Lors de la mise en œuvre de la découverte d'enregistrement, il est nécessaire de s'assurer que les informations de base définies par l'interface peuvent être enregistrées dans le centre d'enregistrement, et que ces informations peuvent être obtenues lors de l'interrogation des instances.
Témoignage client : Ne pas mettre tous les œufs dans le même panier est une considération très importante dans le choix de la technologie. L'ouverture et la substituabilité des solutions ainsi que la substituabilité des services cloud sont des questions qui préoccupent de nombreux clients. Pour un cadre technologique open source, bien que la première version de Java Chassis ait été conçue pour prendre en charge différentes extensions de centre d'enregistrement, elle était très difficile à mettre en œuvre et rendait inconsciemment impossible pour les clients d'utiliser d'autres centres d'enregistrement pour remplacer le centre de service. Fournit une implémentation de découverte d'enregistrement plus simplifiée, ce qui réduit un petit nombre de fonctionnalités concurrentes, mais réduit considérablement les problèmes de sélection des clients.
Cliquez pour suivre et découvrir les nouvelles technologies de Huawei Cloud dès que possible~
Tauri v2 prend en charge Android et iOS, un nouveau choix pour le développement multiplateforme FastGateway : une passerelle PostgreSQL qui peut être utilisée pour remplacer Nginx. 90 % du nouveau code est complété par seulement 50 personnes, et Tuoshupai prend les devants. Lenovo publiera un nouveau système d'exploitation AI OS en 2024 Microsoft introduit des commandes Sudo natives dans Windows 11 pour prendre en charge Redox OS et prévoit de porter davantage de logiciels Linux. Il y a 10 ans aujourd'hui - Vue.js était officiellement lancé. Google a fait don d'un million de dollars à la Fondation Rust pour l'améliorer. l'interopérabilité entre Rust et C++, proposée autrefois par Mozilla Le projet de moteur Web abandonné "Servo" renaîtra en 2024. Le langage de programmation Zig publie une nouvelle feuille de route pour 2024