Évolution de l'architecture et exploration du design d'Ele.me

Au début, nous utilisions un framework qui facilitait l'extension de la SOA. Nous utilisons le framework SOA pour résoudre deux choses :

Au début du site Web, il pouvait n'y avoir que 1 à 5 programmeurs, à cette époque, tout le monde pouvait être occupé avec la même chose. Ils comprennent tous le travail de chacun et résolvent souvent les problèmes en « criant ».

Mais à mesure que le nombre de personnes augmente, cette méthode n'est évidemment pas réalisable. Il est impossible pour une seule personne de mettre à jour le code puis de remettre en ligne les codes de tous les autres, n'est-ce pas ? Nous devons donc considérer la question de la division du travail et de la collaboration.

Dans le passé, le volume des commandes pouvait varier de 1 000 à 10 000. Bien qu'il ait augmenté de 10 fois, le volume total n'est pas très élevé et la pression sur un site Web n'est pas si grande. Lorsque le volume des commandes passe réellement de 100 000 à 1 000 000, et de 1 000 000 à 2 000 000, le nombre ne peut être multiplié que par 10, mais il s'agit d'un énorme défi pour l'architecture de l'ensemble du site Web.

Notre parcours est que nous sommes passés d'un million en 2014 à 9 millions maintenant. L'équipe technique est passée de plus de 30 personnes au début à une équipe de plus de 900 personnes maintenant. À l’heure actuelle, la division du travail et la collaboration constituent un défi de taille. La division et l'intégration des services ainsi que la division et l'intégration des équipes nécessitent un système de framework pour les prendre en charge. C'est également un rôle du framework SOA.

Regardez notre situation actuelle. Le milieu est l'ensemble de notre système d'architecture, et le côté droit est constitué de quelques fondations liées à la servitisation, y compris les composants ou services de base.

Parlons d'abord du langage. Notre site Web d'origine était basé sur PHP, puis il s'est lentement transformé.

Les fondateurs sont tous des étudiants qui créent leur propre entreprise, donc bien sûr Python est un bon premier choix. Jusqu’à présent, Python est également un bon choix, mais pourquoi devrions-nous l’étendre à Java et Go ?

Beaucoup de gens peuvent écrire du Python, mais peu de gens peuvent vraiment bien le faire. À mesure que l’entreprise se développe, davantage de développeurs sont nécessaires. Compte tenu de l'environnement écologique mature de Java et de l'écosystème Go émergent, nous avons finalement choisi un écosystème où Python, Java et Go coexistent dans plusieurs langages.

WebAPI effectue principalement certaines opérations courantes sans rapport avec la logique métier, telles que le déchargement HTTPS, la limitation de courant et la vérification de sécurité.

Service Orchestrator est une couche d'orchestration de services qui réalise la conversion de protocole des réseaux internes et externes ainsi que l'agrégation et la personnalisation des services via la configuration.

Sur le côté droit du schéma d'architecture se trouvent quelques systèmes auxiliaires entourant ces frameworks orientés services, comme le système Job pour exécuter régulièrement une tâche. Nous disposons de près de 1 000 services. Comment surveillons-nous ces systèmes ? Il doit donc y avoir un système de surveillance. Lorsqu'il n'y avait que plus de 30 personnes au début, nous étions meilleurs pour courir vers la machine pour rechercher les journaux. Mais lorsqu'il y a plus de 900 personnes, vous ne pouvez pas tous aller à la machine pour rechercher les journaux dont nous avons besoin. un système de journalisation centralisé. Les autres systèmes ne seront pas décrits un par un ici.

Rome ne s'est pas construite en un jour, les infrastructures sont un processus évolutif. Nous avons une énergie limitée, alors que devons-nous faire en premier ?

Lorsque le site Web s'agrandit, la structure d'origine ne peut pas suivre le rythme de développement. La première chose que nous devons faire est :

Divisez le grand Repo en un petit Repo, divisez le grand service en petits services et divisez nos services de base centralisés en différentes machines physiques.

La répartition des services à elle seule a pris plus d'un an, ce qui est un processus relativement long.

Dans cette démarche, il faut d'abord avoir une bonne définition de l'API. Car une fois votre API en ligne, le coût de réalisation de certaines modifications est assez élevé. De nombreuses personnes compteront sur votre API et, souvent, vous ne saurez pas qui dépend de votre API. C'est un gros problème.

