Évolution de l'architecture du système de commerce électronique Autohome et pratique de l'architecture de la plate-forme-IA-php.cn

★ Table des matières★

01	Avant-propos
02	Évolution de l'architecture 2.1 étape initiale 2.2 Phase microservice 2.3 Phase données de référence 2.4 Phase architecture plateforme
03	Pratique de l'architecture de plate-forme 3.1 Identité commerciale 3.2 Orchestration des services 3.3 Configuration métier 3.4 Outils de développement 3.5 Visualisation des données 3. 6 Accumulation de connaissances
Épilogue	4.1 Explorer de nouveaux commerces de détail 4.2 Mise à niveau de l'architecture Avant-propos Le système de commerce électronique Autohome est né en 2014 et s'est développé de 2016 à 2019. Il a connu le test de pointe des parties Double 11 et 818 pendant de nombreuses années et a accumulé des capacités de transaction en ligne stables, fiables et excellentes. . Avec la montée de la vague de construction de plates-formes intermédiaires d'affaires, elle est entrée dans la phase de construction de plates-formes intermédiaires en 2019, exportant son accumulation de cinq ans de capacités dans le domaine du commerce électronique automobile, contribuant ainsi au développement de l'industrie du commerce électronique automobile. , et accélérer la transformation numérique des entreprises ! Évolution de l'architecture Cette partie parle principalement du processus de développement de l'architecture du système de commerce électronique Autohome, de l'état de l'entreprise, des défis techniques et des stratégies de réponse du système technique à chaque étape. Dans la phase initiale Après que l'environnement Internet ait connu la La guerre des milliers de groupes et la guerre du commerce électronique‍[1] de 2011 à 2013, le commerce électronique est devenu la monétisation du trafic Internet hors publicité. Autre point fort stratégique en dehors du modèle. Pendant la période « Double Eleven » en 2013, Autohome a lancé un service d'achat de voitures et a considéré le lien transactionnel comme une direction de développement importante[2]. Dans la phase initiale de l'activité, l'exigence technique est d'itérer rapidement et d'aller en ligne pour vérifier la faisabilité du produit. Tout en répondant aux besoins quotidiens des entreprises, la réflexion sur l’architecture technique ne s’est pas arrêtée. Compte tenu de l'évolutivité du futur système de commerce électronique et en référence au système technologique d'Alibaba dans l'industrie, nous avons commencé à développer la pile technologique en 2014 et sommes progressivement passés du système .NET au système Java, et avons terminé toutes les mises en marche des applications. 30 mai 2015. Lancement de la plateforme complète d'achat de voitures en ligne Car Mall . Étape microservice Avec le développement rapide du commerce électronique, le nombre de personnel technique a augmenté. En 2016, l'équipe technique comptait des centaines de personnes. La douleur d'une architecture monolithique arrive de plein fouet. Quant à un projet git de centre commercial frontal, près de 30 sous-projets maven sont développés en parallèle lorsque des conflits de fusion de code surviennent souvent, des demandes sont en attente en ligne et des lenteurs en ligne. se produit. SQL et d'autres problèmes, l'efficacité du développement et la stabilité du système dans son ensemble se sont détériorées. À l'heure actuelle, le support système est confronté à d'énormes défis et l'architecture du système doit être mise à niveau et évoluer. Nous avons commencé à développer une stratégie distribuée, en divisant le système unique d'origine en plusieurs systèmes centralisés présentant une cohésion élevée et un faible couplage. C'est-à-dire que le centre utilisateur, le centre de produits, le centre de commande, le centre de promotion, le centre de coupons et le centre marchand actuels peuvent être conçus, reçus et publiés indépendamment. L'efficacité de la R&D et la stabilité du système ont été améliorées. mesures. À ce stade, nous avons techniquement terminé la construction du système de produits au niveau d'un million [3], du système de commande [4] et du système de coupons [5] pour prendre en charge le commerce électronique automobile, et terminé la migration vers le cloud de toutes les applications [ 6] et automatisation Construction de plates-formes de tests[7]. Dans le même temps, nous avons exploré divers modèles commerciaux tels que le modèle de commerce électronique de véhicules autonomes, le modèle de plateforme ouverte, le modèle B2B2C, le modèle de devis, le modèle de conseil, le modèle TPCC et les ventes parallèles de voitures importées. Étape des données de référence Le commerce électronique se développe si rapidement qu'en 2019, l'entreprise dispose déjà d'une variété de modèles de transactions en ligne, tels que les voyages, les produits automobiles et les services après-vente, l'échange de points, etc. Sur la base de la stratégie de développement, l'entreprise a décidé de créer une plate-forme intermédiaire de commerce électronique. D'une part, il s'agit de concentrer les ressources de produits et les ressources opérationnelles de haute qualité de l'entreprise pour créer une plate-forme commerciale de commerce électronique verticale influente. d'autre part, il s'agit également de gérer et de contrôler raisonnablement les ressources techniques et de réaliser le système de commerce électronique de l'unité. Dans ce contexte, mon équipe s'est chargée de construire une plateforme intermédiaire de commerce électronique. Étant donné que les formes commerciales et les architectures techniques de chaque système sont très différentes, le premier problème auquel nous avons été confrontés a été de savoir comment réaliser l'intégration des systèmes de classes. À cette fin, d’une part, nous avons commencé à nous familiariser avec l’état actuel des systèmes de trading dans différents scénarios commerciaux et, d’autre part, nous réfléchissons et discutons également de solutions techniques. En fin de compte, nous avons choisi la solution « basée sur la normalisation des données, fournissant des services milieu de gamme standardisés et intégrant système par système de bas en haut ». Normalisation des données Les données sont l'actif principal de l'entreprise Dans tout système, en particulier les systèmes commerciaux, les données sont la priorité absolue. D'une part, la construction de données de base peut unifier le modèle de données et briser les barrières du système ; d'autre part, elle peut également effectuer une analyse des données opérationnelles grâce à des données centralisées et fournir une base aux décisions commerciales. C'est pourquoi nous considérons la construction. des données de base comme première étape de l'intégration du système. Dans le processus de transaction, les données les plus importantes sont concentrées dans les quatre domaines des commerçants, des produits, des commandes et des activités promotionnelles. Sur la base de la situation actuelle des scénarios de transaction de l'entreprise, nous extrayons les données de base dans ces quatre domaines et les modélisons dans. de manière unifiée autant que possible. Convient à la plupart des scénarios de trading. Ce qui suit est un diagramme schématique de la structure du modèle de données de base des données de base de la commande : Après avoir terminé le modèle de données unifié, l'étape suivante consiste à importer les données hétérogènes existantes dans la base de données principale. Nous utilisons la base de données de lecture. binlog L'importation initiale de synchronisation des données s'effectue via le traitement des données (mysql, sqlserver), qui est également la solution la plus rapide et la moins intrusive pour l'entreprise. Standardisation des API Après avoir terminé la construction des données de base, l'étape suivante consiste à démarrer la construction de normalisation de l'API basée sur les données de base. L'API peut être considérée comme le nerf du système. Les API de haute qualité peuvent connecter un niveau élevé. -système de qualité et l'unifier. L'API réalise également la fermeture du système dans une certaine mesure. À cette fin, nous suivons le principe de responsabilité unique, différencions selon les domaines, clarifions les limites et atomisons toutes les fonctions API sous-jacentes pour permettre aux utilisateurs en amont d'assembler de manière flexible les API pour compléter la logique métier. En même temps, nous unifions la structure des paramètres de. l'API et la structure des résultats de réponse. Les codes d'erreur unifiés, la publication et les appels unifiés basés sur la passerelle API, la surveillance des statistiques des données API, la dégradation et la limitation du courant réalisent une gestion et un contrôle unifiés. Commutation de lecture et d'écriture d'API Avec une API standardisée, il est naturel que les entreprises l'utilisent pour refléter la valeur de l'API. Afin d'éviter que l'étape ne prenne une étape trop importante, nous l'utilisons également. en fonction de l'importance et de l'ampleur de l'entreprise.La solution progressive de lecture et d'écriture implique d'appeler et de changer d'entreprise une par une. Cela semble être une étape très raisonnable, mais elle expose également de nombreux problèmes au cours du processus d'exécution proprement dit. scénarios où la lecture et l'écriture sont fortement dépendantes, par exemple : l'utilisateur sautera immédiatement après avoir passé une commande. Accédez aux détails de la commande pour afficher la commande. À ce moment-là, lorsque le changement d'API d'écriture n'est pas terminé, la lecture des données se fait via la lecture. L'API échouera en raison du retard de synchronisation des données. À l'heure actuelle, il n'y a aucun moyen de basculer par étapes en fonction de la lecture puis de l'écriture. La meilleure méthode consiste à basculer entre la lecture et l'écriture en même temps. 2) La méthode ayant le moins d'impact sur le changement d'entreprise est bien sûr compatible avec les paramètres et les résultats de retour de l'interface d'origine. Si nous forçons le côté commercial à changer selon notre API standard, cela entraînera inévitablement des coûts de changement et des effets négatifs inutiles. du côté des affaires. À l’heure actuelle, nous devons naturellement faire des compromis du point de vue de l’autre partie. La méthode que nous adoptons consiste à ajouter une couche d'adaptation au-dessus de l'API standard pour la conversion des anciens et des nouveaux protocoles, de sorte que l'entreprise n'ait qu'à changer le nom de domaine et l'URL demandée, et que l'autre logique reste inchangée, maximisant ainsi la Sympathique pour le côté commercial. 3) Étant donné que les API sous-jacentes que nous fournissons sont toutes atomiques, dans les scénarios réels, en particulier dans les projets où le front-end et le back-end sont séparés, le front-end n'est pas disposé à appeler l'interface plusieurs fois pour obtenir le même résultat. , nous sommes également Une couche de façade est ajoutée au backend. Sur la base de l'API atomique sous-jacente, les API qui répondent aux scénarios commerciaux sont fournies au monde extérieur et sont modérément compatibles avec la logique d'interface différenciée. 4) La commutation de lecture et d'écriture ne peut pas être réalisée du jour au lendemain.Dans ce processus, il y aura inévitablement des scénarios dans lesquels l'API de données principale et l'API métier d'origine coexisteront. Puisque toutes les entrées API seront fournies par nous, nous adopterons également un mécanisme de routage, via. la couche de routage Différents emplacements sont transférés et toutes les API sont transparentes pour l'appelant. 5) Dans le processus de changement d'API actuel, il existe un scénario particulier. Étant donné que le système doit être intégré à la fin, forcer le changement d'API pour les fonctions qui seront intégrées ultérieurement est en fait un gaspillage de ressources, nous sommes donc également en avance sur le calendrier. . Après avoir fait un préjugé, vous pouvez modérément éviter de changer et attendre que les fonctions soient intégrées avant de changer l'ensemble des fonctions. Intégration des fonctions système Après avoir terminé la commutation de lecture et d'écriture de l'API, les fonctions basées sur les données de base ont pratiquement terminé l'agrégation. À ce stade, il est nécessaire d'unifier systématiquement les fonctions communes, telles que : la gestion unifiée des commerçants. backend, fonctionnement unifié Backend, expérience de transaction unifiée C-end, etc. Le but de l'intégration unifiée au niveau du système est de donner aux utilisateurs une interface d'exploitation unifiée et de refléter le professionnalisme de la plateforme. Dans le processus d'intégration du système, nous avons adopté le principe de « précipitation des points communs et compromis des différences ». Pour les capacités communes, telles que la sortie du produit, la liste de commandes et d'autres fonctions, nous ferons abstraction des capacités communes et fournirons une unité unifiée. Capacités. L'interface d'exploitation répond aux exigences d'utilisation de diverses parties commerciales. Pour les fonctions qui sont propres au côté commercial, nous recommanderons que le côté commercial les implémente. Pour les fonctions qui ne peuvent pas encore former de capacités générales mais qui pourraient le devenir à l'avenir, nous utiliserons le moyen le plus rapide d'implémenter de petites versions en ligne dans. conformément au principe MVP , avec l'itération des affaires, la précipitation des fonctions est continuellement réalisée. Pendant tout le processus d'intégration du système, de nouvelles exigences apparaîtront inévitablement lors de l'intégration des fonctions du système d'origine. Face à ce scénario, notre approche consiste à développer simultanément les nouveaux et les anciens systèmes, ce qui semble en fait augmenter le coût de l'intégration des nouveaux. Les systèmes sont bénéfiques, d'une part, ils n'affecteront pas le développement de l'entreprise et ne provoqueront pas de stagnation de l'entreprise en raison de l'intégration technique. D'autre part, les problèmes possibles dans le nouveau système peuvent être découverts en comparant l'ancien et l'ancien. nouveaux systèmes, ce qui sera également le meilleur moyen de vérifier la fonctionnalité du nouveau système intégré. Après avoir terminé la plupart des travaux d'intégration du système, les principaux liens de transaction du commerce électronique sont opérationnels et ont fait l'objet d'une vérification en ligne à long terme, depuis l'entrée du commerçant, la sortie du produit, l'affichage du produit, la passation de commande, le paiement, l'exécution du contrat, depuis l'après-vente. jusqu'au règlement final, les problèmes rencontrés au cours du processus sont également résolus un par un. À ce stade, nous avons achevé l'intégration des trois principaux systèmes commerciaux de l'entreprise et effectué la mise à niveau architecturale du système de vente flash de la plateforme de commerce électronique [8] et la mise à niveau structurelle du système de coupons pour prendre en charge le 818 Party et Double 11 en 2020-2021, Double 12 et d'autres événements à grande échelle tels que des ventes flash et des scénarios d'émission de coupons. En outre, nous explorons également activement la théorie et la pratique industrielle du modèle DDD axé sur le domaine et l'avons mis en œuvre dans la reconstruction du système de base de données de factures[9], qui fournit également un support technique pour les mises à niveau ultérieures de l'architecture de la plate-forme. Étape d'architecture de plate-forme Alors que le centre d'affaires du commerce électronique continue de « s'approcher » de l'entreprise, l'abstraction et la difficulté de construction du système ont également augmenté de façon exponentielle, et une série de nouveaux problèmes sont apparus : 1) Avec la fin du projet de construction de plate-forme intermédiaire et l'évacuation du personnel, la plate-forme intermédiaire de commerce électronique a intégré la logique de nombreux secteurs d'activité et le code est rempli d'un grand nombre de jugements conditionnels sur le coût de développement. et le coût de régression des tests de chaque itération de demande est très élevé, comment isoler la logique entre les différentes métiers et réduire le couplage entre métiers ? 2) Comment faire abstraction des capacités communes de plusieurs secteurs d'activité qui ont été connectés à la plateforme commerciale de commerce électronique pour éviter la duplication de la construction ? 3) Lorsqu'une nouvelle entreprise est connectée au centre d'affaires du commerce électronique, comment peut-elle être rapidement assemblée et lancée sur la base des capacités et des solutions existantes pour prendre en charge une itération commerciale et une innovation rapides ? 4) Comment pouvons-nous utiliser les moyens techniques pour contribuer à améliorer l’efficacité du travail quotidien dans les opérations des produits ? En résumé, il est particulièrement important d'abstraire les capacités communes des secteurs d'activité ainsi que la conception et la mise en œuvre réutilisables de capacités communes dans la plate-forme intermédiaire d'entreprise de commerce électronique au cours du processus de construction. La plate-forme intermédiaire d'entreprise doit parvenir à la réutilisation des capacités et à la flexibilité. faire de la plate-forme intermédiaire la construction joue un rôle dans la réduction des coûts et l'augmentation de l'efficacité dans le processus de développement des entreprises. L’architecture du système doit être mise à niveau, ce qui conduit à l’étape d’architecture de plateforme. Pratique de l'architecture de plateforme Qu'est-ce que l'architecture de plateforme ? Il est nécessaire de séparer les capacités de base des services caractéristiques de chaque partie commerciale et d'isoler la logique entre les services. Le cœur de la plateforme est l'ouverture de la modélisation abstraite des affaires et de l'architecture du système. L'abstraction commerciale résout 80 % des problèmes courants, et l'ouverture de l'architecture du système résout 20 % des problèmes personnalisés. Après avoir fait référence à la solution "Modern Enterprise Architecture White Paper" proposée par ThoughtWorks[10]et aux solutions milieu de gamme des sociétés Internet du secteur Meituan[11] et Youzan[12] , nous avons donné une maison adaptée Appliance Solution pour plate-forme de commerce électronique : utilisez la modélisation basée sur le domaine pour résumer les capacités communes de plusieurs secteurs d'activité dans le secteur du commerce électronique et réserver des points d'expansion, puis utilisez l'orchestration des services pour combiner les capacités communes. Le principe est le suivant : chaque entreprise exécutée dans le secteur du commerce électronique peut être comprise comme : identité commerciale + processus métier + règles. Le processus métier est réalisé par l'orchestration des services de processus, et le point d'extension est réalisé par l'extension. mécanisme de points. Dans l'ensemble du processus de transaction, l'entrée des commerçants et la libération des produits du côté B sont relativement courantes. Les principales différences de processus entre les différentes entreprises se reflètent dans l'exécution des commandes avant et après le paiement. Ces processus nécessitent souvent un développement personnalisé. C'est pour cette raison que toute la solution est au cœur de la conception architecturale de la plateforme de commande. Comme le montre l'image : l'ensemble de l'architecture de la plateforme de commande est divisée en quatre couches, de bas en haut : Couche d'infrastructure : fournit des middlewares tels que le stockage, la messagerie, RPC, etc. Couche de services de base : les services de base sont organisés par domaine et les services de domaine fournissent des points d'extension pour les différences entre les différentes entreprises. Couche de capacités commerciales : connectez différents services de domaine pour former des capacités commerciales pouvant être utilisées en externe, telles que la commande, le paiement, etc. Couche de processus métier : organisez les capacités commerciales, formez les processus de transaction de commande et terminez les processus de transaction de commande. Couche métier : développer l'identité commerciale, la mise en œuvre des points d'extension et la configuration des processus métier pour obtenir différentes différences commerciales. L'ensemble du processus pratique de mise à niveau de l'architecture de la plateforme de commande est résumé dans les points suivants : Identification de l'entreprise Le concept d'identité commerciale a été proposé pour la première fois par Alibaba lorsque la plateforme commerciale fournit des services à diverses entreprises en même temps. , il doit être capable de distinguer les éléments d'identité commerciale de chaque demande de service commercial afin de fournir des services différenciés et personnalisés. Il est donc nécessaire de modéliser et de différencier les identités et les caractéristiques de chaque activité de l'entreprise, et le résultat est ; l’identité de l’entreprise. L'identité de l'entreprise est unique. Elle est similaire à un numéro d'identification et doit être unique dans l'ensemble de l'entreprise. Grâce à l'identité métier, le centre d'affaires peut résumer le processus métier et les règles métier, et mettre en œuvre le routage des services et la surveillance métier en fonction de l'identité métier. Deuxièmement, l'identité d'entreprise est similaire au concept de locataires dans le système SAAS. Différentes parties commerciales utilisent des identités d'entreprise pour isoler les autorisations de données dans le middle office. Cela garantit que les opérations de chaque entreprise ne peuvent voir que les données de leur propre partie commerciale. Par exemple, dans le domaine du commerce électronique automobile, nous faisons abstraction de l'identité de l'entreprise à travers trois dimensions : les personnes, les biens et les lieux. La dimension humaine comprend si vous êtes membre, si vous êtes propriétaire d'une voiture certifiée, quels services à valeur ajoutée ont été activés, etc. ; la dimension des biens comprend le type de produit (véhicule complet, biens physiques, biens virtuels, etc.) ; méthode de livraison (radiation, échange, livraison en magasin 4S), etc. ; les dimensions du champ incluent la commande en ligne, la commande hors ligne, le centre commercial en ligne dans lequel la commande a été passée, le magasin de livraison dans lequel la commande a été passée, la source du canal de livraison des produits, etc. Une fois qu'une identité commerciale unique est déterminée sur la base de ces dimensions, le processus métier de chaque transaction est déterminé. Orchestration des services Le centre d'affaires du commerce électronique adopte l'architecture des microservices dans son ensemble, et l'ensemble du système de commerce électronique est divisé en centre marchand, centre utilisateur, centre de produits, centre de promotion, centre de transactions, centre de traitement des commandes. Centre et centre de service après-vente. Chaque centre est logiquement divisé en deux couches : des capacités avec des attributs métier et des capacités de base sans attributs métier. La couche de capacités de base se concentre sur les attributs d'entité, les comportements et les événements du modèle de domaine, qui ne changeront pas avec l'ajustement des besoins commerciaux. Elle se concentre sur les comportements courants du secteur, fait converger les modèles commerciaux et garantit la stabilité des services de base. Les capacités avec des attributs métiers sont construites sur la couche de capacités de base grâce à des moyens techniques tels que la composition des services et l'orchestration des processus pour former des solutions orientées métier et achever la transformation de la communauté commerciale vers la personnalisation. Il existe deux approches courantes : l’une consiste à utiliser le codage en dur. À mesure que la logique des différents secteurs d'activité continue de croître, les capacités de base appelées par chaque capacité métier deviendront complexes, ce qui rendra difficile leur configuration et leur mise en œuvre flexible. Lorsque les exigences changent, il est difficile pour les testeurs d'évaluer l'ampleur de l'impact des modifications, et le cycle de coûts des tests de régression est long, ce qui rend difficile un développement véritablement agile et une réponse commerciale rapide. La seconde consiste à utiliser l’orchestration des services. Composez des services grâce à l'orchestration de services de microservices existants, puis renvoyez les informations requises par la réception en une seule fois. Les capacités des différents secteurs d'activité exécutent différents processus grâce au cadre d'orchestration graphique, XML et JSON, le processus peut être clair et les détails du code peuvent être protégés. Il n'est pas nécessaire d'entrer dans les détails sur les avantages du fractionnement des services, mais pour réaliser de la valeur commerciale, il ne s'agit pas des capacités d'un seul service, mais de la coordination de tous les services pour assurer le succès de bout en bout de l'activité de l'entreprise. processus. La plate-forme intermédiaire est la plate-forme d'intégration pour les entreprises. La technologie d'intégration doit coupler de manière lâche les applications et les ressources qui composent le processus. Dans le cas contraire, la logique du processus sera codée en dur dans une plate-forme technologique spécifique et des changements pourraient survenir. coûteux, violant ainsi l’ensemble de l’objectif de réutilisation des processus métier. Cadre d'orchestration de services Dans le domaine de l'orchestration de services, il existe déjà de nombreuses solutions industrielles. Nous nous référons à Orchestration de services basée sur une passerelle API [13], aux cadres d'orchestration basés sur un système de workflow Flowable et Activiti [14] et Netflix. Conductor[16] et Zeebe[17] sont des frameworks d'orchestration d'architecture de microservices. Grâce à l'analyse des principes techniques, nous avons constaté qu'ils présentent tous certaines lacunes et ne peuvent pas être appliqués à l'orchestration de services pour les entreprises de commerce électronique milieu de gamme. En fin de compte, nous avons sélectionné Apache Camel [18] comme moteur sous-jacent. d'orchestration de services pour la deuxième fois. Développement d'emballages secondaires. Apache Camel est né en 2007. Vers 2009, il est devenu un projet Apache de haut niveau et a été renommé Apache Camel. La dernière version est la 3.0. L'avantage d'Apache Camel est qu'il dispose de plus de 300 composants d'extension en plus de dix ans depuis sa sortie ; le mécanisme d'extension est également extrêmement pratique et flexible ; il résout les problèmes d'intégration d'applications grâce aux meilleures pratiques disponibles immédiatement ; basé sur une architecture basée sur les événements a de bonnes performances et un bon débit [19]. Ce qui suit est un exemple simple d'orchestration de processus de service : Le middle office d'entreprise utilise la technologie d'orchestration des services, d'une part, il peut identifier automatiquement les capacités de transaction sous forme de présentation visuelle des composants pour former une carte des capacités, d'autre part, sur la base de ces capacités de base, il peut réaliser ; l'orchestration des processus de service par glisser-déposer. Le procédé construit rapidement tout ou partie du processus de transaction adapté à l'entreprise, similaire à des blocs de construction, en réutilisant les composants de base et en les faisant correspondre de manière flexible, réalisant ainsi la réutilisation du commerce électronique au niveau de l'entreprise. capacités, réduisant les coûts de développement et responsabilisant rapidement l'entreprise. Cadre de point d'extension Le nom complet du point d'extension est Service Provider Interface, ou SPI en abrégé. Il s'agit d'un ensemble de mécanismes fournis par Java pour charger et exécuter des classes d'implémentation d'interface d'extensions tierces. Il est généralement utilisé dans les scénarios de remplacement de composants et d'extension de framework. SPI sépare les interfaces de service et les implémentations de services pour réaliser le découplage et améliorer l'évolutivité des applications. En programmation, la programmation orientée interface est utilisée entre les modules sans références de classe d'implémentation spécifiques, et le plug-in d'application est obtenu en chargeant dynamiquement les classes d'implémentation. Le framework COLA est un framework de points d'extension pour l'architecture d'application proposé par les experts techniques d'Alibaba [20]. L'extension du framework COLA est implémentée via des annotations. Les annotations de l'extension Extension utilisent trois attributs : cas d'utilisation (useCase), business (bizId) et scénario (scenario) pour identifier l'identité. L'utilisation des points d'extension du framework COLA peut prendre en charge l'isolement logique de différentes identités métier au niveau du code, car différentes logiques sont dispersées dans différentes classes d'implémentation, ce qui est conforme au principe d'ouverture et de fermeture de la conception logicielle. Lorsque le contexte d'application Spring est initialisé, le framework COLA commence à analyser les beans avec les annotations d'extension pour l'enregistrement des points d'extension, qui sont stockées dans une structure Map. La clé est une concaténation de chaînes de useCase, bizId et scenario, et la valeur est la. haricot. Au moment de l'exécution, la classe d'implémentation du point d'extension est localisée via l'identité métier, puis la logique implémentée par le point d'extension est exécutée. Le routage à trois couches est pris en charge lors de la localisation de l'implémentation du point d'extension. Tout d'abord, le point d'extension sera trouvé selon la valeur par défaut de useCase+bizId+scenario. il n'a pas été trouvé, il sera trouvé selon la valeur par défaut useCase+bizId+scenario, le principe spécifique est illustré dans la figure : Pour les scénarios métier simples, il n'y a pas beaucoup de non-fonctionnels. exigences en matière d'évolutivité élevée et d'isolation commerciale du système d'application. Cependant, comme le même système d'application prend en charge davantage d'entreprises et que les scénarios commerciaux deviennent plus complexes, il est nécessaire de fournir des solutions d'expansion unifiées au niveau architectural pour solidifier les règles métier changeantes. Cela permet non seulement d'unifier les spécifications techniques, mais réduit également le codage en dur. . IF-ELSE, le mode stratégie, etc. sont causés par la complexité de compréhension et la cohérence des spécifications en raison de niveaux de développement incohérents. Grâce au mécanisme de point d'extension, le centre d'affaires peut gérer différents services à partir des niveaux d'identité d'entreprise et de cadre, comme les locataires de gestion SAAS. Différentes identités d'entreprise peuvent étendre des points d'extension prédéfinis dans différents scénarios. Le middle office commercial d'Alibaba repose également sur l'idée de points d'expansion, réalisant la séparation et le découplage de la logique commerciale de base et des détails techniques, afin que l'unité commerciale partagée puisse prendre en charge des centaines de secteurs d'activité au sein du groupe. Exemples d'orchestration de services + application de point d'extension Après avoir vérifié les fonctions, les scénarios du système de transaction de commerce électronique ont été classés. Tout d'abord, les nœuds avec une faible sensibilisation des utilisateurs et un impact minimal sur les utilisateurs même en cas de problèmes ont été sélectionnés pour les essais de reconstruction. , telles que les commandes impayées, sont clôturées au fil du temps et l'utilisateur annule la commande. Prenons comme exemple le scénario d'un utilisateur annulant une commande. Avant la modification, la logique permettant aux utilisateurs de chaque entreprise d'annuler des commandes est de modifier le statut de la commande en statut annulé, puis d'exécuter le même processus. L'ordre d'exécution du processus est difficile. -codé. Le pseudo code est tel qu'indiqué sur la figure : Après la modification, il a été soigneusement classé en fonction des caractéristiques de chaque commerce. Par exemple, si le commerce de voitures d'occasion n'utilise pas de coupons, alors ce lien n'est pas nécessaire ; en termes de capacité générale des points, les points Wanlitong ont été étendus. Le pseudo code est représenté dans la figure : L'activité hôtellerie et billets d'avion du secteur d'activité voyageurs n'a pas le concept traditionnel de stock de matières premières, il n'est donc plus nécessaire de restituer le stock de matières premières, mais de faire abstraction une nouvelle fonctionnalité générale : annuler les commandes des fournisseurs et prédéfinir deux points d'extension pour l'annulation des commandes des fournisseurs d'hôtels et l'annulation des commandes des fournisseurs de billets d'avion. Le pseudo code est tel qu'indiqué sur la figure : L'effet d'application de l'ensemble du système est évident, se reflétant principalement dans l'amélioration des performances et de l'efficacité humaine. L'amélioration des performances se reflète principalement dans le temps de réponse raccourci du système. Le pourcentage d'amélioration TP99 de l'environnement de production de l'interface d'annulation des commandes après modification est d'environ 30 %. L'amélioration de l'efficacité humaine se reflète principalement dans la comparaison du temps nécessaire pour tester l'annulation des commandes et l'ajout de nouveaux nœuds de processus. Avant modification, les codes entre les processus métiers sont couplés. La modification du processus pour ajouter de nouveaux nœuds nécessite une régression. tests des activités précédentes. Après modification, il n'est pas nécessaire d'effectuer des tests de régression sur chaque entreprise. Configuration d'entreprise Dans la pratique de l'architecture de plate-forme, nous extrayons uniformément les configurations de base qui affectent le flux d'affaires et configurons les valeurs d'attributen fonction des identités d'entreprise pour garantir que les normes de l'ensemble du lien du processus de transaction sont unifié et réduit le besoin de Le code de lien de transaction principal est fréquemment modifié et différentes entreprises sont commutées de manière flexible à différents nœuds dans le même processus de transaction en fonction de différentes valeurs d'attribut. Par exemple : si le produit est automatiquement poussé vers le pool de ressources, si une carte d'identité est requise pour passer une commande, si un indice est poussé si le paiement est réussi, si la réception n'a pas été confirmée depuis plus de N jours, si la réception est automatiquement confirmée, etc. Tous les éléments de configuration sont unifiés via la gestion de la configuration en arrière-plan. De plus, pour toutes les métadonnées de la plateforme de commerce électronique, y compris les identités commerciales, nous avons également unifié la gestion via le backend de gestion de la configuration et fourni une API unifiée pour fournir des services de requêtes externes. Outils de développement En partant des aspects multidimensionnels des affaires et de la technologie, nous développons divers gadgets pratiques et pratiques pour les problèmes commerciaux courants ou les problèmes techniques qui surviennent dans le travail quotidien, afin d'améliorer l'efficacité du travail et de résoudre rapidement les problèmes. . Positionnement et autres effets, tels que : outils de distribution et de récupération de messages ; outils de calcul rapide des prix de remise des produits ; outils de comparaison et de surveillance des prix de mise à niveau en un clic ; Alors que la sensibilisation de chacun à l'outillage continue de croître, de tels petits outils continuent d'apparaître et sont rassemblés pour former une boîte à outils indispensable au personnel de R&D. Visualisation des données Les indicateurs de performance, les indicateurs d'utilisation des ressources, le volume d'appels et d'autres indicateurs dimensionnels du système de commerce électronique peuvent être surveillés de manière uniforme via la plate-forme cloud de l'entreprise. De la même manière pour les données commerciales dont nous avons besoin. pour fournir des données commerciales unifiées Les outils visuels fournissent aux parties commerciales une référence pour prendre des décisions pertinentes. À cette fin, nous avons développé un système de visualisation des commandes sur grand écran utilisant une approche en temps réel + hors ligne. Grâce à ce système, les modifications du volume des commandes peuvent être surveillées en temps réel à partir de plusieurs dimensions telles que le secteur d'activité, l'état des commandes et la région. Si la fluctuation du volume des commandes au cours d'une période de temps déterminée dépasse notre seuil préconfiguré, un message DingTalk sera envoyé pour informer rapidement la partie commerciale de votre attention. De plus, pour les données hors ligne, nous effectuons également une analyse statistique des données de plusieurs dimensions selon le jour, la semaine et le mois, et les enverrons éventuellement à l'entreprise sous forme d'e-mails et de messages d'application de bureau. Le but de ces moyens est de réaliser la gestion visuelle des données de commerce électronique et de fournir aux utilisateurs professionnels des outils plus pratiques pour une gestion et un contrôle complets des activités de commerce électronique. Accumulation de connaissances L'équipe dont je fais partie est une équipe professionnelle dans le domaine du commerce électronique au sein de l'entreprise et a accumulé beaucoup d'expérience dans la technologie et les opérations de produits au fil des ans. Tout au long du processus de construction de la plateforme intermédiaire de commerce électronique, nous avons également utilisé ces expériences et solutions aux problèmes quotidiens comme une accumulation continue de richesse. Dans le passé, nous avons utilisé des outils de gestion de documents tels que wiki pour les résumer. Afin de générer de la valeur à partir de ces connaissances, nous avons également commencé à construire notre propre système de base de connaissances sur le commerce électronique et à saisir tout le contenu pouvant être utilisé comme accumulation de connaissances dans le système de base de connaissances en fonction des différents domaines fournis par l'ensemble de la base de connaissances. récupération rapide et la fonction de positionnement peut servir le personnel technique et le personnel d'exploitation des produits, cultiver davantage la conscience de chacun de l'accumulation de connaissances et améliorer l'efficacité du travail de chacun. Épilogue Il y a vingt ans, Internet commençait tout juste à devenir populaire en Chine. Les informations étaient affichées sous forme d'informations et il n'y avait presque pas de transactions en ligne. Il y a dix ans, Internet se développait rapidement et les consommateurs pouvaient faire leurs achats en ligne représentés par Taobao. Tmall et JD.com Achetez les produits dont vous avez besoin ou que vous aimez dans le centre commercial pour les transactions en ligne ; désormais, diverses formes de commerce électronique émergent constamment, et c'est devenu une tendance aux cent fleurs qui s'épanouissent, comme le commerce électronique de contenu Xiaohongshu. , intérêt pour le commerce électronique Douyin Kuaishou, le commerce électronique social WeChat, Pinduoduo, etc., les sociétés de commerce électronique membres Tmall 88vip, JD plus, etc. Ces formulaires de transaction en ligne prouvent pleinement que le commerce électronique joue un rôle important dans la monétisation du trafic dans le domaine de l'Internet et qu'il est devenu l'eau, l'électricité et le charbon de l'infrastructure des entreprises Internet. La construction d'une plate-forme intermédiaire de commerce électronique n'est pas seulement la construction d'un système technique, mais aussi un processus de refonte de la structure organisationnelle. Toutefois, à mesure que le temps passe, l'espace de croissance de la valeur du middle office deviendra de plus en plus étroit. Cela nécessite de rechercher consciemment des points d'innovation, de dépasser les frontières du système existant et de penser au-delà des frontières. se rapprocher des activités du front office, mener activement l'exploration de nouvelles activités et la mise à niveau de l'architecture technique. Exploration du nouveau commerce de détail En explorant le modèle économique du commerce électronique automobile dans le passé, nous avons constaté que le principal problème était l'incapacité de contourner les magasins 4S pour fournir des services. Ces dernières années, Tesla et de nouvelles forces de construction automobile nationales ont émergé.Le modèle de vente directe émergent a brisé d'un seul coup l'écologie du système de distribution 4S des constructeurs automobiles traditionnels.Le groupe national d'achat de voitures est également devenu de plus en plus jeune. nous permettant de voir le nouveau modèle de commande de voitures en ligne + les modèles de vente au détail deviennent possibles. En mettant à niveau les capacités existantes du système de commerce électronique, les produits prennent en charge la sélection des SKU, les commandes prennent en charge le paiement combiné et le remboursement des dépôts importants et petits, et un nouveau système de livraison est ajouté pour fournir des services aux entreprises automobiles personnalisées des associations industrielles et des entreprises. de nouveaux magasins hors ligne de vente au détail d'automobiles. À l’avenir, nous continuerons à créer un modèle de prix flottants aligné sur l’industrie pour les nouvelles options énergétiques et un modèle d’ensemble de services pour les ensembles de produits optionnels. Mise à niveau de l'architecture Dans le processus de commande de transactions de commerce électronique d'origine, les services externes conçus étaient des services atomisés avec une granularité relativement faible, ce qui entraînait des coûts d'accès relativement élevés pour le côté commercial et une mauvaise expérience utilisateur. À l'avenir, nous améliorerons la solidité des produits et l'efficacité opérationnelle de l'entreprise grâce à des moyens techniques tels que l'ajout de couches BFF, la rationalisation de la chaîne d'appel et l'échafaudage d'accès au commerce électronique.