Auteur | Bangqing

Source | Alibaba Middleware (ID: Aliware_2018)

Figure | IC oriental

Profil personnel:

Avez-vous rejoint les affamés en décembre 2014? > Walle), principalement pour le service client et BD.

En mai 2015, il a commencé à contacter la recherche et le développement du système de commandes et, en juillet, responsable de l'équipe de développement des commandes; au stade d'une application unique à la service.

L'équipe de test mise en place début 2016, après la division de la commande en positive et inversée, est principalement responsable du positif et de la livraison.

En 2017, certaines plateformes ont été expliquées.

Début 2018, l'intégralité de la commande était responsable de la hausse et de la livraison de l'ensemble de la commande. L'ordre de la commande et le panier au milieu de l'année ont été fusionnés ensemble.

En octobre 2019, il a été transféré de la transaction et l'efficacité et la structure organisationnelles ont été réalisées en peu de temps.

Pourquoi ai-je écrit cet article et la raison:

Tout d'abord, je l'ai fait dans la zone de négociation pendant 4 ans. Il y a beaucoup d'histoires que je ne sais que si je sais, et je veux garder ces dossiers et les conserver.

La seconde est que lorsque de nombreux étudiants à l'arrière regardent le système de trading, le contact est distribué, SOA, des millions de millions de données par jour, sachant que c'est comme ça, et il est difficile de comprendre la pensée et les raisons derrière elle . Avec votre expérience ces dernières années, vous pouvez rendre chacun plus facile à comprendre les raisons et le parcours de ce processus d'évolution.

Troisièmement, il y a de nombreux résumés ou méthodologies. Il s'agit davantage de supprimer les «scories» devant tout le monde. Ici, vous pouvez ajouter un peu de «soupe de poulet toxique». La réalité n'est peut-être pas si belle. Nous avons beaucoup de choix. Écoutez, peut-être que c'est chanceux, c'est peut-être une erreur.

Cet article espère présenter tout le voyage à travers certaines histoires de développement et la réflexion. Vous pouvez voir beaucoup de traces de croissance brutales, et aura une réflexion et un résumé, mais ce ne sera pas comme un résumé de nourriture rapide de nombreuses vérités.

Ensuite, nous partons de la période Taikoo en 2012.

Tai ancien

Avant de parler des ordres, nous réindions l'archéologie archéologique. À l'ère Taikoo, il y avait un système appelé System Zeus appelé Zeus. Ce sont tous dans une bibliothèque de code et déployés dans la même machine. Il y a deux curs en dehors de Zeus, c'est-à-dire, c'est-à-dire, c'est-à-dire, c'est-à-dire, c'est-à-dire, La «station principale» souvent mentionnée par de nombreuses personnes âgées, et NAPOSPC pour les marchands. Ces systèmes communiquent via le protocole Thrif. À l'exception de ce lien, toutes les fonctions internes désordonnées sont toutes dans un système appelé Walle. Ce système Walle est écrit en PHP.

Ensuite, le Zeus à l'époque ressemblait à ceci:

Selon l'inact, de l'histoire de la soumission de GIT, le premier engagement de la partie de l'ordre a été soumis par Yu Lixin le 1er septembre 2012, et le contenu a été "Ajouter un service EOS pour Zeus. Cet EOS fait référence au système de commande c'est-à-dire l'abréviation de l'Elemeorderservice. Ce terme est utilisé aujourd'hui, devenant une partie positive de la transaction, et même une période de temps pour le groupe de commandes.

Zeus a ensuite restructuré, appelé Zeus2, mais le temps spécifique n'est plus disponible.

bourgeon

En octobre 2014, je suis allé à l'interview quand j'avais faim. L'intervieweur était le Frère Lei Lei. Le 1er décembre, ai-je eu faim? HR m'a conduit avec un look mignon. Quand je suis allé chez Brother Lei, Lei m'a amené à JN et m'a dit: "C'est le stagiaire." Ran. Plus tard, j'ai appris qu'après l'interview, Lei Brother et JN ont dit qu'ils venaient de faire face à un stagiaire, qui pouvait l'utiliser. Il s'est produit que le groupe marchand avait un plan pour transformer Java. Un repas m'a vendu.

Retour au sujet, de décembre 2014 à avril 2014, j'ai coopéré avec l'ancien système BD pour migrer vers Walis, et après mon transfert de mentor à l'équipe CI, moi-même, moi-même, moi-même, moi-même, moi-même terminée Walis de Single -Application Migration vers les applications distribuées.

Établissement d'un groupe de commandes

Pour moi, c'est complètement de la chance et du destin.

