Transformation et communication - les meilleures pratiques et la tendance de développement de l'architecture de microservices (via l'analyse de cas)

Microservice

Les lecteurs peuvent être des dorsales techniques ou des chefs d'entreprise techniques dans l'entreprise, et ils réfléchiront davantage à la question de savoir s'il existe des bonnes pratiques à consulter et à suivre lors de la mise en œuvre de l'architecture de microservices.

Aujourd'hui, je vais partager avec vous un résumé de 1614, 1 cas, 6 principes, 1 méthode et 4 tendances de développement. Qu'est-ce qu'un microservice? Le champion a été très clair tout à l'heure. Vers le début de 2019, j'ai écrit un livre avec quelques amis intitulé "Highly Available Scalable Microservice Architecture". Mon livre expliquait également systématiquement ce que sont les microservices et quels types de technologies existent. Fonctionnalités, comment faire des microservices autour du dubbo et du printemps nuage, etc.

Aujourd'hui, je partage principalement le livre des microservices, quelques cas de référence et des principes de bonnes pratiques que j'ai résumés dans la pratique, et mon jugement général sur la tendance générale de développement des microservices.

• Un cas - Une étude de cas de la mise en œuvre de microservices dans le secteur financier
• Six principes-six principes de bonnes pratiques de l'architecture de microservices
• Une méthode-méthode de processus générale de la pratique de l'architecture de microservice
• Quatre grandes tendances - la tendance de développement de l'architecture des microservices

Un cas - Une étude de cas de la mise en œuvre de microservices dans le secteur financier

Tout le monde sait que dans notre pays, à l'instar du secteur financier et d'autres entreprises qui dépendent fortement de l'informatique pour le développement, il y a environ trois étapes de développement informatique:

• La première étape va de 1999 à 2008, principalement de la comptabilité distribuée traditionnelle à la réalisation du processus d'informatisation électronique.
• La deuxième étape va de 2008 à 2014. Cette étape est principalement en réseau et mobile, ce qui prend conscience que nous pouvons tous accéder au réseau mobile via des appareils mobiles et utiliser les services système.
• La troisième étape va de 2014 à aujourd'hui, qui est un processus numérique et intelligent. Dans ce processus, les données des utilisateurs deviennent de plus en plus volumineuses, ce qui à son tour peut favoriser le développement de l'ensemble de l'entreprise sur la base de nos données et réaliser des opérations axées sur la technologie.

 

J'ai moi-même l'honneur de terminer mes études universitaires au cours des dix premières années de la première étape et de participer à la construction informatique financière du secteur bancaire national. À ce stade, j'ai eu la chance d'assister au processus de transition de nombreuses banques de l'électronique à la systématisation. Dans un deuxième temps, tout en s'occupant des affaires bancaires, il a également participé à des technologies Internet telles que Taobao, participé à certains de leurs projets d'architecture et participé à certains processus réseau et mobile.

En regardant ces trois étapes en général, avec le développement des systèmes informatiques, la quantité de données et de clients dans le secteur financier augmente. Le système de l'ensemble du secteur financier devient de plus en plus complexe, et les exigences non fonctionnelles de stabilité, de cohérence, de disponibilité, d'évolutivité et de maintenabilité des performances du système sont également de plus en plus élevées.

 

Prenons un cas financier de base dont j'étais en charge auparavant: lorsque j'ai pris la relève, l'échelle du système était relativement grande, avec plus de 10 lignes métier et probablement des centaines de modules fonctionnels. Le nombre d'utilisateurs actifs de ce système est supérieur à 1 million et le nombre total d'utilisateurs est proche de 100 millions. Environ 200 à 300 millions d'ordres de transaction sont générés chaque jour, soit environ 10 fois le nombre d'ordres de transaction quotidiens sur Taobao et Jingdong.

