Conception et mise en pratique d'une architecture de stockage pour des dizaines de millions de commandes par jour | Équipe technologique de JD Logistics

1. Aperçu du système de commande

1.1 Périmètre d'activité

Métiers de services : livraison express, livraison express, petites et moyennes pièces, gros articles, chaîne du froid, international, logistique contractuelle B2B, CLPS, Jingxi, three-in et three-out (achats in, retours in, allocation in, ventes, retrait d'approvisionnement, allocation) )attendre

1.2 Valeur du centre de commande

1. Découplage ( amélioration de la stabilité du système )

Système d'origine : la transaction et la production sont couplées, et les nouvelles exigences commerciales impliquent plusieurs systèmes en amont et en aval. ECLP, commandes étrangères, lettres de transport, systèmes de terminaux, etc. La logique de plusieurs secteurs d'activité est couplée, et les changements dans les exigences d'un seul secteur d'activité impliquent la transformation associée des autres secteurs d'activité dans le système d'origine.

Nouveau système : découplage des transactions et des opérations de production : les demandes liées aux transactions sont résolues dans le domaine des commandes ; les demandes côté production sont résolues dans le domaine de la production, réduisant ainsi les interactions en amont et en aval.

Couplage des secteurs d'activité : différents secteurs d'activité ont des processus métier différents. Les modifications apportées aux exigences d'un seul secteur d'activité ne seront mises à jour que de manière itérative dans le processus spécifique et n'affecteront pas les autres secteurs d'activité. Améliorez la stabilité de l’ensemble du processus et de l’entreprise.

2. Améliorer la vitesse d'accès aux nouveaux services

Le centre de commande fournit des fonctionnalités standard réutilisables à la réception pour accélérer l'introduction de nouvelles affaires.

Le centre de commande divise et résume les grandes applications du système d'origine en plusieurs petites combinaisons d'applications et prend en charge l'orchestration à la demande des processus métier dans différents scénarios. En réutilisant les capacités standards publiques de la plateforme centrale, les nouvelles entreprises peuvent accéder rapidement au centre de commandes et éviter la duplication des mêmes fonctions.

3. Fournir un modèle de données global unifié

Système d'origine : les commandes appartiennent à plusieurs systèmes, y compris les commandes externes, ECLP et les systèmes à grande échelle. Il existe plusieurs ensembles de bases de données et la sémantique métier n'est pas unifiée, ce qui rend la construction de données peu pratique.

Nouveau système : le centre de commande définit uniformément le modèle de données standard des commandes, permettant de stocker les données de différentes entreprises dans le même système, réduisant ainsi la duplication des fonctions liées au domaine des commandes, évitant le gaspillage de ressources et supprimant les barrières départementales. Cela permet aux données et aux processus d'être gérés et optimisés de manière centralisée, fournissant des données standard dans le domaine des commandes pour l'analyse commerciale du groupe et la prévision du futur espace d'innovation de JD.com .

2. Introduction à l'architecture

2.1 Conception globale de l'architecture

Grâce au projet de mise à niveau de l'architecture technologique de milieu de gamme, le système commercial est reconstruit avec une nouvelle architecture à quatre couches d'accès-transaction-performance-exécution. L'ordre de transaction est responsable de la clôture du flux documentaire du contrat de service logistique entre la logistique et les clients, et porte également la responsabilité de la distribution à l'OFC en aval (couche d'exécution des commandes).

2.2 Conception de l'architecture de la couche de données en temps réel

2.2.1 Diagramme d'interaction du système

L'interaction du système est la suivante :



L'interface standard du centre de commande a la clôture des documents dans la couche supérieure, et nous avons également effectué une clôture unifiée dans la couche de données.

Découplez l'architecture d'entreprise des données et séparez les conceptions à haute disponibilité et hautes performances telles que les bases de données distribuées, les caches et la cohérence de la portée de l'architecture d'entreprise, permettant ainsi à l'architecture d'entreprise de se concentrer sur l'entreprise elle-même.

Système de persistance : utilisé pour prendre en charge la persistance des données telles que la réception de commandes, la modification de commandes, l'annulation de commande, la suppression de commande, etc.

Système de recherche : fournit des services tels que l'enquête sur les détails de la commande, l'enquête sur la liste des commandes, l'enquête sur le flux de l'état des commandes et le jugement quant à savoir si les commandes Baichuan sont passées.

Système de relais : hub de données, qui écrit les données de commande sur Elasticsearch, HBase et MySQL via la file d'attente des messages de consommation.

Système de réconciliation des données : utilisé pour comparer la cohérence des données de plusieurs ensembles de middleware de stockage afin de garantir la cohérence finale des données.

Système de synchronisation des données : synchronisez les conditions de requête et les champs d'affichage de liste requis pour la requête de liste de commandes de l'ancien système vers le centre de commande, ce qui est utilisé pour résoudre le problème de pagination difficile en raison des données de commande existant dans l'ancien et le nouveau système pendant le processus de coupe.

2.2.2 Schéma d'architecture technique



• [Architecture de séparation lecture-écriture] Adopte le mode d'architecture de séparation lecture-écriture (CQRS) pour séparer le trafic de lecture et d'écriture afin d'améliorer les performances et l'évolutivité des requêtes, tout en réalisant un découplage de lecture et d'écriture.

• [Mise en cache] Utilisez le cache distribué Redis pour mettre en cache les données de commande courantes et les informations liées aux commandes afin d'améliorer la simultanéité et la vitesse de réponse et de réduire l'accès à HBase . Dans le même temps, trois ensembles de caches hautes performances, primaire, de sauvegarde et temporaire, sont utilisés pour améliorer la tolérance du système aux catastrophes.

• [Message Queue] Utilisez la file d'attente de messages JMQ pour implémenter le traitement asynchrone des commandes afin d'améliorer le débit du système, tandis que la réduction du trafic maximal réduit la pression des requêtes directes vers ES, HBase et les bases de données. L'isolation de différents scénarios commerciaux (tels que les commandes et les retours) à l'aide de différents sujets peut faciliter une meilleure gestion et maintenance ; l'utilisation de différents sujets pour isoler différentes entreprises peut permettre un traitement parallèle et une expansion horizontale des messages, et améliorer le débit et les performances du système.

• [Requête complexe] Utilisez le moteur de recherche Elasticsearch pour résoudre des requêtes complexes de commandes. Obtenez d'abord le numéro de commande via Elasticsearch, puis interrogez le cache distribué Redis + base de données en colonnes HBase en fonction du numéro de commande.

• [Stockage persistant à faible coût] Utilise la base de données en colonnes HBase pour prendre en charge un stockage de données à grande échelle et une forte évolutivité.

• [La cohérence des données] est obtenue grâce à des transactions fortes, une cohérence éventuelle, l'idempotence, une compensation, des verrous distribués, des numéros de version, etc.

• [Architecture multi-tenant] Le système adopte un modèle de données multi-tenant pour stocker les données des locataires séparément afin de garantir l'isolation et la sécurité des données. Développez dynamiquement la capacité et les ressources du système en fonction des besoins des différents locataires, ce qui peut prendre en charge l'expansion horizontale du système. En partageant l'infrastructure et les ressources, l'architecture multi-tenant permet une meilleure utilisation des ressources et une réduction des coûts.

2.3 Avantages de conception

2.3.1 Haute disponibilité

• Les serveurs d'applications, MySQL, Redis, HBase, JMQ, etc. sont tous déployés dans les salles informatiques ; déploiement d'une seule salle informatique ES, création de clusters ES maître et sauvegarde dans deux salles informatiques

• Isolation, limitation de courant, fusion, écrêtage, surveillance

2.3.2 Hautes performances

• Mise en cache hautes performances

• Asynchrone

2.3.3 Traitements massifs de données

• Sous-base de données et sous-tableau

• Séparation chaud et froid

• Stockage de colonnes ( HBase)

2.3.4 Sécurité des données

Les informations sensibles sont cryptées et stockées. Log, Redis, ES, MySQL, HBase, etc. utilisent tous un stockage crypté. "Celui qui les stocke les crypte, et celui qui les utilise les déchiffre."

3. Modèle de données de commande

3.1 Modèle PDM

Dans la conception du modèle de commande, basé sur les principes d'attributs commerciaux unifiés, de modèles généraux abstraits et d'induction d'entités communes, le modèle de commande est principalement divisé en informations de fichier principal de la commande, informations sur le produit de la commande, informations sur le service logistique. de la commande, les informations marketing de la commande et le modèle de commande, les informations financières, les informations sur le canal client de la commande, les informations sur la réception et la livraison de la commande, les informations sur l'opération de commande, les informations étendues sur la commande, etc.







3.2 Évolutivité du modèle

3.2.1 Conception d'extensibilité du modèle standard

Il y a des dizaines ou des centaines de champs d'identification dans la commande. Si de nouveaux champs sont utilisés à chaque fois, les attributs commerciaux de la commande et le modèle de données seront considérablement élargis, corrodant le modèle et l'efficacité du développement sera faible, donc le format KV est utilisé pour l'entreprendre et le stocker. Divisez l'identification en différents domaines commerciaux, tels que l'identification des commandes, l'identification des produits, l'identification marketing, etc.

3.2.2 Évolutivité du modèle économique personnalisé

Pour une entreprise personnalisée, un ensemble de solutions de gestion de terrain de base de données configurables sont fournis. Grâce à certains paramètres prêts à l'emploi, lorsque les commandes sont soumises, modifiées et interrogées, différents modèles de données peuvent être trouvés en fonction de l'identité de l'entreprise + du type d'entreprise + domaines d'activité et le codage de l'expansion des données, c'est-à-dire trouver la table et le champ à stocker. N attributs étendus sont réservés dans chaque table.Pour le même attribut étendu, différentes identités métiers + types d'entreprise représentent différentes significations pour obtenir un stockage étendu.



4. Avenir et défis

4.1 Commander une demande personnalisée

La demande de requêtes personnalisées augmente, comme les requêtes floues, l'agrégation en temps réel basée sur les conditions de requête, etc. Si les index ES sont placés dans le même cluster, cela affectera la stabilité globale du cluster, mais après la division, les données métier ne peuvent pas être interrogé et affiché avec d'autres entreprises. .

4.2 Architecture unitisée

La persistance actuelle de l'ordre TP99 est de 47 ms, et le TP99 est de 20 ms lorsqu'il n'est pas dans les salles informatiques. Du point de vue des données, les salles multi-ordinateurs ont un grand impact sur les performances.

L'unification permet aux demandes associées du même utilisateur d'être traitées dans une « boucle fermée » de tous les services dans une seule salle informatique, éliminant ainsi l'accès « entre salles informatiques » . La méthode de déploiement unitaire permet à chaque salle informatique d'être déployée dans n'importe quelle zone et de nouvelles salles informatiques peuvent être agrandies à tout moment. Grâce à l'unitisation, nous continuerons à renforcer les bases de la plateforme de commande.

4.3 Contrôle des coûts matériels

Le volume quotidien moyen des commandes continue d'augmenter et la quantité de données devient de plus en plus importante, suivie d'une augmentation des coûts du matériel. Comment contrôler l'augmentation des coûts du matériel est un défi aujourd'hui et à l'avenir. Nous prévoyons de réduire les coûts de stockage des données grâce à l'archivage des données, à la hiérarchisation des données chaudes et froides et à d'autres méthodes .

Auteur : Wang Weidong de JD Logistics

Source : JD Cloud Developer Community Ziyuanqishuo Tech Veuillez indiquer la source lors de la réimpression

Amende de 200 yuans et plus d'un million de yuans confisqués You Yuxi : L'importance des documents chinois de haute qualité Le serveur de migration hard-core de Musk Solon pour JDK 21, les fils virtuels sont incroyables ! ! ! Le contrôle de la congestion TCP sauve Internet Flutter pour OpenHarmony est là La période LTS du noyau Linux sera restaurée de 6 ans à 2 ans Go 1.22 corrigera l'erreur de variable de boucle for Svelte a construit une "nouvelle roue" - les runes Google fête son 25e anniversaire

{{o.name}}

{{m.nom}}