Presque en mai 2015, mon superviseur, JN Class Camate, m'a soudainement trouvé, avait l'air très excité et m'a dit que l'entreprise avait l'intention de créer un groupe de commandes. Ce groupe de commandes est responsable de lui. Sauf pour lui, il, il, il , il ne m'a choisi que (probablement à cause d'une partie de l'expérience que j'ai mentionnée dans le paragraphe précédent, dans la personne facultative, et je me suis quand même réunie ~), disant comment je le laisse le regarder, cet homme scintille, un a établi un par un, un a établi un par l'un des.

En tant que technicien, son cur est très bouillant. Tout d'abord, j'ai entendu parler de la concurrence élevée, à un trafic élevé, distribué de grands noms avant d'en avoir entendu parler. Je n'ai jamais pensé que je pourrais entrer en contact avec un tel système si tôt. Il n'y a presque pas de demandes pendant la journée. BD Visiter les marchands retourné. Il s'est avéré être une période de pointe la nuit. Même la nuit, l'interface clé unique occasionnellement quelques-unes et une douzaine de demandes. La suspension peut ne pas être appelée un système. À ce moment-là, nous avons quitté le travail avant 7 O'Clock le soir. Lorsque nous avons été libérés pour la première fois, je m'avais dit très solennellement que nous pourrions avoir à faire des heures supplémentaires jusqu'à 20h30.

La raison pour laquelle il a choisi JN en tant que personne responsable du groupe de commandes, car bien qu'il soit ingénieur avant, il a fait le système de fond "Edge", mais c'était une personne qui connaissait tous les systèmes et les entreprises de l'entreprise entière, et elle était très adaptée au système d'ordre de développement.

Eh bien, oui, la veille de la création de ce groupe, nous n'en avons eu que deux. À ce moment-là, je n'avais pas obtenu mon diplôme. Sauf pour l'excitation, j'étais plus gêné.

Le 12 mai 2015, le groupe de commandes a été officiellement établi. Quand j'en ai parlé. Il est arrivé qu'il y ait un petit frère qui a rejoint le travail ce jour-là. Ce n'était pas mal. Il s'est avéré être un ingénieur Java. En conséquence, le jour de sa création, le nombre d'entre nous a doublé et s'est transformé en 4 personnes.

Nous nous donnons la première tâche: le code de lecture, les affaires rationnelles, le dessin. J'ai postulé pendant un mois pour tamponner avec CTO, et cette fois ne prend aucun besoin commercial.

La personne responsable de l'ancien programme principal de l'ordonnance, le chef du cadre Python et la personne en charge de l'opération de demande et de la maintenance du fonctionnement de l'application de l'ordre ont été invités à nous expliquer. En fait, le partage de tout le monde est plus d'une heure. Ce mois provenait vraiment de dizaines de milliers de lignes de code Python. Il n'y avait pas de documents de produit. C'était des commentaires extrêmement rares. J'ai finalement résumé le cycle de vie, les opérations clés et la logique commerciale clé de l'ensemble de l'ordre sur une image large. Cette image, nous l'avons utilisée pendant plus d'un an.

En fait, avait faim au milieu de l'année?

On peut dire que c'est une période de développement chaotique et rapide. Nous avons dit que le temps devait changer le pneu en conduisant une voiture de sport.

Découplage de zeus

La première super tâche qui est vraiment étroitement liée à l'ordre concerne le découplage de Zeus à partir de juin. Le professeur HC est la personne en charge du cadre Python et l'un des experts techniques les plus admirés et les plus admirés. Sur QCON, comme le L'architecte en chef, il a présenté l'architecture technique globale de Hungry à l'époque. Il a été mentionné dans la période Taikoo que Zeus est une application monomère géante. Afin de se développer rapidement à l'avenir, de réduire le couplage et un impact implicite, la société a lancé le projet de découplage Zeus. En bref, le mot est divisé.

Après plus d'un mois de réunion intensive, le plan divisé a été achevé. Il ne semble pas si difficile à dire, mais cette guerre de salive n'a pas été autorisée à être attaquée à l'époque. Qui appartenait aux différents services après la scission? Il n'y a pas de propreté entre les modules et le module, comment définir les limites des services A et B, etc. À ce moment-là, je n'ai pas été suffisant pour participer à la discussion.

La conclusion est que Zeus sera divisé en plusieurs services principaux ci-dessous:

• Zeus.eos = > Service de commande

• Zeus.eus = > Service utilisateur

• zeus.ers = > Service marchand

• Zeus.eps = > Services de marketing (nouveaux produits)

• Zeus.sms = > Service SMS

• Em

La première phase

Chaque service après avoir été divisé est suivi d'une nouvelle vague de reconstruction et de fractionnement. Par exemple, Biz.Booking est séparé de Zeus.eos et a enlevé les capacités de commander et de caddages de l'achat; Biz.UGC a enlevé les capacités liées à l'évaluation de la commande.

Plusieurs étapes de l'expérience principale divisée:

1. (juillet) Partagez l'entrepôt de code et exécutez-le indépendamment selon le module. Autrement dit, après que tout le code de Zeus est emballé sur le serveur, la division est divisée en fonction de la division, et seul le module spécifique est démarré séparément sur la machine spécifique pour ouvrir le port spécifique.

2. (août) Étape proxy. Autrement dit, dans le service d'origine, un agent à ajouter à l'interface à déplacer peut être agent à l'interface du nouveau service, et la capacité de commutation du centre d'enregistrement de service pour contrôler le flux de commutation.

3. (août au début de septembre) La segmentation complète du script et du module.

4. (septembre) Indépendance de l'entrepôt du code. Le filtre à arme nucléaire du GIT est utilisé pour séparer le code et l'historique dans le module et complètement séparé de la bibliothèque de code d'origine. À l'heure actuelle, le déploiement est toujours un tissu mixte. Dans l'outil de version, après la publication d'une application indépendante, il a en fait remplacé un répertoire sous le grand projet de Zeus.

5. (septembre) Indépendance de la configuration. La configuration d'origine a été brossée sur le serveur par Saltstack et a été partagée par plusieurs applications sur le serveur. Nous l'avons changé directement aux capacités de configuration de l'utilisation du centre d'enregistrement de service pour obtenir une seule configuration d'application. À ce stade, il est également passé à la charge souple.

6. (mars de l'année suivante) Indépendance du déploiement de la physique. Bien sûr, c'est le contenu du découplage.

Bien sûr, cette scission a également apporté un autre produit. Le framework SOA de Python Zeus_Core, Zeus_Core a été séparé par les services commerciaux vers avril.

Toute la période de découplage a duré environ un demi-an. Pendant la période, aucun accident n'a été causé par la division et il n'y avait presque pas de fumée. Pensez à rien à ce moment-là à ce moment-là, les outils sont en arrière, il n'y a pas de test à temps complet et l'alphabétisation technique d'un groupe d'ingénieurs précoces et de camarades de classe d'opérations et de maintenance.

Sous-mètre

C'est encore en 2015. Il est vers septembre et octobre que la table de succursale est déterminée comme étant mise en uvre, et le schéma de la table de succursale est presque finalisé lorsque j'interviens et est dirigé par l'équipe DAL du département CI.

Pourquoi faites-vous une table divisée?

Tout d'abord, je ne peux pas porter de concurrence Essence À ce moment-là, MySQL de notre bibliothèque de commandes était une architecture de 1 maître et 5, et un MHA a été fabriqué. La DB n'est pas en mesure de résister à la pression du simultanément à l'époque, et sa résistance aux risques est très faible. Si l'entreprise n'informe pas certaines activités à l'avance, une fois que nous en accrochons une à la bibliothèque, nous ne pouvons que les couper d'avant en arrière. Dans les cas graves, nous ne pouvons limiter que beaucoup de courant. De plus, pendant ce temps, en tant que technologie, nous avons également prié pour que Meituan à retenir ne soit pas suspendu dans la période de pointe. Une fois que le meituan à emporter sera suspendu, le trafic se déroulera vers les affamés et nous commencerons à être nerveux. De même, pendant cette période, nous avions toute une station, et Meituan Takeaway n'était pas très en mesure de le porter. Tout le monde connaissait une étape de développement similaire.

La seconde est que le coût du DDL est trop élevé et que l'entreprise est au sommet des combats. Le seul volume des affamés à l'époque était au début d'un million de yuans. Il y a des besoins commerciaux, j'espère ajouter de nouveaux champs à la commande. Cependant, lorsque nous trouvons l'évaluation DBA, la réponse donnée est que l'estimation optimiste doit être arrêtée pendant 3 heures, l'estimation pessimiste prend 5 heures et l'approbation du PDG est obligatoire. De toute évidence, ce risque est difficile à accepter et l'équipe commerciale ne peut pas l'accepter. Ensuite, la solution spéculative consiste à continuer à brancher le champ d'expansion JSON réservé. Cette méthode a soulagé une longue période de pression dans une certaine mesure, mais elle a également enterré de nombreux dangers cachés.

Bien sûr, il existe des scénarios commerciaux spéciaux et des interfaces avec une grande taille de particules qui sont ouvertes, ce qui produira des SQL de performance médiocres, ce qui fera exploser toute la station.

La structure physique après Shardin est la suivante:

La logique de l'opération de mise à jour est la suivante:

En fait, nous avons fait un fragment à deux dimensions. Les deux dimensions sont 120 pièces, mais peuvent être écrites de trois manières (ID utilisateur, ID marchand, ID de commande) pour assurer le succès de la dimension de l'utilisateur. En raison des ressources, les utilisateurs et les commerçants sont échelonnés et mélangés.

(En fait, il y a quelques fosses dans la partie épaisse. Cette personnalisation spéciale est également la seule. Si vous êtes intéressé, vous pouvez l'étendre à l'avenir)

Les détails techniques des tables de base de données plus spécifiques ne sont pas élargis ici, et il a connu plusieurs étapes:

1. Formuler les nouvelles règles de génération de numéros de commande et terminer l'accès à la transformation.

2. Double données, lisez l'ancien, comparez les données.

3. Réforme le SQL incohérent, tel que le tri et les statistiques de la puce croisée, sans le SQL de Shardingkey, etc.

4. Double données, lisez nouveau. (Synchronisation avec 3)

5. Complétez le commutateur de la base de données et les données sont écrites et nouvelles.

Pendant ce temps, en tant qu'équipe commerciale, la plupart du temps passé dans la troisième partie, et a travaillé plusieurs fois jusqu'à 3 ou 4 heures du matin.

À la veille du festival du printemps en 2016, afin de dépenser des pics commerciaux et une stabilité du système, nous avons même mis en place des données en dB uniquement pour les commandes au cours des 15 derniers jours.

Je me souviens du jour où j'ai finalement changé. Vers mi-mars 2016, plusieurs camarades de classe et moi sommes allés à l'entreprise à plus de 5 heures du matin, et le ciel était brillant. Toute la faim commence à arrêter le service, puis bloquez la demande d'écriture, complétez la configuration de la direction de DB, vérifiez sans erreur, restaurez la demande d'écriture, vérifiez que l'entreprise est correcte, lâchez lentement le trafic avant et re -Ourer le service. Le cur de l'ensemble du processus est d'environ 10 minutes, et l'ensemble du service d'arrêt dure une demi-heure.

Le deuxième jour, nous avons pu importer des commandes historiques au cours des 3 derniers mois.

Après ce changement, nous nous sommes essentiellement débarrassés du goulot d'étranglement et du point de douleur de DB (bien sûr, l'histoire derrière nous dit que parfois c'est encore un peu naïf ~~~)

Difficulté de message

À cette époque, vers juillet, il a été affecté par certains articles architecturaux. C'est aussi parce que JN a mentionné cela. Nous avons décidé de diffuser l'ordre de l'ordre, l'objectif principal était de se décomposer davantage.

Après avoir enquêté sur Rabbitmq, NSQ, RocketMQ, Kafka, ActiveMQ, la conclusion finale que j'ai parvenue était Rabbitmq. En fait, je pense que RocketMQ est plus approprié, en particulier les caractéristiques des messages séquentiel Support. Cependant, la principale expérience de fonctionnement et de maintenance de l'équipe de fonctionnement et de maintenance se trouve à RabbitMQ. Les étudiants de l'équipe du cadre et de l'équipe d'exploitation et de maintenance sont très confiants. Depuis l'établissement, il n'y a eu aucun problème. L'un est stable. Si vous choisissez RabbitMQ, vous pouvez obtenir le soutien naturel de l'équipe d'opération et de maintenance. C'est pour notre L'équipe commerciale à ce moment-là., Évitez de nombreux risques.

Par conséquent, l'équipe du cadre entreprend un test de performance rigoureux sur RabbitMQ pour donner quelques indicateurs de performance. Ce test a finalement mis en place un cluster composé de 3Broker, qui sert l'ordre seul. Avant cela, il n'y avait qu'un seul nud MQ pour servir la tâche de message asynchrone du système Zeus.

Afin de s'assurer que le processus grand public de la transaction n'a pas d'impact, une série de transformations tolérantes à défaut est effectuée sur le cadre du SOA côté client. Il s'agit principalement de la tolérance aux défauts en temps opportun, comme l'envoi de temps et de déconnexion lors de la connexion le cluster MQ. En fin de compte, le cluster MQ composé de 3 nuds a été construit, et la nouvelle de l'ordre a finalement été envoyée à ce cluster.

Pendant cette période, j'ai en fait monté sur une petite stand. Bien que l'équipe de cadre ait effectué une tolérance anormale à la défaut. Mais après tout, le moment de la diffusion des nouvelles est étroitement lié à l'état du processus grand public. Avant le lancement du code, j'ai toujours été prudent à l'époque, ajoutant un passage au message envoyé pour la première fois. C'était une nuit, vers 8 heures. Maintenant, quand j'y pense, il y a de courts niveaux de gris et de temps d'observation. Quand j'ai été libéré, il a été rapidement vu dans la surveillance que l'interface a commencé à être gravement disparu (nous Utilisé la trame par défaut par défaut par défaut à l'époque. Les paramètres de délai d'expiration, 30s, en fait, cette configuration est très grave), ce qui génère un grand nombre d'interfaces sévères, et il est évident qu'il existe un ralentissement de l'interface. La courbe de négociation est tombée et j'ai été immédiatement fabriqué par NOC. Il a rapidement fermé l'interrupteur envoyé par le message, et la récupération a également été un instant. Ensuite, la chair humaine a couru vers l'avant de l'équipe d'architecture pour aider l'enquête (après tout , c'était encore à l'époque. Trop de légumes).

Cette nuit-là, nous avons ouvert, fermé, ouvert, désactivé, ouvert, désactivé ... Trafic à partir de 5%, 10%, 30%, etc. Après différentes tentatives et vérifications, la conclusion finale était liée à la configuration d'haproxy à l'époque. Étant donné que Haproxy a clôturé la connexion avec le cluster RabbitMQ à l'avance, le client du service a toujours demandé la connexion nécrotique, ce qui a provoqué ce problème, et le client n'a pas toléré le délai d'attente. Après avoir ajusté le délai de liaison de l'haproxy, les symptômes ont été éliminés. Bien qu'il reste des dangers cachés du journal.

Pour le moment, c'est comme ça. La partie commerciale de chaque accès doit demander un sujet. La quantité de file d'attente suspendue sous le sujet peut la déterminer en fonction des besoins de l'entreprise.

Il y a de nombreux problèmes dans le fonctionnement stable de cette architecture physique et en cours moins d'un an, et le prochain chapitre sera à nouveau élargi.

En termes d'utilisation, il y avait plusieurs principes à l'époque:

1. L'ordonnance n'est pas directement exposée à son propre état, mais est exposée à la manière extérieure. Parce que le statut est une description, et l'événement représente une action, et les détails de l'état de commande et les accessoires peuvent être découplés en même temps.

2. La diffusion de messages n'est utilisée que pour les événements de diffusion, pas pour la synchronisation des données. Si les consommateurs ont besoin de plus de données, vérifiez l'interface de données de commande et l'horodatage contient l'heure de l'événement et le délai de livraison (l'heure est ajoutée plus tard). Autrement dit, le message comprend des informations d'en-tête, uniquement le contenu utilisé pour expliquer l'événement, et comprend également la clé principale de la transaction et certaines informations qui peuvent être utilisées pour le filtrage général ou les itinéraires secondaires.

3. Les consommateurs devraient assurer leur propre pouvoir lors des messages des consommateurs, et en même temps, ils ne devraient se faire aucun état lorsqu'ils consomment. Si vous devez consommer dans l'ordre, il est mis en uvre par le redis et d'autres solutions.

4. Lorsque l'accès aux consommateurs, le sujet et la file d'attente doivent suivre une certaine spécification de nom. En même temps, la profondeur maximale de la file d'attente est de 10k, ce qui est abandonné. Les consommateurs doivent clarifier s'ils acceptent les nouvelles et assurer leur propre performance de consommation. Selon l'évaluation à l'époque, lorsque l'accumulation de message a atteint un million, les performances de l'ensemble du cluster ont diminué de 10%. (Sous les conseils de l'architecture mondiale, nous avons également fourni un médium avec Redis comme moyen pour stocker les événements de commande comme une image miroir, mais l'expérience n'est pas assez élégante)

L'architecture logique de cet ensemble de nouvelles diffusées a été continuellement utilisée aujourd'hui, et d'énormes dividendes ont été produits dans le découplage.

Exploration préliminaire

Du milieu de -15 ans au début de 16 ans, nous sommes au stade d'un seul volume de plus d'un million et croît progressivement rapidement.

OSC

Au cours de cette période, j'ai également lu de nombreux articles architecturaux, ESB, SOA, Microservices, CQRS, Eventsource, etc. Nous explorons également activement la restructuration du système de commande pour soutenir une concurrence plus élevée. À cette époque, le plus écouté était l'OFC de JD.com. Il a également acheté spécialement le «décryptage technique JD» et étudiait, mais il a rapidement conclu qu'il n'y avait presque pas de grande valeur de référence. La raison principale est que l'OFC de JD est évidemment déterminé par les caractéristiques du commerce de détail. De nombreux concepts de l'OFC, en tant que superficiel dans notre banque, sont presque difficiles à comprendre lorsque nous avons mis en place un O2O à restauration. Mais nous en sommes encore affectés et prenons une abréviation similaire pour le centre de service du groupe, OSC.

Étant donné que cette commande est en service depuis plus de 3 ans, la pile de langues principale de l'entreprise est également de Python à Java de Python. Il n'a pas fallu longtemps pour réécrire ce système de commande. En conséquence, j'ai conçu un système d'architecture qui a utilisé OSC comme préfixe de domaine. Le concept principal de ce système: l'ordre est de maintenir l'instantané du temps de négociation, de maintenir sa propre simplicité autant que possible, de réduire la dépendance à l'égard de toutes les parties et de réduire le rôle des canaux de données.

La sélection de la pile linguistique que nous avons choisie est Java, qui est prévue pour commencer la transformation de Java. (Malheureusement, nous nous sommes vraiment transformés en Java en 2019).

En ce moment, nous sommes en septembre. Par coïncidence, l'entreprise a commencé à créer un nouveau système d'examen de l'architecture de service pour la première fois. Mon plan est probablement les Top1 et 2 Little White Rats participant à la revue. Fresh Sledgehammer attend de frapper les gens.

En fait, après un an après cela, j'ai examiné cette revue d'architecture, non pas parce qu'elle est passée, mais parce qu'elle a été rejetée.

C'était drôle de le dire. À ce moment-là, je me souvenais légèrement des juges qui ont participé à la revue d'architecture.

Le point de questionnement de l'architecte à cette époque a pu l'utiliser pendant un an ou 3 ans dans cette architecture, et la question de la personne en charge des OP de base était particulièrement intéressante. Il a posé la première question. Ce système est-il un chemin clé ? Je pensais que ce n'est pas ce non-sens, j'ai répondu directement, la partie centrale l'est.

Ensuite, la deuxième question, le problème, cette application peut-elle être rétrogradée? Je pensais que ce non-sens n'est-ce pas? Bien sûr, ce lien ne peut pas être rétrogradé. C'est le lien de base et de base. Le principal activité de l'entreprise est d'entourer la transaction. (Il se peut que la compréhension des deux parties ne soit pas sur un seul canal).

Donc, la conclusion qu'il a donnée était, Le chemin clé est l'ordre de base, qui ne peut pas être rétrogradé. Une fois qu'il y a un problème, tout le monde n'a pas de nourriture. L'examen était donc terminé et la conclusion n'a pas été adoptée.

Établir une équipe de test

L'équipe de trading n'a pas subi de test à temps complet, c'est-à-dire que tout le contenu est garanti par la R&D et l'auto-test. Le test d'automatisation de l'entreprise à l'époque était très faible, et presque tous les tests ont été effectués à la main. Cependant, pour le moment, je me sentais très nécessaire pour obtenir des ressources de test. J'ai une demande solide pour mettre en place une équipe de test pour ajouter une couche de protection à la qualité de la commande.

À ce moment-là, des choses intéressantes se sont produites. Selon JN, l'équipe du cadre n'a pas été testée. Cependant, ils ne semblaient pas avoir de problèmes. À ce moment-là, ils ont fièrement expliqué pourquoi la technologie ne devrait pas garantir la qualité du code eux-mêmes . C'était juste simple et impeccable. Je pense qu'il y a des idéaux dans ce point de vue. Il peut ne pas être facile de trouver leurs propres erreurs. L'introduction d'un autre groupe de personnes peut couper sous un autre angle, ce qui peut encore améliorer la qualité de la qualité. Après tout, ce système est si important et à haut risque, mais nous ne devons pas être établis une équipe de test qui ne peut fournir que "point".

Enfin, après une longue communication avec JN, nous avons déterminé le positionnement et les responsabilités de l'équipe de test à ce moment-là: pour nous assurer que la qualité du code est la responsabilité qu'elle doit être développée. Sur cette base, le développement du test fournit principalement l'outil soutien pour réduire le coût du test. Dans le même temps, offrant un certain degré de garantie de test à l'allocation du permis d'énergie.

Par conséquent, vers février et mars 2016, l'équipe commerciale a été premier test. Presque en avril, le test HC a atteint 4 personnes et j'étais responsable de toute l'équipe de test.

La première chose est de créer un test intégré automatisé.

Le choix sur la pile technologique a adopté RobotFramework. La raison principale était que toute l'équipe a toujours pris Python comme langue principale à l'époque, et le test et le développement des élèves pouvaient réellement écrire Python et Java., La lib liée au système peut être raffiné, même si la pile de langues est transformée, le coût ne sera pas élevé.

En plus de tester les spécifications du processus et les normes de test, commencez à créer une plate-forme pour gérer les cas de test, les rapports d'exécution et d'exécution.

J'ai nommé Webot dans ce système:

• Utilisez RobotFramwork comme base de l'exécution du cas de test

• Où Jenkins est-il réellement déployé où est l'exécution et respecter la gestion du plan d'exécution

• Sur la base de Django, une interface de gestion simple est configurée pour gérer les cas et les rapports de test, et permettre à chaque cas de test d'être assemblé en tant qu'unité. Si vous connaissez Java, vous pouvez faire une analogie similaire ici. Les cas d'utilisation peuvent être considérés comme un SPI.

• De plus, Docker a été initié à déployer l'environnement de l'esclave, qui était très superficiel. Bien qu'il ait faim à l'époque, avez-vous utilisé Docker (affamé? La conteneurisation devrait être d'environ 17 ans).

Pensez à ce que je jouais avec l'environnement de test à ce moment-là, et j'ai beaucoup aimé.

La pensée générale est:

Unité d'essai : Business Library est en fait une couche d'emballage de l'interface de service SOA à RobotFramwork. Chaque unité de test peut appeler une ou plusieurs interfaces pour terminer les activités commerciales de l'atome.

Composant de vérification : Fournissez une vérification de la valeur de retour ou de la configuration supplémentaire des données Redis et de la base de données.

Tests d'intégration : Plusieurs unités de test sont organisées en ligne pour compléter un cas de test intégré. Une fois chaque unité d'essai effectuée, la demande et le repas de la demande peuvent être obtenus n'importe où dans le domaine en cours d'exécution du cas de test intégré.

Les tests de régression : Sélectionnez plusieurs tests intégrés, qui peuvent être utilisés comme schéma, configurés.

De cette façon, la réutilisation de la taille des particules à plusieurs niveaux et différentes. Selon le plan d'essai de test et de régression intégré, l'arrière-plan compile et générera les fichiers robot correspondants.

En fin de compte, ce projet a échoué. La raison principale est que les étudiants qui ont testé et développé étaient insuffisants dans le développement, et qu'il y avait plus de travaux de développement avant sur l'interface. Au début, j'ai directement appliqué l'interface de gestion étendue de Django pour faire une expansion simple. autorisé à dépenser trop d'énergie sur le dessus. Les composants frontaux construits ont des défauts dans l'expérience, ce qui conduit à une faible efficacité. En mai, le deuxième développement a été essentiellement abandonné.

Mais cette tentative a également apporté d'autres résultats. Nous sommes équivalents à l'abandon des cas de gestion des systèmes et la combinaison de Jenkins + Robotframwork est conservée. Nous sommes la garde de certains des tests intégrés écrits sur le GIT, et la R&D déploiera les succursales que nous avons développées dans l'environnement désigné. La mise en uvre sera dessinée chaque matin. Quelque chose ne va pas. Dans le même temps, l'application manuelle est également autorisée. Deux étudiants, la culture et les arts martiaux, et Xiaodong, ont contribué beaucoup d'énergie.

L'établissement de cette régression d'intégration d'automatisation fournit une garantie importante pour la reconstruction à l'échelle divisée et à petite échelle du système de commande ultérieur. Faites la bravoure R&D et les étapes peuvent être plus longues. Il sera très actif d'utiliser cet outil, et vous avez goûté beaucoup de douceur évidente.

La deuxième chose est de construire des tests de performances.

Contexte:

Je me souviens que lorsque je suis entré en contact avec la commande dans 15 ans, j'ai eu la chance de visiter le professeur XL qui avait faim. Mesure.

À cette époque, il y avait des problèmes, des performances et des capacités. Nous n'avions pas la capacité de prédire à l'avance. Par exemple, avant de terminer la rupture, une entreprise a été lancée une fois une liste de listes de commandes, car l'interface universelle existante a été utilisée (cette taille de particules d'interface était épaisse et la combinaison conditionnelle était forte), nous n'avons pas pu l'évaluer à l'avance. Query a pris un très mauvais indice de performance. À cette époque, le pic de midi était proche, et quelques interfaces de requête K KP ont été vaincues de Kuru (15 ans de notre système de surveillance et d'alarme).% Sont venus, et l'ensemble de l'ensemble a duré près d'une demi-heure. Enfin, cela revient aux changements récents, et le marchand est revenu à ce changement pour vraiment récupérer. Après enquête, le lent SQL de l'accident a provoqué environ des centaines de centaines de QP.

Les tests de performance de l'ensemble de l'entreprise étaient plus tôt que mon plan, mais le test de performance de l'entreprise à l'époque était pour 517 festivals à emporter. Il y avait une vague de camarades de classe spéciaux. La préparation et la mise en uvre ont en fait pris beaucoup de temps.

Pendant le test de pression, vous devez résoudre le problème en continu et appuyer à plusieurs reprises le test. Cet incident a fait voir de nombreux étudiants de l'apparence de chaque heure à Kintera -Iron City Square à ce moment-là. Je me souviens de ce moment. étaient déjà à 5h30 du matin. Les réverbères des deux côtés à mon arrivée à la maison étaient éteints.

Ci-dessus est un peu étranger. Bien que le test de pression de liaison complète nous apportera certainement, nous avons également des endroits où le lien complet ne peut pas être enfoncé, et il y a des interfaces ou une logique qui doivent être effectuées séparément et doivent être transportées à tout moment.

Construction:

Locust est sélectionné dans la sélection technique, car le cadre Python SOA et ses composants peuvent apporter une grande commodité. Auparavant, lorsque le test de pression de liaison complète de niveau de l'entreprise, JMeter n'était pas facile à intégrer avec le cadre SOA de Java. Il est nécessaire qu'il ait provoqué un certain inconvénient à l'époque. Une autre raison est que le concept de conception du crique peut rapprocher certains cas d'utilisation du scénario commercial réel. Seuls les indicateurs QPS sont observés, et parfois il y a une certaine distorsion.

Avec l'équipe complète des tests de performances en lien, à l'avant de la fosse, en fait, l'établissement de ma propre capacité de test de performance a été achevé rapidement. L'ensemble du processus de construction a pris plus d'un mois. Essence Les testeurs de performance comprennent l'apprentissage de la recherche et du développement, ce qui nécessite un peu de processus. Bientôt, le test de performance de notre groupe a été sorti de l'ensemble du département, y compris la fusion avec l'équipe financière par la suite.

Cette construction nous permet d'avoir certaines attentes pour notre charge de service et notre limite supérieure de performance lors de la fourniture d'une interface à l'extérieur. Nous avons évité certaines interfaces avec des dangers cachés pour aller en ligne, en particulier pour les conditions de requête complexes pour les marchands. . Certaines de nos étapes de reconstruction ont trouvé à l'avance des verrous simultanés et des dépendances d'appel des liens.

La troisième chose est un exercice de défaillance aléatoire.

Version 1.0:

Le prototype au début est en fait très simple, l'idée générale est:

1. Tirez un environnement spécial dans l'environnement de test, avec une surveillance et une base de données distinctes.

2. Construisez un client pour simuler le nombre de comportements de l'utilisateur. (Notre expérience dans l'accumulation de test intégrée automatisée a été utilisée.

3. Fournissez un outil pour créer un service dépendant du serveur simulé pour résoudre le problème de la dépendance du service à liaison longue. Mock Server peut renvoyer quelques sorties set en fonction de l'entrée.

4. De plus, l'équipe de cadre a aidé à faire des mains et des pieds et a envoyé une version spéciale, afin que nous puissions marquer le trafic. Selon le marquage du trafic par le client, le serveur simulé peut simuler certains comportements anormaux tels que l'obstruction, le délai d'expiration, etc., et les commentaires à notre serveur mesuré.

Il s'agit d'un prototype très simple, et l'ordre a été régi par plusieurs fois, et la dépendance étrangère est très faible, elle sera donc complètement formée en moins de 2 ou 3 jours. Mais ce n'est qu'un jouet, et il n'a pas de signification de référence suffisante. Parce que la concurrence n'est pas très élevée, le serveur simulé peut faire limité.

Version 2.0:

JN a convoqué certains camarades de classe et fait des roues en faisant référence au singe Choas de Netflix, et nous avons appelé le chenil.

Le dessin de conception du centre de contrôle est le suivant:

Avec l'aide de camarades de classe spéciaux et d'étudiants d'exploitation et de maintenance, Kennel était initialement disponible vers octobre 2016. Cet outil fournit: la perte de paquets de réseau de simulation; injection d'interface anormale; supprimer un nud dans le cluster; tuer violemment le processus de service, etc.

Tout le monde n'a jamais essayé cette chose auparavant, et nous ne savons pas quoi mesurer. Je voulais faire la première vague de tentatives en novembre. J'ai essayé de faire 5 scènes qui doivent être acceptées:

1. Transactions distribuées ultra-longues

2. Une interface anormale provoque toute l'avalanche

3. Un nud redémarrer dans le cluster ou le redémarrage de la machine, la réaction de l'appel est évidente

4. La charge du processeur d'un cluster devient plus élevée et la charge est inégale

5. Le service est un seul point, et le comportement du cluster est incohérent

Sur la base de ces scènes, choisissez une personne dans les camarades de classe de test pour prendre les devants de la mise en uvre. Les rapports de test de différents services sont légèrement différents, et les captures d'écran de l'une d'entre elles sont les suivantes:

Après une série du test principal de service sur la transaction, nous avons trouvé des dangers cachés:

• Dans certains cas, le nombre de clusters et les centres d'enregistrement des services déployés peut être incohérent, c'est-à-dire, une fois le nud de service tué par la violence, le centre d'enregistrement des services ne peut pas découvrir et expulser activement. Il s'agit d'un danger caché relativement important.

• Chaque cluster a une charge inégale et les machines individuelles peuvent être élevées dans l'utilisation du processeur. (Lié à la stratégie d'équilibrage de la charge)