Les capacités de traitement des commandes, les capacités de règlement des comptes et des fonds du système entier sont sévèrement limitées et la stabilité est très mauvaise, souvent en panne. Le montant de la transaction est également relativement important, avec un montant de transaction quotidien supérieur à 10 milliards de dollars américains. Le système a de très sérieux problèmes de stabilité, l'efficacité de la recherche et développement n'est pas élevée, plus d'une douzaine de business lines BU, bruyant chaque jour, donc toutes les parties sont très insatisfaites, y compris la satisfaction client est relativement faible.

Avant que je ne prenne la relève, l'équipe a également essayé de procéder à un fractionnement et à une transformation de microservices. À cette époque, l'échelle était relativement petite, il n'y avait aucune implication des entreprises, et c'était simple et grossier, de sorte que le système de base a été démoli. Ensuite, j'ai rapidement constaté que je ne pouvais pas le contrôler: en moyenne, une personne entretient 1,5 sous-système et la stabilité de l'ensemble du système n'est pas aussi bonne qu'avant. Dans le processus de transformation des microservices, nous alignons d'abord toutes les opérations, produits et technologies de l'entreprise, déterminons la construction de la centralisation globale de l'entreprise et la manière de transformer le plus grand objectif, et démontons l'ensemble du système en réception, middle desk et back office.

La réception est l'entreprise 2C front-end financière, qui change tous les jours. Cette chose ne convient pas au cœur de métier comme auparavant. À l'instar des activités bancaires traditionnelles dans le passé, de nombreuses petites et moyennes banques ne peuvent pas placer leurs activités au cœur de leurs activités, elles les placent donc sur le front-end. Nous avons subdivisé le système en premier plan, milieu et arrière-plan. L'arrière-plan est l'infrastructure pour assurer la stabilité minimale de l'ensemble du système. La station intermédiaire est également divisée en trois couches, la plus externe est la couche d'accès API, et les deux dernières couches sont la station intermédiaire métier et la station intermédiaire technique, qui sont au cœur du microservice. Nous avons regroupé de nombreuses unités commerciales de base, et le centre technologique est principalement la gouvernance des services et la passerelle de services.

 

À cette époque, la fiabilité globale de l'infrastructure n'était probablement que de 2 9s, moins de 3 9s, mais que se passe-t-il si notre système d'entreprise veut atteindre 4 9s? Nous devons apporter de grands changements au milieu du système et l'utiliser pour prendre en charge ce qui précède sans être affecté par l'infrastructure sous-jacente. La sécurité, la conformité et la stabilité de l'ensemble du système financier sont la partie centrale, alors à l'époque, nous avons cité de nombreuses stratégies et fait beaucoup de construction de la stabilité du système. Heureusement, avant l'équipe, il y avait de nombreux experts Google et Amazon qui ont fait la construction de solutions connexes. Deux ans avant que je prenne le relais, ils ont commencé à faire des préparatifs liés à la stabilité.

Après avoir pris le relais, j'ai reçu tous les rapports d'échec du COE il y a deux ou trois ans, combien de pannes ABC, comment elles se sont produites et les raisons de celles-ci. Grâce à ces choses, tous les échecs historiques peuvent être comptés. Ces systèmes, ces personnes et ces équipes, en cas de panne, quel lien s'est produit? Grâce à ceux-ci pour optimiser et intégrer l'équipe, optimiser notre technologie et optimiser notre processus, de nombreux problèmes sont fondamentalement résolus. Les problèmes de processus appartiennent au processus, les problèmes humains appartiennent aux personnes, la technologie appartient à la technologie et les problèmes de gestion appartiennent à la direction. Après une pièce est fait, le facteur d'instabilité est réduit de 99%.

 

Les choses axées sur les services ci-dessus doivent être soutenues par une base technique stable, nous avons donc consolidé la couche inférieure et nous devons avoir des idées nouvelles et rapides dans la construction d'infrastructures pour résoudre les problèmes d'origine.