Ensuite, faites abstraction de quelques services de base. De nombreux services originaux sont en réalité couplés dans le code métier d’origine. Par exemple, prenons le secteur des paiements. Lorsque l'activité est très simple, le code étroitement couplé n'a pas d'importance. Mais lorsque des entreprises de plus en plus étendues ont besoin de services de paiement, devez-vous en créer un pour chaque activité (par exemple, une fonction de paiement) ? ? Par conséquent, nous devons extraire ces services de base, tels que les services de paiement, les services SMS, les services push, etc.

Le démantèlement des services semble très simple et de peu de valeur, mais c'est exactement ce que nous devons faire dès le début. En fait, pendant cette période, toutes les architectures précédentes peuvent être reportées, car si vous ne faites pas d’ajustements architecturaux, les gens ne mourront pas, mais si vous ne démantelez pas les services, les gens mourront réellement.

Le fractionnement des services doit être un processus long, mais c'est en fait un processus très pénible et nécessite beaucoup d'ingénierie système des systèmes de support.

La libération est le plus grand facteur d'instabilité. De nombreuses entreprises ont des limites strictes sur les fenêtres de temps de publication, par exemple :

• Seulement deux jours par semaine pour publier ;
• Absolument pas posté le week-end ;
• La publication n'est absolument pas autorisée pendant les périodes de pointe ;
• Attendez...

Nous avons constaté que le plus gros problème avec la publication est qu'il n'y a pas d'opération de restauration exécutable simple après la publication. Qui effectuera l'opération de restauration ? Le personnel de publication peut-il l'effectuer ou nécessite-t-il une personne dédiée pour l'effectuer ? S'il s'agit d'un éditeur, l'éditeur ne travaille pas en ligne 24 heures sur 24. Que dois-je faire s'il y a un problème et que je ne trouve pas quelqu'un ? S'il existe une personne dédiée pour effectuer la restauration et qu'il n'y a pas d'opération de restauration simple et unifiée, alors cette personne doit se familiariser avec le code de l'éditeur, ce qui n'est fondamentalement pas réalisable.

Nous avons donc besoin d'un système de publication. Le système de publication définit une opération de restauration unifiée. Tous les services doivent suivre l'opération de restauration définie par le système de publication.

Il est obligatoire que tout le monde se connecte au système de publication dans Ele.me. Tous les systèmes doivent être connectés au système de publication. Le cadre du système de publication est très important. Cette chose est en fait très importante pour l'entreprise et doit être prise en compte dans la première file d'attente prioritaire.

La prochaine étape est le framework de service d'Ele.me, qui divise un grand Repo en un petit Repo et un grand service en un petit service pour rendre nos services aussi indépendants que possible. Cela nécessite un ensemble de framework de services distribués à prendre en charge.

Le cadre de services distribués comprend l'enregistrement des services, la découverte, l'équilibrage de charge, le routage, le contrôle de flux, le disjoncteur, la dégradation et d'autres fonctions, qui ne seront pas abordées une par une ici. Comme mentionné précédemment, Ele.me est un écosystème multilingue, comprenant Python et Java. Notre framework orienté services est également multilingue. Cela aura un impact sur notre sélection ultérieure de certains middlewares, comme la couche DAL.

Lorsque le volume d'activité augmente, la base de données deviendra un goulot d'étranglement.

Au début, les performances de la base de données peuvent être améliorées en mettant à niveau le matériel. Par exemple :

• Mise à niveau vers une machine avec plus de processeurs ;
• Changez le disque dur contre un SSD ou quelque chose de plus avancé.

Mais l’amélioration du matériel a finalement une limite de capacité. De plus, de nombreux partenaires commerciaux exploitent directement la base de données lors de l’écriture du code. Il y a eu de nombreux cas où la base de données a explosé dès la mise en ligne du service. Une fois la base de données détruite, il n’y a aucune autre chance de restaurer l’entreprise à moins que la base de données ne soit restaurée.

Si les données de la base de données sont normales, l'entreprise peut effectivement être indemnisée. Ainsi, lorsque nous construisons la couche de service DAL, la première chose à faire est de limiter le courant, et d'autres choses peuvent être mises de côté. Ensuite, pour la réutilisation des connexions, notre framework Python utilise un modèle multi-processus, mono-thread et coroutine.

En fait, plusieurs processus ne peuvent pas partager une connexion. Par exemple : 10 processus Python sont déployés sur une machine et chaque processus dispose de 10 connexions à la base de données. S'étendant à 10 machines, il existe 1 000 connexions à la base de données. Pour les bases de données, les connexions coûtent très cher et notre couche DAL doit réutiliser les connexions.