• Lorsque la «destruction» récupère, le taux d'utilisation du processeur de certains nuds sera nettement plus élevé que les nuds, et il sera progressivement uniforme après quelques heures. (Lié à la stratégie d'équilibrage de la charge)

• Lorsque la charge du processeur à nuds unique est élevée, l'équilibrage de charge ne roulera pas le routage de débit vers d'autres nuds. Même si cette partie des performances de demande est bien pire que les autres nuds, même de nombreux délais apparaissent. (Il est lié au mécanisme de mise en uvre de l'équilibrage de la charge et du fusible. Le SOA de Python est une fusion sur le serveur, et le client ne le fait pas)

• Le réglage au fil du temps d'un grand nombre de services est faux, le cadre prend en charge la configuration des heures supplémentaires et du temps difficiles, et les bulles ne sont que l'alarme sans bloc par des erreurs de niveau bas qui peuvent ne pas éviter certains avalanches.

• Dans les scénarios individuels, la configuration du délai d'expiration échoue. Attrapez ce temps mort.

• Em

Plusieurs raisons de ce projet sont évidentes, Nous avons fait beaucoup de conception et de précautions, et nous devons combiner des exercices de défaut pour acceptation. Qu'il s'agisse d'erreurs de niveau bas ou de conception insuffisante, nous pouvons le trouver à l'avance dans une certaine mesure.

Bien sûr, nous avons également causé quelques erreurs. Un lien de rémunération (généralement pas de travail). Lorsqu'il a attaqué, il était invalide. Plus tard, il a été découvert que c'était un danger caché qui a été enterré dans un certain changement. Le pot fait par moi-même, je dois me porter avec des larmes, mais je pense que l'exercice d'échec est plus utile. Qui peut garantir que lorsque l'échec réel arrive, ce n'est pas un accident plus grave.

En plus du système favorable, le personnel a également reçu de nombreux avantages, tels que le temps réel des tests et les étudiants de R&D à travers ce projet, et l'utilisation de nos systèmes de trace et de journal dans l'utilisation. Dangers cachés et racines Des causes ont été trouvées en testant les élèves à creuser le fond des camarades de classe. Les camarades de classe QA de haut niveau sont importants et il est tout aussi important d'améliorer le niveau des camarades de classe QA.

Bien sûr, à l'exception des travaux de l'équipe de test, les tests unitaires n'ont pas été abandonnés et maintient une couverture de ligne de code de 80% à 90% en 16 ans.

Une série de problèmes avec la hausse du volume

Amélioration de Redis

Gouvernance de la posture:

Au début de 2016, le principal goulot d'étranglement était dans la base de données. En fait, il a été mentionné au-dessus de la base de données. Il peut respirer un peu. En juin, tout le monde était le plus inquiet qu'il soit devenu redis. À ce moment-là, Zabbix ne pouvait surveiller que le fonctionnement de la machine. Zabbix était en fait progressivement hors ligne. L'équipe SRE a mis en place un ensemble de systèmes de collecte d'index de machine à temps supérieur et a lu quelques données de Linux directement. Cependant, l'ensemble Reded Operation Situation C'est encore une boîte complètement noire.

Avez-vous faim? Il y a aussi beaucoup de fosses sur Twemproxy et Codis. Redis-Cluster n'a pas été utilisé dans l'industrie. Il a donc étudié un ensemble de redis proxy: Corvus. Memory, liens, taux de succès, nombre de clés, transmission Volume de données, etc. Il s'est avéré être lancé à ce stade pour remplacer Twemproxy, ce qui fait que la gouvernance de Redis a inauguré un revirement.

Nous avons coopéré avec cette migration.

À ce moment-là, nous avions trois utilisations principales de Reids. L'une était du cache, similaire aux tables et à la latitude d'interface; l'autre était des serrures distribuées, et certaines scènes ont été utilisées pour prévenir et écrire; Le code a été écrit par des prédécesseurs il y a plusieurs années.

The old posture, configure the table -level cache and interface cache in one cluster; the rest are configured in another cluster, but in terms of use, the framework is packaged with two clients, which have different fault tolerance mechanisms (that is, whether Il est fort en fonction ou peut être disponible ou disponible. Vérification).

Tout le monde sait que les transactions à emporter ont une caractéristique, Dans un court laps de temps, une commande progressera plus rapidement pendant la phase de transaction, de sorte que la mise à jour du cache de commande est plus fréquente Après la disponibilité de la vérification grise courte du cluster Redis, nous avons effectué une commutation complète (les détails du schéma de commutation spécifique à l'époque n'étaient pas clairs, et maintenant je peux réellement avoir une solution plus sécurisée).

Le cluster du cache d'origine est de 55 g et OPS prépare un cluster de 100 g. À environ 10 minutes après la commutation, la mémoire du cluster est pleine.

Nous arrivons à une conclusion incroyable ... Le 55 g de l'ancien cluster a toujours été super (par coïncidence, et les OP que nous avons migmées sont également appelés Super Brother).

Du point de vue des indicateurs de surveillance, les clés ont augmenté rapidement et TTL a diminué rapidement. Nous avons rapidement verrouillé les deux interfaces, Query_Order et Count_Order. À ce moment, il n'y a pas de problème sur le RT avant les deux interfaces, et la moyenne est de 10 ms.

À partir de notre scénario d'entreprise, le rôle principal de ces deux interfaces est de demander l'ordre d'un restaurant pendant un certain temps. Afin de s'assurer que le marchand peut voir les nouvelles commandes dès que possible, le marchand a adopté un mécanisme pour rafraîchissant. Et ce problème est principalement sur les paramètres de requête. Ces deux interfaces utilisent le cache de niveau d'interface. Le cache de niveau interface SO-So-called consiste à générer un hachage en tant que clé et la valeur de retour sous forme de valeur. C'est normal de voir. Si le horodatage du paramètre de requête est la dernière seconde de la journée, c'est en effet. Je crois que beaucoup de gens ont deviné que le horodatage est réellement passé dans le moment actuel. C'est un temps de glissement, ce qui fait que le cache est proche de 100% Miss. Essence

(Parce que la stratégie de recyclage de la mémoire des anciens et nouveaux clusters est différente, dans ce cas, les GC fréquents entraîneront des indicateurs de performance à secouer farouchement)

Ces deux caches ne sont en fait pas utiles ... après avoir roulé un jour, après niveaux de gris, le cache de ces deux interfaces a été complètement retiré. Divisé en deux grappes.

Ensuite, nous avons trouvé des choses intéressantes ...

Jetons un coup d'il à la courbe rugueuse de notre valeur de pic de caractéristique unique.

Vers 3 heures de l'après-midi après le changement, la mémoire éclate à nouveau ..., la courbe d'occupation de la mémoire est approximativement la figure suivante:

Après l'expansion d'urgence, nous avons observé le soir, et la courbe finale est devenue le chiffre suivant. Du point de vue du taux de succès, il y a également une certaine amélioration (les données spécifiques ne sont plus disponibles, entre 88% et 95% , puis il atteint plus de 98%) Essence

Pourquoi est-ce différent de l'entreprise de pointe ...

En fait, il est toujours simple de combiner l'entreprise. C'est très simple. À ce moment-là, les demandes de rotation du marchand avaient plusieurs scénarios. Le plus longtemps était de demander des commandes dans les 3 derniers jours, et il y avait une page pour interroger la commande le même jour séparément.

Le backend vérifie plus d'éléments requis que chaque page de l'avant pendant la rotation, et non, toutes les commandes du marchand ne sont pas supérieures à la journée. Par conséquent, avec le temps de la journée, le phénomène ci-dessus apparaît.

Pourquoi les indicateurs de performance précédents n'ont-ils pas vu de problèmes? Premièrement, il est lié à la sélection des stratégies de recyclage de la mémoire de l'ancien cluster Redis. La seconde est que la quantité de QPS est très élevée. Si vous ne regardez que le temps de réponse moyen, les mauvais indicateurs sont moyens et le taux de réussite est également tiré en moyenne.

Eh bien, après avoir résolu ce problème, de nouveaux problèmes ont été découverts.

Vers 1 et 2, lorsque la nuit était silencieuse, elle a été appelée par OnCall, et la surveillance a révélé que l'utilisation de la mémoire grimpait brusquement.

Nous verrouillons une interface qui n'est pas normale et query_order. Pendant la journée, le règlement s'est installé juste rénové. C'est à ce moment que ce genre de nuit était silencieux. À ce moment-là, notre période de compte était relativement longue (cela est dû au problème que l'ordre peut être retourné, et il y aura un lieu pour se développer ci-dessous). À cette époque, les commandes historiques ont provoqué une grande quantité de mémoire, et le moment de notre cache de surface est de 12 heures. S'il n'est pas nettoyé, il peut avoir un certain impact sur le pic précoce. Plus tard, nous avons fourni une interface qui n'a pas pris le cache le lendemain et l'avons donnée pour effacer le règlement seul.