• La première couche est la base de données. Il y a une période pendant laquelle la base de données est trop volumineuse pour être sauvegardée et il y a toujours un long délai de synchronisation. Si elle n'est pas gérée correctement à ce moment-là, de nombreux problèmes se produiront. Ensuite, divisez la base de données plusieurs fois verticalement et horizontalement pour réduire la capacité totale avant d'effectuer des sauvegardes.
• La deuxième couche est le middleware de message et le middleware de mémoire. L'entreprise est très sensible à la faible latence des transactions, mais les transactions principales précédentes étaient basées sur des bases de données et des fichiers disque, ce qui se traduisait par une latence élevée. Ici, le processus de transaction est optimisé en introduisant un middleware de message, et en même temps, l'interaction d'origine de chaque nœud du système est introduite dans le traitement de la mémoire, et le retard final est réduit d'un ordre de grandeur.
• Enfin, la stratégie de conteneurisation et d'automatisation est mise en place pour réduire les opérations manuelles et améliorer progressivement la maturité technique et la maturité R&D de l'équipe. Après tout, la leçon apprise auparavant est que la maturité en R&D de l'ensemble du système ne peut pas suivre, tout le monde est encore à l'ère traditionnelle et vous ne pouvez pas faire quelque chose de high-tech pour tout le monde.

Au cours de ce processus, nous avons introduit certains centres de données et la gouvernance des données, et avons superposé les données. Étant donné que la quantité de données quotidienne est trop importante, nous divisons les données en données chaudes, données chaudes, données froides et données de glace. Les données chaudes sont stockées dans une base de données relationnelle, les données chaudes sont stockées dans une base de données non relationnelle, les données froides y sont d'abord stockées selon diverses exigences, et les données de glace sont directement tuées.

Après toute la transformation, le débit a été multiplié par plus de 50 et le délai a été réduit des 600 ms d'origine à moins de 30 ms. Le coût de maintenance de l'ensemble du système est rapidement réduit et le temps de connexion professionnelle est réduit de plus de 80%. Dans le passé, il fallait deux semaines pour connecter une entreprise, et seulement deux jours après le traitement du système.La stabilité de l'ensemble du système peut essentiellement répondre aux exigences attendues, atteignant 4 9s. Après la transformation de l'ensemble du système, il y a eu un saut qualitatif.

 

Six principes-six principes de bonnes pratiques de l'architecture de microservices

Dans le cadre du processus de conduite de mon équipe vers des microservices, j'ai résumé six principes de bonnes pratiques pour la transformation de l'architecture des microservices:

1. Comment gérer les anciens systèmes?

Le développement de toute l'infrastructure va du simple au complexe. Un système tel que la transformation de microservice précédemment effectuée est un système qui a évolué jusqu'à un certain stade. Il est difficile à traiter au niveau métier et la quantité de données est importante. S'il y a un problème, le Hold ne peut pas l'aider. Pour ce type de transformation du système hérité, quelle est la meilleure façon de l'implémenter? Je résume cinq quarante mots:

1. La séparation des fonctions et le découplage des données modifient non seulement le système d'application, mais le divisent également en centre d'affaires en fonction des fonctions et des capacités verticales. Dans le même temps, la base de données doit être divisée.Je constate que de nombreuses équipes de R&D déploient simplement des clusters d'applications système et divisent à la place plusieurs modules en fonction des capacités de l'entreprise, mais la base de données est toujours un gros tas. De cette manière, la base de données n'est pas fractionnée et toute la pression est toujours dans la base de données, qui est limitée par le couplage des données elles-mêmes.
2. Évolution naturelle, démantèlement progressif, démontez d'abord les 10% et 20% qui affectent le plus la stabilité ou les besoins commerciaux les plus urgents du système, démontez d'abord. Qu'il soit découpé en deux ou découpé d'abord une petite fonction sans importance, c'est en fait un moyen réalisable. Mais pour cette demande commerciale, ou demande de stabilité, où les sourcils sont les plus chauds, les meilleurs résultats peuvent être vus. Cela peut également renforcer la confiance de toutes les parties impliquées dans les travaux de rénovation ultérieurs.
3. Exécutez par petites étapes et répétez rapidement. Chaque fois que vous fendez un petit morceau, ce petit morceau peut être entretenu séparément. Dans un cas précédent, il y avait un module qui a été développé pendant de nombreuses années. Ce module contient 100 000 lignes de code. On constate que l'ancien système ne peut pas être modifié. Vous pouvez supprimer le problème. Si le problème n'est pas clair , laissez-le être dedans. Nous l'avons divisé et réécrit, et nous l'avons terminé rapidement, en utilisant moins de 8 000 lignes de code.
4. Il est également très important de publier en niveaux de gris et d'être prudent face aux essais et erreurs. Par l'introduction de différentes méthodes de publication (laminage, niveaux de gris, bleu-vert, canari, etc.), pour assurer la stabilité et la fiabilité de la publication. Nous avons constaté que 80% des pannes se produisaient lorsque le système était libéré ou changé, tout comme un accident d'avion s'est produit 5 minutes avant le décollage et 5 minutes avant l'atterrissage.
5. Relever la ligne de qualité et rembourser la dette technique La qualité de chaque système doit être lentement réduite avec un développement stable à long terme. Lorsque nous divisons une pièce, nous pouvons la découper, la nettoyer et voir comment cela est fait. De cette manière, la qualité précédente peut être compensée et la dette technique précédente peut être compensée.

2. Comment faire le fractionnement avec la granularité appropriée?

Le principe de la séparation est: une cohésion élevée, un faible couplage et différents points de séparation à différentes étapes. Selon les besoins réels, il peut être nécessaire de procéder à un rodage au milieu après le fractionnement. Lors du premier cycle de fractionnement majeur, nous avons constaté que certains éléments étaient divisés de manière déraisonnable, puis ajoutés plus tard.

3. Comment étendre le système de microservices?

Il existe ici un concept de cube étendu. Toutes les extensions système peuvent être regroupées dans ce cube, qui a trois directions, axe XYZ.

• L'axe X est l'expansion horizontale, qui est en fait la réplication de la machine. Si nous ajoutons F5 et nginx à l'avant, nous pouvons copier le système d'entreprise sans cervelle sur N systèmes pour équilibrer la charge et égaliser la pression.
• L'axe Y est le découplage fonctionnel. Nous pouvons diviser tous les différents modules d'utilisateurs, de produits, de transactions et de paiements dans un système indépendant. La première étape du processus de fractionnement consiste à étendre le système. Après le fractionnement, vous pouvez développer différents contenus système en fonction de différentes caractéristiques système.
• L'axe Z est la partition de données et les données doivent être divisées. Il y a deux significations à cela: la première est la division horizontale, dans laquelle toutes les données sont divisées sans discernement et partitionnées. La seconde est que plusieurs fois, nous constatons que l'utilisation de toutes les données dans le système n'est pas uniforme, elle est inclinée. Par exemple, pour les transactions entre utilisateurs VIP et grands comptes dans le système, nous pouvons créer une machine distincte pour que VIP traite ses demandes, et s'agrandisse en fonction des caractéristiques et des balises des données utilisateur elles-mêmes. Cette pièce est également la base de l'architecture unifiée dont nous parlerons plus tard. À partir de cette extension, mon expérience consiste à renforcer le commutateur de fonctionnalités, de sorte que le nouveau et l'ancien ainsi que certains modèles tolérants aux pannes soient compatibles, de sorte qu'après la mise en ligne de notre système, s'il y a un problème, nous pouvons toujours basculer en fonction du pour rejeter le flux vers l'ancien système, ou migrer progressivement le trafic vers le nouveau système. S'il est stable pendant un certain temps, il est stable, puis l'ancien est abandonné Il y a un processus de coexistence dual core.

 

4. Comment améliorer l'efficacité de la R&D?