Cette réutilisation des connexions ne concerne pas la réutilisation des connexions du service lui-même, mais la réutilisation des connexions sur la couche DAL. Autrement dit, le service dispose de 1 000 connexions à la couche DAL. Après la réutilisation des connexions, la base de données ne peut conserver qu'une douzaine de connexions. Une fois qu'il est découvert qu'une requête de base de données est une transaction, DAL vous aidera à conserver la relation correspondante de cette connexion. Lorsque la transaction se termine, la connexion à la base de données est remise dans le pool partagé pour être utilisée par d'autres.

Ensuite, fumez et fusionnez. La base de données peut également fusionner. Lorsque la base de données fume, nous supprimerons certaines requêtes de base de données pour garantir qu'elle ne plante pas.

Après le cadre de service, vient la question de la gouvernance des services. La gouvernance des services est en fait un vaste concept. La première consiste à enterrer des points. Vous devez enterrer un grand nombre de points de surveillance.

Par exemple, s'il y a une demande, si la demande est réussie ou échouée, et quel est le temps de réponse de la demande, mettez tous les indicateurs de suivi sur le système de suivi. Nous disposons d’un grand écran de suivi avec de nombreux indicateurs de suivi. Une équipe dédiée surveille cet écran 72 heures sur 7. S'il y a une fluctuation dans la courbe, quelqu'un sera trouvé pour la résoudre. L'autre est le système d'alarme. Les éléments affichés sur un écran de surveillance sont toujours limités et ne peuvent afficher que ces indicateurs clés très importants. A cette époque, un système d’alarme est nécessaire.

Rome ne s'est pas construite en un jour et les infrastructures sont un processus évolutif. Nos ressources et notre temps sont toujours limités. En tant qu'architecte et CTO, comment pouvons-nous produire des choses plus importantes avec des ressources aussi limitées ?

Nous avons construit de nombreux systèmes et pensons que nous avons fait du bon travail, mais en fait, ce n'est pas le cas. J'ai l'impression que nous sommes revenus à l'âge de pierre, car il y a de plus en plus de problèmes et de plus en plus de demandes. j'ai l'impression qu'il y a encore des lacunes dans votre système. Il y a beaucoup de fonctions que je veux faire avec quelque chose.

Par exemple, pour le système de contrôle de flux, nous avons toujours besoin que l'utilisateur configure un numéro de simultanéité, donc ce numéro de simultanéité n'exige-t-il pas du tout que l'utilisateur le configure ? Est-il possible de contrôler automatiquement le nombre de concurrences en fonction de l'état de notre service lui-même ?

Ensuite, il y a la méthode de mise à niveau du SDK qui est une chose très pénible. Par exemple, notre framework de services 2.0 a été publié en décembre de l'année dernière, et certaines personnes utilisent encore la version 1.0. Est-il possible de réaliser une mise à niveau sans perte du SDK ? Nous pouvons contrôler nous-mêmes le temps et le rythme de la mise à niveau.

De plus, notre surveillance actuelle ne prend en charge que l'agrégation sur le même service et n'est pas divisée en clusters ou en machines. Les futurs indicateurs seront-ils divisés en clusters et en machines ? Pour donner l'exemple le plus simple, s'il y a 10 machines sur un service, il peut y avoir un problème sur une seule machine, mais tous ses indicateurs seront répartis équitablement sur les 9 autres machines. Vous constatez simplement une augmentation de la latence globale du service, mais il est possible qu'une seule machine ralentisse l'ensemble du cluster de services. Mais nous ne sommes pas encore en mesure de surveiller davantage de dimensions.

Il existe également une alarme intelligente. Cette alarme doit être rapide, complète et précise. Nous sommes désormais capables de la faire plus rapidement et de manière plus complète. Chaque jour, aux heures de pointe, plus de 1 000 alarmes sont envoyées chaque minute. Les mille alarmes sont-elles toutes utiles ? Après avoir appelé la police trop de fois, cela équivaut à ne pas appeler la police du tout. Tout le monde était fatigué et a arrêté de regarder. Comment puis-je distinguer cette alarme avec plus de précision ? Existe-t-il une analyse de liens plus intelligente ? À l'avenir, ne devrions-nous pas mettre des indicateurs de suivi dans notre suivi, mais une analyse de liens, afin de savoir clairement à quel nœud correspond le problème.

Ces questions mettent en jeu un principe de notre travail : tant que les choses suffisent, nous devons être capables de nous préparer aux jours de pluie et d'assurer une certaine planification à l'avance.

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!