Le problème central ici est que nous La serviceization est inférieure à un an. La gouvernance des services ne peut pas être très fine. L'interface du service est ouverte, exposée au réseau intérieur, et tout le monde peut appeler. Notre protocole d'interface est également ouvert. Il est facile pour quiconque de savoir à vérifier l'interface, et le vieil homme de l'entreprise est relativement sauvage (pas besoin de faire, ce qui est nécessaire, l'ajoutez simplement par lui-même). Les autorisations de fusion et de libération du code GIT Warehouse ont été récupérées et contrôlées dès 15 ans, mais à ce moment, SOA n'avait pas encore terminé, et l'autorisation d'interface n'a été prise en charge qu'au plus tard.

L'utilisation de Redis doit encore être basée sur une compréhension approfondie des scénarios d'entreprise et faire attention à divers indicateurs.

Amélioration du mécanisme de cache

Notre mécanisme de cache à l'époque était comme ceci:

Avantages de cette conception d'architecture:

1. Il existe un lien indépendant pour mettre à jour le cache, qui a moins d'invasion du service d'origine

2. Réplication des composants élevés

3. Il y a des pics MQ, et en même temps, il y a un niveau de redis, qui globe pour réduire davantage la concurrence

Dans de nombreux scénarios, c'est une architecture bien-jacente.

Décorpation:

1. La file d'attente à deux niveaux a été utilisée et le lien est long

2. Mauvais en temps réel

La raison de la transformation de nous est également dérivée d'un petit accident.

La requête de la liste des commandes du marchand est en fait basée sur l'état de la commande et l'ordre obtenu doit être payé. Cependant, une logique de jugement erronée a été placée à l'arrière du marchand à ce moment-là. Cette logique déterminera si le flux sur l'ordre est 0 (valeur par défaut). Perdre.

Dans cet accident, le composant de mise à jour du cache était agenouillé (et personne ne sait ... bien que cette architecture ait été conçue au début de certains étudiants dans le cadre, il était trop stable et même oublié ...). Parce que la mise à jour du cache n'est pas opportune, les données obsolètes sont obtenues. L'aspect est que les commerçants ne peuvent pas voir de nouvelles commandes. Lorsqu'ils le voient, il a été annulé par la logique de la logique qui n'est pas disponible sans le délai. C'est vraiment une merveilleuse combinaison ...

Le dos est transformé en look ci-dessous:

En revanche, ce lien d'architecture a beaucoup été réduit et la nature réelle est garantie. Cependant, afin de ne pas bloquer le processus, une certaine tolérance aux défauts est effectuée, qui doit ajouter un lien de compensation de surveillance. Après cette amélioration, nous avons immédiatement supprimé la dépendance du code et de la configuration de Zeromq.

Amélioration de l'utilisation des messages

Une fois la sous-bibliothèque terminée, nous n'avons aucune confiance dans MQ. Au cours des prochains mois, MQ a sorti plusieurs anomalies successivement. C'était vraiment la loi de Murphy. Malheureusement, nous avons juste senti que cela allait se produire sans quelque chose. où ça arrive.

Mauvaise pose

Dans le chapitre précédent, j'ai mentionné que j'ai construit un ensemble de mécanismes de diffusion de messages de commande. Sur la base de cet ensemble de messages, le marchand a fait une optimisation technique pour les demandes de rotation à haute fréquence. La pression de l'enquête. Permettez-moi de présenter brièvement cette solution. Le marchand a un service de dos et la diffusion du message de la commande. S'il y a une nouvelle commande (c'est-à-dire la commande qui peut être vue pour terminer le marchand de paiement) sera sur le haut , il déclenchera un rafraîchissement actif à la fin et fera une touche du son pour rappeler au marchand. Les demandes de rotation d'origine ont augmenté l'intervalle de temps et réduisant la fréquence.

Alors, où est le problème? Dans un certain temps, la ligne bleue, le temps de dépense global est inférieur à la ligne rouge, c'est-à-dire que la demande d'une partie de la proportion est d'aller au réseau extérieur. Rapidement.

Le marchand a proposé que la bibliothèque principale, les bêtes, évidemment, ne y pense pas, il est impossible d'être d'accord. Les consommateurs ne sont pas très amicaux par les consommateurs pendant un certain temps. Après tout, ce n'est parfois pas nécessairement une bonne chose, alors pouvons-nous le laisser sortir lentement?

Ainsi, la topologie de Binding a été changée pour nous. La file d'attente rose rose a utilisé les caractéristiques de RabbitMQ dans la file d'attente (c'est-à-dire un message définissant un temps d'expiration, et le temps d'expiration peut être abandonné ou déplacé de la file d'attente vers un autre endroit.), :

Le problème devant moi a été résolu, mais il a également été enterré. Les étudiants qui ont été légèrement expérimentés dans le lapin et la conception d'architecture devraient bientôt se rendre compte des erreurs qui ont été commises ici. Chaque courtier de ces méta-informations tels que la relation de liaison est utilisé pour le routage. Cependant, la persistance de la nouvelle est dans la file d'attente. Et la file d'attente n'aura qu'un seul nud, qui est à l'origine un cluster. À l'heure actuelle, la partie supérieure de la topologie devient un seul point.

De retour à l'accident de cluster MQ que j'ai mentionné au début, pour certaines raisons, certains nuds de notre cluster MQ étaient malheureusement à genoux, y compris cette file d'attente rose rose. En même temps, un autre problème a été exposé, Cette structure topologique ne peut pas être un fonctionnement et une maintenance automatisés. , Reconstruire un nouveau nud, les méta-informations doivent être exportées de l'ancien nud, mais cela entraînera un certain conflit. Et, tôt, nos déclarations de sujet et de file d'attente n'ont aucune expérience, N'alloutez pas la file d'attente en fonction de la consommation réelle de consommateurs, afin que certains nuds soient surchauffés. Sous le fonctionnement automatique et la maintenance et l'équilibre relatif, cette dernière pratique sélectionne en fait un nud pour déclarer la file d'attente.

Après cela, nous avons apporté deux améliorations. L'une devait déclarer la topologie dans le fichier de configuration du service, et automatiquement à MQ pour déclarer dans le MQ lorsque le service a été démarré; demandez le nouveau single par un seul (cache, si Miss Routage vers la bibliothèque principale).

Ainsi, la topologie des nouvelles est devenue ci-dessous:

Splatement du cluster de messages

C'est toujours le contexte de l'histoire ci-dessus, et nous revenons à la cause de l'accident. Selon nos tests de performance du cluster RabbitMQ, ce débit devrait être capable de le résister. Cependant, la charge du processeur est très élevée, ce qui affecte également le message d'envoi du producteur (déclenchant le mécanisme d'auto-protéction de RabbitMQ) et même raccroche.

Avec les efforts de l'architecte, la raison a finalement retracé. et mode récupérer, paramètres préfetch_count, etc.), en fait, ce paramètre nécessite une certaine quantité de calculs pour obtenir une valeur raisonnable. Sinon, même si la machine a toujours un processeur disponible, la puissance de dépense ne peut pas être en hausse.

Quelle est la relation avec l'ordre? La réponse est mitigée. Ce cluster est séparé par différents messages commerciaux via VHOST, il a donc déployé des informations sur les commandes, les commandes de transport et le transfert de marchand.

Le jour de l'accident, le patron du département des opérations et de la technologie a passé une commande, peu importe comment il a fait la machine, Le jour, un cluster de diffusion de messages indépendants doit être mis en place pour les commandes. Le département des technologies de l'opération et les États-Unis sont combinés avec toute la fête des consommateurs. La nuit, un cluster à 7 nuds a été configuré pour démanteler l'ordre de la commande.

(Un an plus tard, ce cluster a également atteint le goulot d'étranglement et n'a pas pu être résolu par l'expansion. La raison principale était que le consommateur n'utilisait pas les caractéristiques de RabbitMQ pour surveiller les nouvelles. L'augmentation de l'échelle a atteint le goulot d'étranglement. Ce dernier a envoyé Un message supplémentaire au cluster nouvellement construit du producteur, qui a été soulagé. La vraie solution a toujours faim? Après avoir remplacé RabbitMQ en utilisant GO auto-développé MaxQ).

PS: Si le temps remonte à l'élément d'amélioration d'origine, un troisième point sera ajouté à l'avance. Pour l'utilisation du «*» pour s'abonner au message, l'abonné doit changer en fonction des besoins réels. Les raisons de la corruption ici ne sont pas suffisamment de contrôle et de gouvernance. Des suggestions standard et de meilleures pratiques sont disponibles dans les documents d'explication initiaux. À l'avenir, le vieil homme n'est pas complètement contrôlé par les opérations techniques, et le fournisseur de services a besoin.

Transaction et innovation virtuelles

petit-déjeuner:

De la fin de 2015 à début 2016, le petit-déjeuner qui avait faim, bien que la proportion de volume unique n'ait pas été élevée, elle était relativement importante pour l'architecture technique à l'époque.

L'interaction entre les plats à emporter et le petit déjeuner est:

Je suppose qu'à ce moment, il y aura un tas de points d'interrogation ...

J'explique l'arrière-plan:

1. Le petit déjeuner est indépendant de la restauration et construit complètement un nouveau système (utilisateur, magasins, commandes, distribution, etc.).

2. Étant donné que le paiement ne peut pas être effectué de manière indépendante, le paiement est couplé dans le système utilisateur avant 2016, et cet ensemble de paiement est purement personnalisé pour les plats à emporter.

En conséquence, en tant que «activité d'innovation» du département «d'innovation», afin d'essai et d'erreur rapidement, il a complètement construit un ensemble complet de prototypes de commerce électronique. lien de transaction. Cette solution a été déterminée et mise en uvre par les étudiants en recherche et développement du petit-déjeuner et des étudiants en recherche et développement qui ont payé. L'ordre est devenu un outil sans perception.

Quand je le savais, j'avais grandi comme ça. Quand ai-je su, quand je suis sorti du pot, c'était très réel. À ce moment-là, l'EPI et le PRD n'ont pas été complètement isolés. Une mauvaise opération a provoqué la mise en uvre de la tâche asynchrone de ProD à l'EPI puis transférée. À la fin, l'ordre a été annulé sans consommation de travailleurs.

Carte de membre de la livraison affamée

Début 2016, le parti en affaires a mentionné une demande, en espérant que les ventes de la carte d'adhésion à la livraison peuvent être en ligne, et cela a été fait auparavant de s'appuyer sur les ventes hors ligne d'une carte physique. Juste, après la précédente revue d'architecture, nous avons également besoin d'un modèle de petite entreprise pour pratiquer nos nouvelles idées d'architecture, il existe donc un système de commande à vendre de notre produit virtuel.

Nous abstracons un ensemble du modèle d'état le plus simple:

Le point central:

1. Toutes les transactions dans le monde sont inséparables de ses ancêtres. Les nuds principaux sont relativement stables.

2. Le comportement d'achat de C-Fend est relativement simple, tandis que la livraison de la fin B peut être en train de se chuter.

3. Plus les systèmes de base, plus il faut être simples.

L'interaction en amont et en aval est comme ci-dessus. La gestion, le marketing, le guide d'achat, etc. sont tous remis à l'équipe commerciale elles-mêmes, le système commercial La responsabilité principale est de fournir des données pour les canaux et les transactions.

Dans la conception des données, les acheteurs et les vendeurs, le sujet et la scène, ces trois sont considérés comme nécessaires à l'époque. Bien sûr, je peux maintenant donner un modèle plus standard, mais à l'époque, nous n'avons vraiment pas fait Je pense tellement.

Par conséquent, la montre principale de la transaction est démontée.

Un tableau de base, y compris l'ID principal de l'acheteur, l'ID de l'acheteur, le code d'état, le type d'entreprise, le montant du paiement. Le type d'entreprise est utilisé pour distinguer les différents systèmes d'acheteurs.

Un autre devient une extension, y compris la liste des sujets, la liste des informations marketing, la réception du numéro de téléphone mobile, etc., qui appartient aux détails, permettant à la partie commerciale d'avoir un certain espace libre.

(PS: À l'avenir, le sujet, les informations marketing, etc. Bien que le amont puisse être contrôlé par lui-même, il est nécessaire de restreindre le paradigme du niveau de code, sinon la gouvernance sera plus gênante et le parti en affaires ose vraiment tout farcir))

Démontant deux tables, la raison derrière elle est qu'une fois la commande générée, les responsabilités de l'instantané sont presque terminées. La chose la plus importante est la maintenance de l'État, et le fonctionnement à haute fréquence est également concentré dans l'État. Il aide à Assurez-vous le processus de base; la seconde consiste à se référer à l'expérience des ordres de restauration. L'espace de stockage 2/3 est utilisé sur les détails, en particulier plusieurs champs JSON.

Une fois l'ensemble du système de commandes virtuels configuré, de nombreuses plateformes vendant des activités via ce système sont accessibles via ce système. Pour nous, le développement des coûts d'accès + ne prend que dans les 2 à 3 jours, et l'ensemble de l'entreprise est généralement en ligne dans un semaine en une semaine. D'accord, nous sommes très heureux et l'équipe commerciale de la réception est également très heureuse. Parce qu'il n'y a pas de grandes scènes de requête à l'échelle, pendant longtemps, il a stabilisé des centaines de milliers de commandes quotidiennes par jour, et les ressources de dizaines de curs sont plus que suffisantes.

Il s'agit en fait du prototype d'un système de plate-forme simple.

autre

Autour de la transaction, nous avons en fait dérivé certaines entreprises. Dans un sens large, l'équipe de commande était responsable à l'époque, et elle a également été causée par l'impact de la structure organisationnelle.

Par exemple, la propriété intellectuelle de la «poursuite», le côté technique est la réalisation de notre propriétaire d'équipe à partir de zéro, et en même temps, un «centre de rémunération des transactions» est dérivé pour percevoir toute la rémunération en train de recevoir une transaction (y compris les enveloppes rouges, les bons de bons, les bons, les bons, les espèces, les points, etc.),;

Afin d'améliorer l'expérience de transaction de l'utilisateur, nous avons lancé un "Centre de touche de transaction" (a évolué plus tard en Universal Touch Center d'une entreprise). Pendant la transaction, les messages texte de l'utilisateur, la poussée, le téléphone, etc. Le taux de cas extrême réduit le harcèlement répété aux utilisateurs.

Service et gouvernance des entreprises

La plupart d'entre eux mentionnés ci-dessus sont quelques-uns des détails techniques. Les deux choses ci-dessous sont une évolution majeure de l'architecture d'application, qui jette également la direction de l'architecture d'application par la suite.

Ventes inverses et après-vente

À la mi-2016, les antécédents commerciaux, afin d'améliorer l'expérience de l'utilisateur dans l'insatisfaction (des dizaines de cas sur notre tableau blanc), afin de raccourcir la période du compte de règlement (parce que le temps inverse est efficace pendant sept jours, le règlement est fort Cela dépend de cette époque).

Dans le cadre de l'initiative de JN, nous avons démantelé l'inverse inversé de l'ordre d'origine et divisé le groupe d'ordre d'origine en deux équipes. Je recommande l'un des étudiants pour devenir le chef d'équipe de la nouvelle équipe.

Pour positif, la responsabilité principale est d'assurer la douceur de la transaction, donc elle se concentre sur les cheveux élevés et les cheveux élevés et la stabilité.

La concurrence inverse est inférieure à celle de l'avant, et seulement 1% des ordres doivent aller dans la direction inverse. Cependant, la complexité de la branche et la relation hiérarchique de la logique commerciale est bien supérieure à celle de l'avant, et une abstraction commerciale est requise. Bien que la stabilité et les performances soient tout aussi importantes à inverser, elles ne sont pas si élevées.

Parce que les problèmes de base sont différents et que les exigences de service sont différentes, la division est logique.

Le processus partagé réel est encore très douloureux. Tout le monde explore. Moi et mon patron, y compris le patron, avons fait une tournée d'innombrables fois.

Le formulaire final à l'époque était le suivant (il y a encore des problèmes, après avoir été responsable de l'inverse au cours des prochaines années, a fusionné les ventes et après les ventes):

La première étape consiste à ajouter un statut de commande Il est utilisé pour représenter l'achèvement de la commande (sur la réception des marchandises, car il est généralement achevé immédiatement après la réception, mais il y a encore quelques différences entre les deux). Augmentation de la lumière, poussant en amont et en aval, y compris la mise à niveau de l'application, il a fallu près de 3 mois.

La deuxième étape, configurez un ensemble de retraites Une fois l'échelle de gris de l'achèvement de la commande terminée, cet état est utilisé comme fin du cycle de vie de la commande. De cette façon, le règlement et la déduction du règlement et du règlement sont indépendants les uns des autres.

Dans la troisième étape, la logique impliquée dans la commande est également réduite dans le service. Essence (À propos de l'évolution des ventes de milieu et après les ventes, il y aura une chance de se développer plus tard)

L'un des stands dans lesquels nous sommes intervenus à cette époque n'a pas décolleté le statut et les événements supérieurs relativement proprement, et finalement reflété dans la frontière commerciale et les affaires distribuées. Il y avait beaucoup de problèmes.

Après quelques querelles, la logique principale du système de commande a en fait été supprimée relativement simple. Le travail principal est de définir la relation entre l'état Par exemple, a- > C, b- > CALIFORNIE- > B, si A, B, C et peuvent être inversés ici sont définis par les commandes. La signification commerciale de cette couche est très légère, et l'accent est mis sur * - > C Nous pensons que c'est une scène, et le niveau supérieur est responsable.

Par exemple, le statut de C est une commande invalide. À l'exception des commandes qui ont été ouvertes, tout statut peut être changé en invalide. Quel type de condition est déterminé par le formulaire d'entreprise. Elle convient au service dans le service de vente. Voulez-vous déclencher des commandes pour inverser. Il y a aussi des ordres à recevoir.

En ce moment, il y a déjà le dieu de la machine d'État.

En particulier, il est expliqué que la ligne rouge est en effet une conception pliante dans le scénario de trading avec une forte actualité. La tâche principale de cette ligne est purement un marquage. Jouez une étiquette sur l'ordre pour indiquer si Indiquez s'il y a des ventes après. Nous nous référons à l'E-Commerce (Taobao, JD.com) à l'époque, et le démontage vertical a été achevé à partir de la page. Pour la conception du système, c'était beaucoup plus simple, et nous ne pouvions pas le faire. Ceci est déterminé par le forme d'entreprise. Ceci est déterminé par le formulaire d'entreprise. Ceci est déterminé par le formulaire d'entreprise. Les commerçants doivent terminer la commande en très peu de temps, et en même temps, ils doivent toujours prêter attention à l'affaire anormale. De nombreuses pages sont sous peser, et ils doivent s'occuper de l'expérience utilisateur. En d'autres termes, bien que le système soit démonté, l'entreprise de niveau supérieur ne peut toujours pas être démantelé, et même il y a beaucoup de voix à l'intérieur. Nous voulons simplement rembourser. Pourquoi est-ce que je dis-je, distingue et relier les deux systèmes. Par conséquent, une partie des données est écrite sur la commande.

À ce stade, les deux mots les plus utiles:

1. Que ce soit non? : Peu importe à quel point tout le monde veut faire les choses mieux. Ne vous lève pas aux gens en fin de compte; (Il n'y a rien cet après-midi, le thé ne peut être résolu).

2. persistent à faire quelque chose de plus bénéfique : Personne n'est un sage. Quelle que soit la décision initiale, il n'y a pas de persuasion absolue pour se persuader. . (En revanche, la perte d'arrêt en temps opportun, les deux ne sont pas en conflit, mais doivent également être décidées).

Acosité logistique

Début août, j'ai prévu de me transférer la logique commerciale MQ, car les concepts de conception sont différents et la pile de langues est différente. La première chose est de commencer la reconstruction.

Parlons ici de deux conceptions d'architecture "obsolètes".

TOC et TOB et TOD:

Début 2016, il y avait un ancien mandat, et maintenant la plupart des gens ne savent pas les choses: le corps.

C'est la forme d'auto-distribution lorsque vous vous levez tôt. Cet ensemble d'entreprise reflète le couplage complet des commandes, des magasins, de la distribution, du règlement, etc. dans l'entreprise. Hungry? Mon grand système de logistique a été construit à partir de la mi-2015. À l'heure actuelle, il est nécessaire de faire un grand projet et un DBO découplé.

Ce découplage est né dans les forfaits de service, les ordres TOB et les ordres TOD.

Expliquez un peu les antécédents commerciaux. À cette époque, la plate-forme a vendu des services aux marchands et a signé un contrat avec le marchand. Les services vendus ici incluent les services de distribution. Ensuite, l'utilisation de la livraison ou non, elle affecte la commission et la création du marchand. Cependant, l'innovation caractéristique de cette industrie est de dire au marchand lorsque le marchand reçoit l'ordre. Que le marchand voir un projet de loi avec une probabilité élevée ( Quelle que soit l'exception de la vente) à l'avance, et vous devez également dire au marchand que le projet de loi est soumis au projet de loi.

Il s'agit en fait d'une logique de division et de division. Les activités de nettoyage du domaine de règlement sont présentées au lien commercial. Effacer le règlement est une entreprise non réel toute l'année. Naturellement, il est tombé dans l'équipe de commande. Une autre expérience, il y avait de nombreux étudiants CTRIP qui sont venus ici à l'époque. et Tod a été introduit.

La tâche que je reçois est de passer une commande TOB. À ce moment-là, je sentais que cette forme était erronée. Le trading des affamés et les transactions de CTRIP était différent. J'ai exprimé son opposition au superviseur, mais après tout, je n'ai pas eu beaucoup de précipitations pendant un demi-an. Je n'ai pas beaucoup de raisons claires et puissantes. Il y a aussi d'autres personnes en difficulté. En bref, L'écale de gris a été officiellement lancée début mars.

Cette image peut voir quelques questions évidentes:

1. La transaction a été démolie en plusieurs sections, et les utilisateurs et les commerçants doivent réellement percevoir chaque paragraphe. Et chaque étape a certaines exigences pour la rapidité et la cohérence.

2. La plate-forme et la logistique n'interagissent qu'à travers le rouge en premier. Ce canal est très lourd

3. Formule Synchronisation hors ligne ...

Tod

Après la mise en uvre de l'architecture ci-dessus, en juillet, la partie TOD est devenue le seul canal pour les plateformes et la logistique. Il était trop lourd. L'entreprise n'a pas encore développé à ce stade, et les inconvénients sont supérieurs au profit. Les camarades de classe du marchand avec le groupe de livraison sont malheureux, les étudiants en logistique sont malheureux et les camarades de classe de la commande ne sont pas satisfaits.

Il arrive que l'ordre augmente. Nous pensons que le cycle de vie qui doit être contrôlé et contrôlé doit être étendu à la livraison, et que la livraison appartient au cycle de vie de l'enfant, qui fait partie de la transaction. Ainsi, fin juillet, Tod m'a également donné et a atteint le lien de restructuration.

À en juger par le personnel externe du système de technologie des affaires, la conception de Tod était très anti-humaine à l'époque.

Lorsque nous avons vraiment pris le relais, nous avons constaté que la structure d'application de l'entreprise à ce moment-là était probablement comme ceci:

Avec un tel étage public d'infrastructures, cette couche résume les opérations publiques telles que DB et Redis. C'est-à-dire, La logique commerciale et les données du même champ sont divisées en services à différents niveaux de services en fonction du principe de superposition de ce système. La couche commerciale dans un domaine doit faire fonctionner ses propres données, et elle doit également être effectuée via l'interface . Essence Cela peut avoir un certain sens (y compris en 2020 lorsque j'ai découvert des candidats dans l'interview, et certaines entreprises sont également cette approche), mais quand elle est remise, c'est douloureux! Le couplage complexe équivaut à peler une ligne relativement propre et indépendante à partir d'un système complexe.

Plus tard, nous avons changé pour le look suivant:

1. TOB et TOD sont fusionnés dans la première couche, placés dans le service OSC.Blink et éliminent ces deux concepts comme des données étendues pour les commandes, et non une section coupée de la transaction.

2. Si la plate-forme et la logistique ont une interaction de données, il n'a pas nécessairement besoin de passer cette couche d'amarrage. Il est préférable de transporter les données nécessaires à la livraison réelle du temps réel. La logistique Apollo peut prendre les données ailleurs ailleurs sur la plate-forme. (En fait, certains problèmes n'ont pas été résolus. Le positionnement d'Os.Blink et Apollo dans les deux parties n'est pas complètement cohérent. Apollo rassemble toutes les données connectées à la plate-forme comme centre de la liste de transport).

3. L'interaction entre les nuds et les nuds est aussi simple que possible, et le nud lui-même garantit sa propre robustesse. L'ordre de poussée d'origine a été effectué via le message. Maintenant, il est changé en RPC. Le Push Party peut prendre l'initiative de re -push (il existe une puissance de garantie de bon, etc.).

(La figure 3.1 était due à la plate-forme à emporter et à la plate-forme logistique à l'époque. La salle informatique a été déployée dans différentes villes. Le nombre de demandes de salle de la machine croisée a eu un impact énorme, donc ce service a été encapsulé par ce service sur le lien) .

Fin août, la pièce d'appel a été achevée. Les données ont commencé à reconstruire les données en septembre.

sommaire

À la fin de 2016, notre système de trading se développe dans son ensemble:

À cette époque, certaines bonnes habitudes et consciences étaient très importantes:

1. Clarifier la puissance et les responsabilités : Code d'entrepôt de code Recyclage, recyclage des autorisations de publication, base de données et file d'attente de messages Connexion de gestion et de contrôle des chaînes, etc.

2. Gardez la propreté La

a. Nettoyez la logique inutile dans le temps (par exemple, j'organiserai un lot d'interfaces sans trafic tous les un ou deux mois, et il vérifiera également l'interface avec une croissance anormale du trafic. Comment le montant en aval peut-il parfois être pratique).

b. Nettoyez la configuration inutile dans le temps et n'a pas besoin de tuer immédiatement, sinon personne n'ose se déplacer après le transfert.

C

3. La poursuite idéale de l'ultime mais en bas à terre.

4. Adhérer aux normes et mécanismes de test.

a. adhérer à la construction d'automatisation

b. Adhere to Performance Test

c. persister dans le foret de faille

5. Demandez, demandez et entrez constamment et entrent en collision.

6. Restez simple, restez facile.

7. Peu importe ce qui est bien.

L'évolution de l'architecture est préférable d'être motivée par des affaires, de l'amélioration de l'avant, pas un moteur d'accident. Avec le recul, nous avons constaté que la moitié de notre évolution était réellement accompagnée de l'accident. Heureusement, à cette époque, la technologie peut être librement contrôlée à ce moment-là.

Si vous lisez ici, il y a beaucoup de résonance et de sentiments, mais vous ne le dites pas, alors vous organisez votre expérience dans certains cerveaux.

Dans le stage de demi-ans, chaque mois, je me sens changer chaque jour qui passe. Au cours des premiers ans et demi de remise des diplômes, j'ai toujours senti que moi-même était faible il y a trois mois. L'un du temps.

C'est tout pour la partie précédente. S'il y a quelque chose, attendez la partie suivante.

Informations sur l'auteur:

Le fan de Yang, le nom du nom de la fleur, est Hungry, un architecte de haut niveau, est-il rejoint en 2014? En 2018, il avait faim avec Alibaba et a rejoint Alibaba ensemble. 4 ans d'expérience en gestion d'équipe. La construction du système a également été responsable du compte affamé, de l'évaluation, de la messagerie instantanée, de la livraison des performances et d'autres systèmes.

News Fei Smart Voice Pioneer: Lorsque l'interaction humaine-machine est aussi naturelle que la communication humaine, la véritable ère intelligente vient!

B Les développeurs de github chinois ont augmenté de 37% d'années sur un an, le plus rapide du monde

P de Nginx à Pandownload, comment les programmeurs évitent-ils la programmation en prison?

Ne peut trouver que l'algorithme dans les opérations de mathématiques du secondaire? Quelle est la puissance de l'open source de Google Automl-Zero

L'architecture micro-service de Lspring Cloud sous l'architecture cloud: Microservice Department (Dept)

C du Cloud de Spring au maillot de service, comment évolue le système de gouvernance d'architecture micro-service?