Dans le passé, il n'était pas facile de tester un seul système avant la scission, et il était facile de faire le déploiement, l'exploitation et la maintenance.Après la scission, le système est devenu plus grand et plus compliqué. C'est un défi de taille pour le développement, les tests, le déploiement, l'exploitation et la maintenance. À l'heure actuelle, une expérience relativement solide du traitement automatisé est requise.

5. Comment choisir les transactions distribuées?

De XA pris en charge par la base de données au départ, à TCC, SAGA, AT, etc. côté business. L'entreprise TCC est constituée de trois petites entreprises indépendantes et non d'une seule grande entreprise. Ces trois petites transactions distinctes et liées ont des exigences élevées en matière de conception commerciale, ce qui conduit à ce que l'on appelle l'intrusivité de l'entreprise. À ce stade, je constate que de nombreux éléments sont utilisés de manière incorrecte.

Le mode de transaction SAGA consiste à effectuer directement divers services inter-bases de données et à effectuer les opérations d'annulation une par une en cas de problème. Il n'y a pas de solution de transaction distribuée. C'est le même que le concept de transaction distribuée que tout le monde utilisait il y a de nombreuses années. Le modèle de compensation / réconciliation des entreprises est le même, donc à l'heure actuelle, tout le monde dans le secteur financier utilise le plus pratique.

AT est une génération automatisée d'opérations inverses et de SQL, qui est plus intelligente, mais elle n'est pas trop mature à ce stade et une logique complexe peut ne pas être en mesure de la gérer. Ces types sont tous des mécanismes de transaction flexibles qui sont contrôlés du côté commercial en plus de la base de données, également appelés transactions de cohérence éventuelles. En fait, les bases de données relationnelles et même certains intergiciels tels que MQ peuvent avoir un support intégré pour les transactions distribuées telles que XA avec une forte cohérence. Depuis dix ans, cette technologie est la plus utilisée dans les transactions financières et dans d'autres lieux où une forte cohérence est requise. L'enseignant champion a également mentionné beaucoup de solutions commerciales et de solutions open source pour les transactions distribuées, donc je n'en dirai pas plus ici.

 

6. Comment faire la surveillance, l'exploitation et la maintenance?

Le suivi de l'exploitation et de la maintenance implique l'observabilité des microservices, ce qui est également un sujet très intéressant. D'une part, la surveillance doit soutenir nos opérations commerciales, d'autre part, elle doit coopérer avec l'infrastructure technique. En coopération avec l'entreprise, mon plus grand sentiment avant est que notre suivi ne doit pas se faire uniquement à partir d'indicateurs techniques et système, mais également à partir d'indicateurs commerciaux. Plusieurs fois, nous trouvons des plaintes des départements commerciaux et des clients, ce qui ne va pas avec le système, nous voyons que tous les indicateurs techniques du système sont bons, ce n'est certainement pas notre problème. À cette époque, de graves conflits et un chaos se sont produits entre la technologie et les affaires.

Ensuite, les différentes opérations effectuées dans notre système ajouteront directement les indicateurs métier du système, examineront d'abord le problème à partir des indicateurs métier, puis chercheront des indices à partir des indicateurs techniques. En même temps, effectuez la planification de la capacité, l'alarme et l'alerte précoce, et consolidez les procédures d'exploitation et de maintenance. Nous avons constaté que si de nombreux techniciens sont responsables et dirigent le lancement, ils penseront certainement à résoudre tous les problèmes survenus pendant le processus de lancement et le laisseront être lancé une fois avec succès. Cependant, d'après notre expérience, il y a des problèmes lors du processus en ligne. La meilleure façon est de restaurer la version avant la mise en ligne, d'enregistrer les données à ce moment-là et de les analyser lentement. Faites un bon travail de dépannage. Il y a des catastrophes naturelles et causées par l'homme dans nos fautes, et les catastrophes naturelles ne peuvent être évitées. Le système est comme une personne et il y aura des problèmes après une longue période. Par conséquent, il peut être normal que diverses anomalies et accidents de la circulation se produisent. Nous devons accumuler des solutions et une expérience suffisantes pour y faire face.

