A propos de l'auteur
py.an, responsable R&D back-end Ctrip, axé sur l'optimisation des performances, l'architecture technique et d'autres domaines
Venson, responsable R&D senior back-end de Ctrip, se concentre sur l'optimisation des performances, l'architecture technique et d'autres domaines
Introduction
Dans le contexte de la stratégie de mondialisation, Trip.com, en tant que plateforme OTA mondiale face au marché international, travaille dur pour promouvoir le déploiement stratégique international. Les billets de train Trip.com investissent activement des ressources et des compétences techniques pour développer leurs activités à l'étranger. En déployant des applications et des données dans des centres tels que Singapour et Francfort, l'entreprise offrira une meilleure expérience d'achat de billets aux utilisateurs du monde entier et réduira les risques liés à la conformité des données. .
2. Expérience en affaires
Comme le montre la figure, l'activité ferroviaire mondiale de Trip.com est actuellement principalement concentrée au Royaume-Uni, en Asie et dans les pays européens. L'Europe, en tant que continent avec des économies et des transports très développés dans le monde, est également devenue une gare plus préoccupante. Il y en aura d'autres dans le futur. Une scène plus grande.
À mesure que la crise épidémique mondiale s'atténue et que la demande de tourisme et de voyages se libère, l'activité mondiale de billets de train de Trip.com a progressivement pris forme avec le soutien de scénarios multilingues et multidevises.
3. Défis rencontrés
Dans le contexte de la mondialisation, en plus d'envisager un déploiement mondial fluide pour répondre aux exigences de disponibilité des applications et de performances d'accès des utilisateurs, vous devez également prendre en compte des exigences strictes telles que la sécurité, la conformité légale et l'isolation des données pour les données exportées à l'étranger. Exemples des perspectives suivantes :
3.1 Déploiement mondial
Avant la transformation, les applications et données commerciales des billets de train Trip étaient déployées dans la même ville que la salle informatique d'origine : il y avait deux centres IDC A+B (la même salle informatique logique) avec double activité dans la même ville.
Par rapport aux caractéristiques architecturales avant la transformation, comme indiqué dans le tableau :
| Niveau de reprise après sinistre | même partition logique | partition utilisateur | Visite à proximité | Les données abondent | accès publique | |
| Avant transformation (double actif dans la même ville) | Niveau transversal de la salle des machines |
Oui |
Non |
Non |
Non |
Le support est complet et mature |
| Multicentrique mondial | niveau régional |
Non | Oui, partition unitisée | Oui |
Le strict respect des politiques transfrontalières en matière de données est requis | Besoin de prendre en charge plusieurs scénarios IDC |
Il ressort de cela que dans un scénario multi-IDC, il est inévitable de faire face à des problèmes tels que la fragmentation des données, l'unification, les conflits de données et l'idempotence des entreprises. Par rapport à l'architecture distribuée traditionnelle, non seulement les projets d'applications métier, mais aussi l'infrastructure de plate-forme PaaS ont rencontré de nouveaux défis pour faire face au système technologique mondial et nécessitent d'énormes ajustements.
3.2 Problèmes de performances
Face à la réponse aux demandes commerciales des utilisateurs du monde entier, il est inévitable que certains utilisateurs connaissent une mauvaise qualité d'accès au service en raison de problèmes tels que la transmission transocéanique du réseau et les longues distances de transmission des liaisons. Comment garantir un lien d'accès optimal pour les demandes des utilisateurs, réduire la latence du réseau et fournir une réponse de service plus rapide.
3.3 Conformité et gouvernance des données
Comment respecter strictement les lois et réglementations pertinentes promulguées par différentes régions concernant les flux de données transfrontaliers, les fuites de données et autres problèmes de sécurité des données.
3.4 Problèmes liés à l'exportation de données à l'étranger
Cohérence des données : dans un scénario de lecture et d'écriture multi-IDC, lorsque les utilisateurs créent et gèrent des commandes dans plusieurs centres de données à travers le monde, comment garantir la cohérence des données lorsque plusieurs centres de données se synchronisent les uns avec les autres et gèrent les activités de commandes.
Conformité synchrone : en raison de l'influence des politiques de données transfrontalières, les activités multiples dans différents endroits ne sont généralement pas autorisées. Il est nécessaire d'éviter les violations causées par les flux de données transfrontaliers.
3.5 Évolutivité mondiale
Dans le but d'étendre facilement la couverture commerciale, lorsque de nouvelles activités sont développées, comment ajuster facilement et dynamiquement les stratégies de stockage de données en transformant l'activité et les données pour faire face aux politiques de conformité des données dynamiques et changeantes.
Ce qui suit combinera les défis et les problèmes rencontrés par la mondialisation et expliquera en détail la pratique d'évolution architecturale de la mondialisation des billets de train Trip du point de vue du déploiement à l'étranger, de la conformité des données et des pratiques de transformation de l'architecture .
4. Pratique de l'évolution de l'architecture à l'étranger
4.1 Sélection de la région (zone disponible)
Le choix d'une région appropriée nécessite de prendre en compte plusieurs facteurs tels que les besoins des utilisateurs, les lois et la confidentialité, l'infrastructure et les réseaux, l'évaluation des risques transfrontaliers liés aux données, ainsi que les coûts et avantages.
Trip Train Ticket prend en compte de manière exhaustive les facteurs ci-dessus et l'orientation de développement de ses propres besoins commerciaux, mène des études et des analyses de marché détaillées et sélectionne les zones de disponibilité : Singapour (SIN) et Francfort (FRA) sont utilisés comme centres de données pour le déploiement à l'étranger. des services ferroviaires.
4.2 Couche d'accès au réseau
Comment configurer le routage réseau pour Trip Train Ticket afin d'obtenir un accès au routage et une transmission de données fiables et efficaces, il existe trois scénarios au total.
Réseau externe : multi-chemins, accès à proximité.
Tenant compte des retards du réseau et des limitations de bande passante entre les différentes régions, les billets de train Trip adoptent une stratégie de routage d'accès à proximité. Autrement dit, le chemin ayant la distance la plus proche ou la bande passante la plus grande est sélectionné pour la transmission des données afin de réduire les retards et d'augmenter la vitesse. Avantages : garantissez que le même utilisateur peut accéder à l'IDC avec la meilleure liaison réseau à proximité.
Configurez plusieurs chemins FRA et SIN pour la transmission de données et le routage multi-chemins. De cette manière, même si un chemin échoue, les données peuvent toujours être transmises via d’autres chemins.
Intranet : essayez d'accéder aux ressources de la même région pour réaliser des activités en boucle fermée dans la même région.
Scénario d'accès inter-régions : s'il n'y a aucune ressource commerciale à obtenir dans la même région et doit être accessible dans plusieurs régions, une optimisation des liens est effectuée. Par exemple, les utilisateurs européens accèdent à FRA et demandent des ressources SIN via des liens dédiés. Cela évite un accès transocéanique direct à d’autres régions, ce qui peut prendre trop de temps en raison de problèmes tels que la transmission du réseau transocéanique et la qualité instable des liaisons.
4.3 Couche de données
1) Transformation de la conformité des données à l’étranger
La transformation de la conformité des données à l'étranger est une tâche complexe et importante qui nécessite une prise en compte approfondie de diverses lois, réglementations et besoins commerciaux. Grâce aux mesures de transformation suivantes, nous pouvons garantir la conformité de la transmission et du traitement transfrontaliers des données et offrir aux utilisateurs une protection des données plus fiable :
Classification et étiquetage des données : classifiez et étiquetez les données commerciales pour identifier clairement les données protégées telles que les données sensibles et les informations personnellement identifiables. Cela permet de mieux comprendre où se trouvent les données sensibles et comment elles sont traitées pendant le transfert et le traitement des données.
Cryptage et anonymisation des données : utilisez une technologie de cryptage et des méthodes d'anonymisation des données appropriées pour protéger les données sensibles. Le cryptage peut empêcher efficacement l'obtention de données par des visiteurs non autorisés pendant la transmission et le stockage, tandis que l'anonymisation des données peut protéger la confidentialité des informations personnelles identifiables.
Désinvestissement et transformation des activités de données à l'étranger : flux de données transfrontaliers. De nombreux pays mettent en œuvre des stratégies de localisation des données. Lorsque les données sont exportées à l'étranger, les règles de données transfrontalières des lieux de sortie et d'entrée des données doivent être prises en compte en même temps. La transmission transfrontalière de données nécessite une identification des risques et des mesures de contrôle des données associées, et les données commerciales doivent être supprimées et transformées.
2) Déploiement de plusieurs IDC de base de données
Afin de garantir que les besoins de l'entreprise peuvent être satisfaits et d'améliorer la disponibilité et la tolérance aux pannes de la base de données, un plan de déploiement multi-IDC sera mis en œuvre pour la base de données à l'étranger. Comme indiqué ci-dessous:
Il convient de noter que lors de la synchronisation entre les IDC, les lois et réglementations de chaque pays et région doivent être prises en compte pour garantir que le lien pour les données synchronisées est conforme aux réglementations locales en matière de stockage de données et de protection de la vie privée.
De plus, l'architecture devient très complexe lorsque plusieurs données de base de données sont synchronisées les unes avec les autres. Afin de garantir une faible latence du réseau et une synchronisation stable des données entre les différents IDC, il convient de prêter attention au retard de chaque lien de synchronisation, à la gigue du lien réseau et aux problèmes de cohérence des données, et une surveillance, des tests et des exercices réguliers doivent être effectués pour vérifier l'ensemble du déploiement. plan, fiabilité et validité.
3) Surveillance du retard synchrone
Comme le montre la figure ci-dessus, par exemple, le délai de synchronisation du lien de synchronisation DRC :
PÉCHÉ<—>OFF : 160 ms+
4) Évolutivité de la base de données multi-IDC
Présentation de RegionCode : ajoutez l'identification de la salle informatique d'enregistrement RegionCode lors de l'insertion des données utilisateur.
Déterminez la région où se trouvent les données en fonction de RegionCode, afin que les requêtes de données ou les opérations de traitement métier couramment utilisées puissent être exécutées sur un seul nœud pour obtenir un traitement de données unifié et un ajustement dynamique des politiques de conformité des données, évitant ainsi une consommation de performances et de données supplémentaire. nœuds.Problèmes de conformité transfrontalière.
4.4 Couche de composants de base
1) Accès multi-IDC aux composants de base du PaaS
a. Centre de configuration distribué :
Dans le scénario d'application de plusieurs déploiements IDC, les fichiers de configuration dans différents environnements IDC semblent être différents. À ce stade, les fichiers de configuration du centre de configuration doivent également être ajustés : accéder au sous-environnement, introduire plusieurs fichiers de configuration IDC, et prend en charge différents IDC.Configurez la scène.
B. Centre de répartition distribué :
Étant donné que la plupart des JOB de l'entreprise traitent les données par lots en analysant les tables, dans les scénarios multi-IDC, les tâches sont distribuées à plusieurs IDC en fonction du RegionCode stocké, et les données sont traitées en fragments après un filtrage unifié.
c. Rédis :
Pas de synchronisation bidirectionnelle, plusieurs sources de données.
Il existe de nombreux scénarios dans lesquels Redis est utilisé en entreprise, mais Redis est différent des scénarios de bases de données d'entreprise, il n'effectue donc pas de synchronisation bidirectionnelle. Chaque IDC correspond à un cluster Redis dans la même unité. Chaque cluster Redis ne sert l'entreprise que dans l'unité actuelle, elle n'est donc pas pleine. Par conséquent, dans un scénario multi-IDC, de nombreux scénarios commerciaux doivent être ajustés.L'activité de couverture basée sur Redis doit assurer une boucle fermée au sein de l'unité.
2) Transformation multi-IDC du centre de messagerie
Chaque cluster MQ est indépendant et isolé les uns des autres. Dans un scénario multi-IDC, il sera inévitablement confronté au problème du traitement des messages idempotents, c'est pourquoi MQ a été transformé en groupements logiques :
Traitement au sein de la même région : traitement en boucle fermée de la production et de la consommation de MQ dans la même salle informatique au sein de la même région
Scénario inter-régions : MQ inter-régions doit être synchronisé avec la région de la salle informatique centrale via BaseSubject pour garantir des processus métier normaux.
Traitement idempotent côté consommateur : le côté consommateur est logiquement regroupé selon RegionCode pour une consommation unifiée.
L'organigramme de transformation du traitement des messages est présenté dans la figure ci-dessous :
4.5 Couche métier du projet
1) Transformation en boucle fermée des unités commerciales
Selon le principe de partitionnement des utilisateurs en différentes zones et de fonctionnement indépendant dans chaque unité. Transformez l'activité du projet pour garantir que toutes les activités peuvent être réalisées de manière indépendante au sein de l'unité autant que possible, et que chaque IDC peut prendre en charge indépendamment les capacités de traitement commercial de certains utilisateurs.
2) Demander une modification du lien
Essayez d'assurer autant que possible l'exécution dans la même région afin de réduire les problèmes tels qu'un temps de réseau excessif causé par les requêtes transocéaniques.
3) Transformation de la scène inter-régionale
Pour les demandes chronophages entre régions, la logique de traitement métier d'origine des appels série vers des interfaces externes est ajustée au traitement simultané asynchrone et à l'optimisation du préchargement des données. Par exemple, dans le scénario d'obtention de coupons utilisateur, qui doivent être obtenus dans toutes les régions, les coupons sont demandés à l'avance pour supprimer l'impact entre les régions.
Dans les scénarios qui traversent des régions plusieurs fois, le nombre de traversées des régions est réduit grâce à la modification de l'interface, réduisant ainsi le nombre de traversées océaniques.
Lorsqu'il y a des activités interrégionales non essentielles dans l'activité principale : les principes de traitement non immédiats sont adoptés et le traitement de transformation MQ asynchrone est effectué sur l'activité non principale via le fractionnement des activités.
4.6 Problèmes de transformation et points de réflexion dans l'évolution
Dans le processus actuel de transformation d'un projet, les difficultés font également partie du processus de transformation. La clé est d'avoir une attitude positive pour traiter et résoudre les problèmes, surmonter les difficultés et promouvoir le bon déroulement de la transformation du projet en analysant les problèmes, en formulant des solutions, en les exécutant et en apprenant de l'expérience.
Voici les problèmes rencontrés lors du processus de transformation et leurs solutions
1) Problème de conflit de synchronisation de base de données
Une fois la synchronisation des données activée dans l'environnement de production, une instabilité du réseau s'est soudainement produite, provoquant le blocage du lien de synchronisation DRC.
Comme le montre la figure, lorsque le lien de synchronisation DRC est surveillé comme étant instable, l'alarme de conflit de synchronisation DRC est déclenchée.
Raison : Grâce au dépannage des données de la base de données, il a été constaté que les opérations de mise à jour de SIN et FRA sur le même ordre étaient dues à des retards de réseau qui provoquaient un conflit DRC lors de la synchronisation, provoquant l'abandon de l'une des opérations de mise à jour, affectant ainsi les opérations suivantes. processus de commande.
Solution : modifiez la logique de mise à jour de la commande et exécutez-la dans le même IDC. Les retards de synchronisation en cas de double écriture entraîneront inévitablement des conflits de cohérence. La solution à long terme consiste à unifier les données pour éviter d'exploiter les mêmes données dans toutes les régions.
2) Problème de verrouillage distribué
Les verrous distribués du projet actuel sont implémentés sur la base de Redis. Étant donné que les clusters Redis des différents IDC sont isolés les uns des autres, la granularité des verrous distribués ne prend actuellement en charge qu'au niveau régional. L'activité actuelle concerne uniquement les verrous distribués basés sur des scénarios d'utilisation, de sorte qu'elle peut également répondre aux scénarios commerciaux réels actuels. S'il y a une activité ultérieure d'acquisition mondiale de verrous distribués, une conception plus approfondie est nécessaire pour garantir que toutes les régions disposent d'un seul endroit pour obtenir la ressource en même temps, et que les autres régions doivent attendre, ce qui peut sacrifier des performances considérables pour réaliser cette fonction. .
3) Problème d’inventaire de salles multi-machines
La demande de l'utilisateur garantit que la boucle fermée est réalisée dans la même salle informatique, mais certains scénarios ne se prêtent pas à une division en unités, comme le problème de la déduction des stocks dans plusieurs salles informatiques. La stratégie actuelle pour faire face au problème de déduction des stocks de plusieurs salles informatiques est la suivante :
La logique de déduction des stocks de l'entreprise n'est pas ajustée, les stocks sont toujours déduits de manière synchrone, mais les stocks de chaque salle informatique sont répartis à l'avance en fonction du trafic.
Ajoutez un mécanisme d'allocation d'inventaire pour déclencher l'allocation d'inventaire lorsque l'inventaire est insuffisant et allouez à partir de la salle informatique avec un inventaire excédentaire.
Ajoutez des notifications d'alarme de surveillance et de rupture de stock. En plus de l'allocation automatique des ressources, de l'observation en temps réel et de l'allocation manuelle en temps réel de l'inventaire dans la salle informatique après le lancement de l'événement.
4.7 Résultats de l'évolution
Grâce à la transformation et à l'optimisation ci-dessus, l'évolution de l'architecture du système et l'optimisation des performances des billets de train Trip.com sont les suivantes :
1) Schéma d'évolution de l'architecture
2) Optimisation des performances
Réduisez l’accès des utilisateurs à travers les océans en optimisant les liens réseau des utilisateurs. L'optimisation fastidieuse de l'interface FRA réduit la consommation de temps globale de 300 à 800 ms.
5. Nouveau point de départ, nouveau voyage
Dans le contexte actuel, il existe encore de nombreuses imperfections et de nombreux défis techniques. Le système d'architecture doit encore continuer à évoluer et à itérer. Ensuite, les billets de train Trip.com doivent être encore optimisés et transformés pour la future orientation stratégique mondiale :
5.1 Routage unifié
Stratégie de routage UCS (service de contrôle d'unité) du groupe d'accès : mappez l'IDC spécifié en fonction des informations régionales de l'utilisateur en tant que ShardingKey pour obtenir une mise en œuvre parfaite dans le scénario de plusieurs IDC pour le trafic et les composants.
5.2 Transformation des unités de données
Le premier indicateur actuel est de donner la priorité à la garantie des affaires. Les données de base de données de chaque région seront synchronisées dans les deux sens. Les données de chaque région sont pleines, ce qui augmente également la tolérance aux pannes et réduit le risque d'interruption d'activité causée par une exportation anormale de données. Cependant, il faut encore atteindre le point où les données et les unités commerciales peuvent être complètement fermées et où le lien de synchronisation peut être coupé à tout moment pour éviter les irrégularités causées par les données transfrontalières, afin de parvenir à l'unification des données.
5.3 Aménagement de la salle informatique du centre d'affaires
Afin de s'adapter à l'évolution des politiques de conformité des données et de répondre aux tendances de développement commercial, la future salle informatique centrale est aménagée en centre de données SIN et a la capacité de supprimer la salle informatique d'origine du centre d'affaires.
À l'heure actuelle, il est nécessaire de définir le centre d'affaires sur SIN après avoir permis à toutes les entreprises d'être en boucle fermée à l'étranger afin de pouvoir créer des sites Web de conformité à l'étranger.
5.4 Conclusion
Avec le développement mondial de Trip.com, le développement technique des billets de train s'est progressivement étendu du domaine technique d'origine pour traiter des scénarios plus complexes. Il reste encore un long chemin à parcourir avant de pouvoir établir un système de mondialisation complet. Dans ce contexte, il est nécessaire de continuer à dépasser ses propres frontières techniques, de réaliser la transformation des capacités unidimensionnelles en capacités multidimensionnelles, d'établir des plans à l'avance et de fournir continuellement de la valeur technique à l'entreprise.
[Lecture recommandée]
Pratique de reconstruction de l'architecture des billets d'avion internationaux de Ctrip
Ctrip 10 moyens efficaces pour réduire le délai d'attente des clients
Optimisation des performances d'épissage de la solution de transport de transfert Ctrip
Faible coût et petite erreur, la pratique de Ctrip de file d'attente sans serveur basée sur Kafka
Compte public « Ctrip Technology »
Partager, communiquer, grandir