Nous disons souvent que si nous prévoyons un arrêt pour maintenance, nous le disons d'abord à tous les clients, alors c'est une histoire. Si nous trouvons un problème, ne vous arrêtez pas pour la maintenance et attendez un arrêt soudain à un moment donné, c'est un accident.

 

Une méthode-méthode de processus générale de la pratique de l'architecture de microservice

Après avoir dit tant de choses sur les microservices, comment les microservices fonctionnent-ils dans des projets spécifiques? J'ai résumé un total de huit étapes. Les quatre premières sont la phase de préparation et les quatre dernières sont la phase de mise en œuvre. Ensuite, vous pouvez revenir à la phase de préparation et continuer à itérer le processus:

• La première étape consiste à rechercher, d'abord comprendre la situation actuelle du système et les demandes de toutes les parties
• La deuxième étape consiste à clarifier les enjeux fondamentaux et les objectifs de transformation
• La troisième étape est d'achever la phase de transformation et de planifier en fonction de l'objectif, ce n'est pas réaliste du jour au lendemain, surtout lorsque le système implique des milliers de personnes travaillant ensemble.
• La quatrième étape consiste à coordonner les équipes et les ressources liées au système. Les quatre premières étapes ensemble sont la phase de préparation. Les quatre étapes de la phase de préparation sont différentes des quatre étapes de la phase de mise en œuvre.

 

Les quatre étapes suivantes sont le fractionnement, le déploiement, la gouvernance et l'amélioration. Du contrôle technique et de l'exploitation à l'ensemble du système et du processus, la coopération de tous est-elle acceptable? S'il y a un problème, quelle que soit la partie du problème à améliorer, et puis de manière itérative De cette manière, un grand système d'entreprise est progressivement transformé en microservices.

Au cours de ce processus, quelqu'un me demandera, me recommanderiez-vous à quel moment et quelle méthode dois-je utiliser pour résoudre le problème? Vous lui dites que vous n'avez pas besoin de rechercher les dernières et meilleures technologies du système, il vous suffit de rechercher la technologie qui correspond à la maturité de votre équipe actuelle, en particulier dans le secteur financier pour être indépendante, contrôlable et open source.

Quatre grandes tendances - la tendance de développement de l'architecture des microservices

Enfin, laissez-moi vous présenter la tendance de développement des microservices. De l'architecture monolithique à l'architecture verticale en passant par SOA et microservices.

 

Le concept de microservices est relativement précoce. Il existe depuis 2011. Comme chacun sait, c'était en 2014. Le pays a commencé à faire la première vague de microservices en 2014 et 2015. En 2016, il y avait des microservices réactifs. Les services sont maintenant plus populaire. Concept de grille et concept natif de cloud.

 

Le développement de l'architecture des microservices bat son plein et il existe actuellement quatre grandes tendances de développement.

 

Tendance 1: microservices réactifs

Les microservices réactifs sont issus de déclarations réactives et d'une programmation réactive. Parmi eux, la réactivité instantanée signifie que quel que soit le système, tant qu'il n'y a pas de temps d'arrêt, les utilisateurs doivent bénéficier de services réactifs. Pour faire simple, nous sommes de plus en plus conscients que le système est comme un être humain, et il y aura des problèmes tels que maux de tête et fièvre. Lorsqu'un problème survient, est-ce que nous descendons directement ou fournissons des services sous certaines conditions. .

Résilience et élasticité. L'élasticité signifie évolutivité et contraction. De plus, axé sur les messages, le système est comme les gens, nous devons faire un choix, vous ne fournissez pas du tout de services ou fournissez maintenant des services dans une capacité limitée. L'exemple que je donne souvent, un système a trois niveaux de protection et de limitation de courant de l'ensemble du système:

• Le premier niveau est ce qu'on appelle le contrôle de flux. Par exemple, nous le limitons en fonction du nombre de fois par unité de temps et de la quantité de données consultées, avec des poids.
• La seconde est la dégradation du service: si vous ne pouvez pas faire tout le travail, je laisserai à tout le monde le soin d’obtenir de l’argent.
• Le troisième est la protection contre les surcharges de l'ensemble du système. Ce système a longtemps été incapable de le gérer. Une agence bancaire avait l'habitude de quitter le travail à 17 heures, mais maintenant je quitte le travail à 15 heures, ce qui est aussi une protection contre les surcharges. Pendant le processus, l'ensemble du système n'est pas en panne, et le fonctionnement du service minimum est conservé, ce qui signifie que sa récupération contrôlable est comme un humain.

Tendance 2: Service Grid et Cloud Native

Au cours des 2 dernières années, Service Mesh est définitivement un sujet populaire que tout le monde connaît. Différente des solutions de microservices Apache Dubbo ou Spring Cloud courantes, la grille de services fait référence au déploiement de diverses stratégies non liées à l'entreprise dans les microservices du système métier vers ce nœud de manière unifiée, en supprimant l'infrastructure existante du processus, qui est Sidecar, les microservices et les microservices communiquent via le Sidecar local, et Sidecar contrôle les règles de stratégie via le panneau de contrôle, qui est une grille de microservices.

De cette manière, nous divisons le système en la plate-forme de données où se trouvent les services métier et le plan de contrôle où se trouvent les nœuds de contrôle. Par conséquent, dans cette nouvelle structure, le nœud de microservice doit uniquement se concentrer sur la logique métier elle-même.

 

Tendance 3: Grille de base de données et base de données distribuée

De même, lorsque nous appliquons ces concepts au champ de la base de données, un nouveau composant est créé, nous pouvons d'abord l'appeler Sharding-Sidecar. De cette manière, le système d'entreprise n'a pas besoin de gérer le protocole de données et l'emplacement, mais doit seulement traiter toutes les données comme des données locales et s'appliquer au composant Sharding-Sidecar. Toutes les configurations liées à la base de données elle-même, toutes les stratégies de qualité des données, de sécurité, de contrôle de flux et de gouvernance, ne nécessitent pas de perception directe par le système métier.

En conséquence, nous pouvons également ajouter Sharding-Sidecar au panneau de données et ajouter notre gestion de base de données distribuée et notre interface utilisateur au panneau de contrôle. Dans le même temps, nous pouvons utiliser des nœuds de base de données totalement transparents pour le système d'entreprise, comme un lot d'instances MySQL, en tant que nouvelle couche appelée panneau de stockage. À ce stade, une solution middleware de base de données native cloud complète est produite, que nous appelons un maillage de base de données (Database Mesh).

 

Tendance 4: architecture unifiée

De nombreuses grandes entreprises ne peuvent pas directement faire des microservices en une seule étape, nous pouvons donc transformer les gros morceaux originaux en mini-versions dans le processus de transformation des microservices, et même certaines parties se trouvent être auto-cohérentes pour former une boucle fermée et distribuées dans différents À l'intérieur du centre de données.

 

L'image ci-dessous est l'une des quatre grandes banques publiques auxquelles j'ai récemment participé en tant que consultant expert, et l'ensemble de leur structure unifiée. La couche PaaS (TSF + TDSQL de Tencent) utilisée dans la couche inférieure doit être connue de tous, et la couche supérieure utilise notre couche de gestion de services auto-développée et notre couche d'architecture unifiée.

 

Résumons la tendance actuelle de développement des microservices, des microservices aux grilles de services en passant par les microservices réactifs, les grilles de bases de données et les natifs du cloud, puis à certaines choses que nous faisons actuellement, pour comparer les idées et les expériences d'architecture de microservices avec les actuelles analyses de rentabilisation du secteur financier, telles que l'architecture modulaire.

J'espère qu'il peut être utile pour tout le monde de se renseigner sur les microservices, et que les amis que j'aime peuvent m'aider avec trois connexions en un clic, merci!