Entwicklung der Autohome-E-Commerce-Systemarchitektur und Praxis der Plattformarchitektur

★ Inhaltsverzeichnis

Entwicklung der Architektur 2.2 Microservice-Phase 3.4 Entwicklungstools 3. 6 Wissensanhäufung

2.1 Anfangsphase	2.3 Stammdatenphase
2.4 Plattformarchitekturphase	03 Plattformarchitekturpraxis 3.1 Geschäftsidentität 3.2 Service-Orchestrierung 3.3 Geschäftskonfiguration
3.5 Datenvisualisierung	04 Epilog 4.1 Erkundung neuer Einzelhandelsflächen 4.2 Architektur-Upgrade Vorwort Das Autohome-E-Commerce-System wurde 2014 geboren und wuchs von 2016 bis 2019. Es hat viele Jahre lang den Spitzentest der Double 11- und 818-Parteien erlebt und stabile, zuverlässige und hervorragende Online-Transaktionsfunktionen aufgebaut . Mit dem Aufkommen der Welle des Baus mittlerer Geschäftsplattformen ist das Unternehmen im Jahr 2019 in die Phase des Baus mittlerer Plattformen eingetreten und hat seine fünf Jahre gesammelten Fähigkeiten im Bereich des Automobil-E-Commerce exportiert und so die Entwicklung der Automobil-E-Commerce-Branche unterstützt und die digitale Transformation von Unternehmen beschleunigen! Entwicklung der Architektur In diesem Teil geht es hauptsächlich um den Architekturentwicklungsprozess des Autohome-E-Commerce-Systems, den Geschäftsstatus, technische Herausforderungen und Reaktionsstrategien des technischen Systems in jeder Phase. In der Anfangsphase Nachdem die Internetumgebung von 2011 bis 2013 den Tausende-Gruppen-Krieg und den E-Commerce-Krieg‍[1] erlebte, ist das E-Commerce-Geschäft entstanden die Monetarisierung des Internetverkehrs außer Werbung. Ein weiterer strategischer Höhepunkt außerhalb des Modells. Während der „Double Eleven“-Periode im Jahr 2013 startete Autohome einen Autokaufservice und betrachtete die Transaktionsverknüpfung als wichtige Entwicklungsrichtung[2]. In der Anfangsphase des Geschäfts besteht die technische Anforderung darin, die Machbarkeit des Produkts schnell zu iterieren und online zu überprüfen. Während die täglichen Geschäftsanforderungen erfüllt werden, hat das Nachdenken über die technische Architektur nicht aufgehört. Unter Berücksichtigung der Skalierbarkeit des zukünftigen E-Commerce-Systems und unter Bezugnahme auf das Technologiesystem von Alibaba in der Branche begannen wir 2014 mit der Entwicklung des Technologie-Stacks, wechselten schrittweise vom .NET-System zum Java-System und schlossen die gesamte Anwendungsumschaltung ab 30. Mai 2015. Start der kompletten Online-Auto-Shopping-Plattform Car Mall . Microservice-Phase Mit der rasanten Entwicklung des E-Commerce-Geschäfts ist die Zahl des technischen Personals gestiegen. Bis 2016 bestand das technische Team aus Hunderten von Mitarbeitern. Der Schmerz einer monolithischen Architektur kommt direkt zum Vorschein. Bei einem Front-End-Mall-Git-Projekt werden fast 30 Maven-Unterprojekte parallel entwickelt, wenn es häufig zu Konflikten bei der Codezusammenführung kommt, wenn Anforderungen online abwarten Wenn SQL- und andere Probleme auftreten, haben sich die Entwicklungseffizienz und die Systemstabilität des gesamten Systems verschlechtert. Derzeit steht die Systemunterstützung vor großen Herausforderungen und die Systemarchitektur muss aktualisiert und weiterentwickelt werden. Wir begannen mit der Entwicklung einer verteilten Strategie und teilten das ursprüngliche Einzelsystem in mehrere zentralisierte Systeme mit hoher Kohäsion und geringer Kopplung auf. Das heißt, das aktuelle User Center, das Product Center, das Promotion Center, das Coupon Center und das Merchant Center können unabhängig voneinander entworfen, unabhängig empfangen und unabhängig freigegeben werden. Die gesamte F&E-Effizienz und Systemstabilität wurden verbessert. Schritte. Zu diesem Zeitpunkt haben wir den Aufbau des Millionen-Level-Produktsystems [3], des Bestellsystems [4] und des Gutscheinsystems [5] zur Unterstützung des Automobil-E-Commerce technisch abgeschlossen und die Cloud-Migration aller Anwendungen abgeschlossen [ 6] und Automatisierung Testplattformbau[7]. Gleichzeitig haben wir verschiedene Geschäftsmodelle untersucht, wie das E-Commerce-Modell für selbst betriebene Fahrzeuge, das Modell der offenen Plattform, das B2B2C-Modell, das Angebotsmodell, das Beratungsmodell, das TPCC-Modell und den parallel importierten Autoverkauf. Stammdatenphase Die Geschwindigkeit der E-Commerce-Entwicklung ist sehr hoch. Bis 2019 verfügt das Unternehmen bereits über eine Vielzahl von Online-Transaktionsmodellen, wie z. B. Reisen, Autoprodukte und After-Market-Services, Punkteeinlösung usw . Basierend auf der Entwicklungsstrategie beschloss das Unternehmen, eine E-Commerce-Mittelplattform aufzubauen. Einerseits geht es darum, die hochwertigen Produktressourcen und Betriebsressourcen des Unternehmens zu konzentrieren, um eine einflussreiche vertikale E-Commerce-Handelsplattform zu schaffen Andererseits geht es auch darum, technische Ressourcen angemessen zu verwalten und zu kontrollieren und das E-Commerce-System der Einheit zu verwirklichen. Vor diesem Hintergrund übernahm mein Team die Aufgabe, eine E-Commerce-Mittelplattform aufzubauen. Da die Geschäftsformen und technischen Architekturen der einzelnen Systeme sehr unterschiedlich sind, bestand das erste Problem darin, die Integration von Klassensystemen zu erreichen. Dazu haben wir einerseits damit begonnen, uns mit dem aktuellen Stand von Handelssystemen in verschiedenen Geschäftsszenarien vertraut zu machen, andererseits denken und diskutieren wir auch über technische Lösungen. Am Ende haben wir uns für die Lösung entschieden, die „auf Datennormalisierung basiert, standardisierte Middle-End-Dienste bereitstellt und System für System von unten nach oben integriert“. Datennormalisierung Daten sind das Kernkapital des Unternehmens. In jedem System, insbesondere in Handelssystemen, haben Daten oberste Priorität. Einerseits kann der Aufbau von Stammdaten das Datenmodell vereinheitlichen und Systembarrieren abbauen; andererseits kann er auch eine operative Datenanalyse durch zentralisierte Daten durchführen und eine Grundlage für Geschäftsentscheidungen bieten der Stammdaten als erster Schritt der Systemintegration. Im Transaktionsprozess werden die wichtigsten Daten in den vier Feldern Händler, Produkte, Bestellungen und Werbemaßnahmen konzentriert. Ausgehend von der aktuellen Situation der Transaktionsszenarien des Unternehmens abstrahieren wir die Stammdaten in diesen vier Feldern und modellieren sie möglichst einheitlich für die meisten Handelsszenarien geeignet. Das Folgende ist ein schematisches Diagramm der Kerndatenmodellstruktur der Auftragsstammdaten: Nach Abschluss des einheitlichen Datenmodells besteht der nächste Schritt darin, die vorhandenen heterogenen Daten in die Hauptdatenbank zu importieren. Wir verwenden die Lesedatenbank binlog Der anfängliche Datensynchronisierungsimport wird durch Datenverarbeitung (MySQL, SQLServer) abgeschlossen, was auch die schnellste und am wenigsten aufdringliche Lösung für das Unternehmen darstellt. API-Standardisierung Nach Abschluss der Stammdatenkonstruktion besteht der nächste Schritt darin, mit der API-Standardisierungskonstruktion zu beginnen, die als der Nerv des Systems angesehen werden kann -Qualitätssystem und Vereinheitlichung Die API realisiert bis zu einem gewissen Grad auch die Schließung des Systems. Zu diesem Zweck folgen wir dem Prinzip der Einzelverantwortung, differenzieren nach Feldern, klären Grenzen und atomisieren alle zugrunde liegenden API-Funktionen, um vorgelagerten Benutzern die flexible Zusammenstellung von APIs zu erleichtern, um die Geschäftslogik zu vervollständigen. Gleichzeitig vereinheitlichen wir die Parameterstruktur von Die API und die Struktur der Antwortergebnisse ermöglichen eine einheitliche Verwaltung und Kontrolle. API-Lese- und Schreibumschaltung Bei einer standardisierten API ist es für Geschäftsparteien selbstverständlich, sie zu verwenden, um den Wert der API widerzuspiegeln. Um zu verhindern, dass der Schritt zu groß wird, verwenden wir sie auch Je nach Bedeutung und Größe des Geschäfts umfasst die schrittweise Lösung das Aufrufen und Wechseln von Unternehmen zu Unternehmen. Dies scheint ein sehr vernünftiger Schritt zu sein, bringt aber auch viele Probleme während des tatsächlichen Ausführungsprozesses mit sich Wenn Lesen und Schreiben stark voneinander abhängig sind, springt der Benutzer beispielsweise sofort nach der Bestellung zu den Bestelldetails, um die Bestellung anzuzeigen. Wenn der Schreib-API-Schalter noch nicht abgeschlossen ist, werden die Daten über die Lese-API gelesen wird aufgrund der Verzögerung der Datensynchronisierung fehlschlagen. Derzeit gibt es keine Möglichkeit, stufenweise zu lesen und dann zu schreiben. Die beste Methode besteht darin, gleichzeitig zwischen Lesen und Schreiben zu wechseln. 2) Die Methode mit den geringsten Auswirkungen auf den Geschäftswechsel ist natürlich mit den Parametern und Rückgabeergebnissen der ursprünglichen Schnittstelle kompatibel. Wenn wir die Geschäftsseite dazu zwingen, gemäß unserer Standard-API zu wechseln, führt dies unweigerlich zu Wechselkosten und unnötigen negativen Auswirkungen auf die geschäftliche Seite. Zu diesem Zeitpunkt müssen wir natürlich einige Kompromisse aus der Sicht der anderen Partei eingehen. Die Methode, die wir anwenden, besteht darin, der Standard-API eine Anpassungsschicht für die Konvertierung alter und neuer Protokolle hinzuzufügen, sodass die Geschäftspartei nur den Domänennamen und die angeforderte URL ändern muss und die andere Logik unverändert bleibt, wodurch die Maximierung erreicht wird Freundlich gegenüber der Geschäftsseite. 3) Da die zugrunde liegenden APIs, die wir bereitstellen, alle atomar sind, ist das Front-End in tatsächlichen Szenarien, insbesondere in Projekten, bei denen das Front-End und das Back-End getrennt sind, nicht bereit, die Schnittstelle mehrmals aufzurufen, um das gleiche Ergebnis zu erzielen , wir sind auch Eine Fassadenschicht wird dem Backend hinzugefügt. Basierend auf der zugrunde liegenden atomaren API wird der Außenwelt eine API bereitgestellt, die dem Geschäftsszenario entspricht und mäßig mit der differenzierten Schnittstellenlogik kompatibel ist. 4) Das Umschalten zwischen Lesen und Schreiben kann nicht über Nacht erfolgen. Da alle API-Eingänge von uns bereitgestellt werden, wird es zwangsläufig zu Szenarien kommen, in denen wir einen Routing-Mechanismus verwenden Die Routing-Schicht leitet verschiedene Standorte weiter und alle APIs sind für den Aufrufer transparent. 5) Im eigentlichen API-Wechselprozess gibt es ein besonderes Szenario. Da das System am Ende integriert werden muss, ist das Erzwingen des API-Wechsels für die Funktionen, die später integriert werden sollen, tatsächlich eine Verschwendung von Ressourcen, sodass wir auch dem Zeitplan voraus sind Nachdem Sie eine Vorabentscheidung getroffen haben, können Sie einen Wechsel mäßig vermeiden und warten, bis die Funktionen integriert sind, bevor Sie die Gesamtfunktionen wechseln. Systemfunktionsintegration Nach Abschluss der API-Lese- und Schreibumschaltung haben die auf den Stammdaten basierenden Funktionen die Aggregation grundsätzlich abgeschlossen. Zu diesem Zeitpunkt ist es notwendig, die allgemeinen Funktionen systematisch zu vereinheitlichen, wie zum Beispiel: einheitliche Händlerverwaltung Backend, einheitlicher Betrieb Backend, einheitliche C-End-Transaktionserfahrung usw. Der Zweck der einheitlichen Integration auf Systemebene besteht darin, Benutzern eine einheitliche Bedienoberfläche zu bieten und die Professionalität der Plattform widerzuspiegeln. Im Prozess der Systemintegration haben wir das Prinzip der „Fällung von Gemeinsamkeiten und des Ausgleichs von Unterschieden“ übernommen. Für diese gemeinsamen Funktionen wie Produktfreigabe, Bestellliste und andere Funktionen werden wir die gemeinsamen Funktionen abstrahieren und eine einheitliche Einheit bereitstellen Die Bedienoberfläche erfüllt die Nutzungsanforderungen verschiedener Geschäftsparteien. Für Funktionen, die nur für die Geschäftsseite gelten, empfehlen wir der Geschäftsseite, diese zu implementieren. Für diejenigen Funktionen, die noch keine allgemeinen Fähigkeiten bilden können, aber in Zukunft zu allgemeinen Fähigkeiten werden können, werden wir dem MVP-Prinzip folgen und den schnellsten Weg nutzen Implementieren Sie kleine Versionen online, mit der Iteration des Geschäfts wird die Funktionsausfällung kontinuierlich realisiert. Während des gesamten Systemintegrationsprozesses werden bei der Integration der ursprünglichen Systemfunktionen zwangsläufig neue Anforderungen auftreten. Angesichts dieses Szenarios besteht unser Ansatz darin, das neue und das alte System gleichzeitig zu entwickeln, was die Integration neuer Systeme tatsächlich in die Höhe treibt Einerseits hat es keinen Einfluss auf die Geschäftsentwicklung und führt nicht zu einer Stagnation des Geschäfts aufgrund der technischen Integration. Andererseits können mögliche Probleme im neuen System durch den Vergleich des alten und des neuen Systems gefunden werden Dies ist auch die beste Möglichkeit, die Funktionalität des neuen integrierten Systems zu überprüfen. Nach Abschluss des Großteils der Systemintegrationsarbeiten waren die zentralen E-Commerce-Transaktionsverbindungen betriebsbereit und wurden einer langfristigen Online-Verifizierung unterzogen, vom Händlereintrag über die Produktfreigabe, die Produktanzeige, die Auftragserteilung, die Zahlung, die Vertragserfüllung bis hin zum Kundendienst Bis zur endgültigen Abwicklung werden auch während des Prozesses aufgetretene Probleme nach und nach gelöst. Zu diesem Zeitpunkt haben wir die Integration der drei wichtigsten Handelssysteme im Unternehmen abgeschlossen und das architektonische Upgrade des Flash-Sale-Systems der E-Commerce-Plattform [8] sowie das strukturelle Upgrade des Coupon-Systems zur Unterstützung von 818 durchgeführt Party und Double 11 in den Jahren 2020-2021, Double 12 und andere Großveranstaltungen wie Flash-Sales und Coupon-Ausgabeszenarien. Darüber hinaus erforschen wir aktiv die Theorie und Branchenpraxis des domänengesteuerten Modells DDD und haben es bei der Rekonstruktion des Rechnungsdatenbanksystems[9] implementiert, das auch technische Unterstützung für nachfolgende Upgrades der Plattformarchitektur bietet. Phase der Plattformarchitektur Während sich das E-Commerce-Geschäftszentrum weiterhin dem Geschäft „annähert“, haben auch die Abstraktions- und Konstruktionsschwierigkeiten des Systems exponentiell zugenommen, und es sind eine Reihe neuer Probleme aufgetreten: 1) Mit dem Ende des Bauprojekts der mittleren Plattform und der Evakuierung des Personals hat die mittlere Plattform des E-Commerce die Logik so vieler Geschäftsbereiche integriert, und der Code ist mit einer großen Anzahl bedingter Beurteilungen gefüllt Die Entwicklungskosten Die Kosten für die Testregression jeder Nachfrageiteration sind sehr hoch. Wie kann die Logik zwischen verschiedenen Unternehmen isoliert und die Kopplung zwischen Unternehmen verringert werden? 2) Wie können die gemeinsamen Fähigkeiten mehrerer Geschäftsbereiche, die mit der E-Commerce-Geschäftsplattform verbunden wurden, abstrahiert werden, um Doppelkonstruktionen zu vermeiden? 3) Wenn ein neues Unternehmen an das E-Commerce-Business-Center angeschlossen wird, wie kann es schnell aufgebaut und auf der Grundlage bestehender Fähigkeiten und Lösungen gestartet werden, um eine schnelle Geschäftswiederholung und Innovation zu unterstützen? 4) Wie können wir mit technischen Mitteln dazu beitragen, die Effizienz der täglichen Arbeit im Produktbetrieb zu verbessern? Zusammenfassend ist es besonders wichtig, die gemeinsamen Fähigkeiten der Geschäftsbereiche sowie das wiederverwendbare Design und die Implementierung gemeinsamer Fähigkeiten in der E-Commerce-Business-Middle-Plattform während des Aufbauprozesses zu abstrahieren Um die mittlere Plattform zu schaffen, spielt der Bau eine Rolle bei der Kostensenkung und Effizienzsteigerung im Entwicklungsprozess von Unternehmen. Die Systemarchitektur muss aktualisiert werden, was zur Plattformarchitekturstufe führt. Plattformarchitektur-Praxis Was ist Plattformarchitektur? Es ist notwendig, die Grundfunktionen von den charakteristischen Diensten jeder Geschäftspartei zu trennen und die Logik zwischen den Diensten zu isolieren. Der Kern der Plattformisierung ist die Offenheit der abstrakten Geschäftsmodellierung und der Systemarchitektur. Die Geschäftsabstraktion löst 80 % der allgemeinen Probleme und die Offenheit der Systemarchitektur löst 20 % der personalisierten Probleme. Nachdem wir uns auf die „Modern Enterprise Architecture White Paper“-Lösung von ThoughtWorks[10] und die Middle-End-Lösungen der Internetunternehmen der Branche Meituan[11] und Youzan[12] bezogen haben, haben wir ein passendes Zuhause gegeben Appliance-Lösung für E-Commerce-Plattformen: Verwenden Sie domänengesteuerte Modellierung, um die gemeinsamen Funktionen mehrerer Geschäftsbereiche im E-Commerce-Geschäft zu abstrahieren und Erweiterungspunkte zu reservieren, und verwenden Sie dann Service-Orchestrierung, um gemeinsame Funktionen zu kombinieren. Das Prinzip ist wie in der Abbildung dargestellt: Jedes im E-Commerce-Geschäft laufende Unternehmen kann wie folgt verstanden werden: Geschäftsidentität + Geschäftsprozess + Regeln. Der Geschäftsprozess wird durch Prozessservice-Orchestrierung und der Erweiterungspunkt durch Erweiterung realisiert Punktmechanismus. Im gesamten Transaktionsprozess sind die Eingabe von Händlern und die Produktfreigabe auf der B-Seite relativ häufig. Die Hauptprozessunterschiede verschiedener Unternehmen spiegeln sich in der Auftragsabwicklung vor und nach der Zahlung wider Aus diesem Grund liegt der Kern der gesamten Lösung im Design der Auftragsplattformarchitektur. Wie im Bild gezeigt: Die gesamte Architektur der Bestellplattform ist von unten nach oben in vier Schichten unterteilt: Infrastrukturschicht: Stellt Middleware wie Speicher, Messaging, RPC usw. bereit. Basisdienstschicht: Nach Domäne organisierte Basisdienste, und Domänendienste bieten Erweiterungspunkte für Unterschiede in verschiedenen Unternehmen. Geschäftsfähigkeitsschicht: Verbinden Sie verschiedene Domänendienste, um Geschäftsfähigkeiten zu bilden, die extern genutzt werden können, z. B. Bestellung, Zahlung usw. Geschäftsprozessschicht: Ordnet Geschäftsfunktionen an, bildet Bestelltransaktionsprozesse und schließt Bestelltransaktionsprozesse ab. Geschäftsschicht: Entwickeln Sie eine Geschäftsidentität, eine Erweiterungspunktimplementierung und eine Geschäftsprozesskonfiguration, um unterschiedliche Geschäftsunterschiede zu erzielen. Der gesamte Praxisprozess zur Aktualisierung der Bestellplattformarchitektur lässt sich wie folgt zusammenfassen: Unternehmensidentifikation Das Konzept der Geschäftsidentität wurde erstmals von Alibaba vorgeschlagen, als die Geschäftsplattform gleichzeitig Dienstleistungen für verschiedene Unternehmen bereitstellte. Es muss in der Lage sein, die Geschäftsidentitätselemente jeder Geschäftsdienstanfrage zu unterscheiden, um differenzierte und personalisierte Dienste bereitzustellen. Daher ist es notwendig, die Identitäten und Merkmale jedes Geschäfts des Unternehmens zu modellieren und zu unterscheiden Geschäftsidentität. Die Unternehmensidentität ist einzigartig und ähnelt einer ID-Nummer und muss im gesamten Unternehmen eindeutig sein. Mit der Geschäftsidentität kann das Geschäftszentrum den Geschäftsprozess und die Geschäftsregeln abstrahieren und Service-Routing und Geschäftsüberwachung basierend auf der Geschäftsidentität implementieren. Zweitens ähnelt die Geschäftsidentität dem Konzept der Mandanten im SAAS-System. Verschiedene Geschäftsparteien verwenden Geschäftsidentitäten, um Datenberechtigungen im Middle Office zu isolieren. Dadurch wird sichergestellt, dass die Vorgänge jedes Unternehmens nur die Daten ihres eigenen Geschäftsteils sehen können. Im Bereich des Automobil-E-Commerce beispielsweise abstrahieren wir die Unternehmensidentität durch drei Dimensionen: Menschen, Waren und Orte. Die menschliche Dimension umfasst, ob Sie eine Mitgliedschaft haben, ob Sie ein zertifizierter Autobesitzer sind, welche Mehrwertdienste aktiviert wurden usw.; die Warendimension umfasst die Warenart (komplettes Fahrzeug, physische Ware, virtuelle Ware usw.); Lieferart (Abschreibung, Umtausch, 4S-Ladenlieferung) usw.; die Abmessungen des Feldes umfassen Online-Bestellung, Offline-Bestellung, in welchem ​​Online-Einkaufszentrum die Bestellung aufgegeben wurde, in welchem ​​Liefergeschäft die Bestellung aufgegeben wurde, die Quelle der Produktlieferkanal usw. Sobald anhand dieser Dimensionen eine eindeutige Geschäftsidentität ermittelt wurde, wird der Geschäftsprozess für jede Transaktion bestimmt. Service-Orchestrierung Das E-Commerce-Businesscenter übernimmt die Microservice-Architektur als Ganzes, und das gesamte E-Commerce-System ist in Merchant Center, User Center, Commodity Center, Promotion Center, Transaction Center und Fulfillment unterteilt Zentrum und Kundendienstzentrum. Jedes Zentrum ist logisch in zwei Schichten unterteilt: Fähigkeiten mit Geschäftsattributen und Basisfähigkeiten ohne Geschäftsattribute. Die Basisfähigkeitsschicht konzentriert sich auf die Entitätsattribute, Verhaltensweisen und Ereignisse des Domänenmodells, die sich bei der Anpassung der Geschäftsanforderungen nicht ändern. Sie konzentriert sich auf branchenübliche Verhaltensweisen, konvergiert Geschäftsmodelle und gewährleistet die Stabilität grundlegender Dienste. Fähigkeiten mit Geschäftsattributen werden auf der Basisfähigkeitsschicht durch technische Mittel wie Servicekomposition und Prozessorchestrierung aufgebaut, um geschäftsorientierte Lösungen zu bilden und den Wandel von der Geschäftsgemeinsamkeit zur Personalisierung abzuschließen. Es gibt zwei gängige Ansätze: Der eine besteht darin, harte Codierung zu verwenden. Da die Logik verschiedener Geschäftsbereiche immer weiter zunimmt, werden die von den einzelnen Geschäftsfunktionen geforderten Grundfunktionen kompliziert und komplex, was ihre Konfiguration und flexible Implementierung erschwert. Wenn sich Anforderungen ändern, ist es für Tester schwierig, den Umfang der Auswirkungen von Änderungen einzuschätzen, und der Kostenzyklus von Regressionstests ist lang, was es schwierig macht, eine wirklich agile Entwicklung und schnelle Geschäftsreaktionen zu erreichen. Die zweite besteht darin, die Service-Orchestrierung zu verwenden. Stellen Sie Services durch Service-Orchestrierung vorhandener Microservices zusammen und geben Sie dann die von der Rezeption benötigten Informationen auf einmal zurück. Die Fähigkeiten verschiedener Geschäftsbereiche führen unterschiedliche Prozesse aus. Durch das grafische, XML- und JSON-Orchestrierungs-Framework können der Prozess klar gestaltet und Codedetails abgeschirmt werden. Es besteht keine Notwendigkeit, im Detail auf die Vorteile der Dienstaufteilung einzugehen. Um jedoch einen geschäftlichen Nutzen zu erzielen, kommt es nicht auf die Fähigkeiten eines einzelnen Dienstes an, sondern auf die Koordinierung aller Dienste, um den Erfolg des End-to-End-Geschäfts des Unternehmens sicherzustellen Verfahren. Die Business-Middle-Plattform ist die Integrationsplattform für das Unternehmensgeschäft. Die Integrationstechnologie muss die Anwendungen und Ressourcen, aus denen der Prozess besteht, lose koppeln. Andernfalls wird die Logik des Prozesses fest in eine bestimmte Technologieplattform codiert, und es kann zu Änderungen kommen Dies ist kostspielig und beeinträchtigt somit das gesamte Ziel der Wiederverwendung von Geschäftsprozessen. Service-Orchestrierungs-Framework Im Bereich der Service-Orchestrierung gibt es bereits viele industrielle Lösungen. Wir verweisen auf API-Gateway-basierte Service-Orchestrierung [13], Workflow-System-basierte Orchestrierungs-Frameworks Flowable und Activiti [14] und Netflix Conductor[16] und Zeebe[17] sind Orchestrierungs-Frameworks für Microservice-Architekturen. Durch die Analyse der technischen Prinzipien haben wir festgestellt, dass sie alle bestimmte Mängel aufweisen und nicht auf die Service-Orchestrierung des mittleren E-Commerce-Geschäfts angewendet werden können. Am Ende haben wir Apache Camel [18] als zugrunde liegende Engine ausgewählt der Service-Orchestrierung zum zweiten Mal. Apache Camel wurde 2007 geboren. Um 2009 wurde es zu einem Top-Level-Apache-Projekt und wurde in Apache Camel umbenannt. Die neueste Version ist 3.0. Der Vorteil von Apache Camel besteht darin, dass es seit seiner Veröffentlichung über mehr als 300 Erweiterungskomponenten verfügt; der Erweiterungsmechanismus ist außerdem äußerst praktisch und flexibel und löst Anwendungsintegrationsprobleme durch sofort verfügbare Best Practices Basierend auf einer ereignisgesteuerten Architektur weist es eine gute Leistung und einen guten Durchsatz auf [19]. Das Folgende ist ein einfaches Beispiel für die Orchestrierung eines Serviceprozesses: Das Business Middle Office nutzt Service-Orchestrierungstechnologie. Einerseits kann es Transaktionsfähigkeiten automatisch als visuelle Darstellung von Komponenten identifizieren, um andererseits eine Fähigkeitskarte zu erstellen Die Orchestrierung von Serviceprozessen durch Drag & Drop erstellt schnell den gesamten oder einen Teil des Transaktionsprozesses, der für das Unternehmen geeignet ist, ähnlich wie bei Bausteinen, indem grundlegende Komponenten wiederverwendet und flexibel angepasst werden, wodurch die Wiederverwendung von E-Commerce auf Unternehmensebene realisiert wird Fähigkeiten zu erweitern, Entwicklungskosten zu sparen und das Unternehmen schnell zu stärken. Erweiterungspunkt-Framework Der vollständige Name des Erweiterungspunkts lautet Service Provider Interface, kurz SPI. Dabei handelt es sich um eine Reihe von Mechanismen, die von Java zum Laden und Ausführen von Schnittstellenimplementierungsklassen von Drittanbieter-Erweiterungen bereitgestellt werden. Sie werden im Allgemeinen in Szenarios zum Ersetzen von Komponenten und zur Erweiterung des Frameworks verwendet. SPI trennt Serviceschnittstellen von Serviceimplementierungen, um eine Entkopplung zu erreichen und die Skalierbarkeit der Anwendung zu verbessern. In der Programmierung wird schnittstellenorientierte Programmierung zwischen Modulen ohne spezifische Referenzen auf Implementierungsklassen verwendet, und Anwendungs-Plug-Ins werden durch dynamisches Laden von Implementierungsklassen erreicht. Das COLA-Framework ist ein Erweiterungspunkt-Framework für die Anwendungsarchitektur, das von Alibaba-Technikexperten vorgeschlagen wurde [20]. Die Erweiterung des COLA-Frameworks wird durch Annotationen implementiert. Die Annotationen der Erweiterungserweiterung verwenden drei Attribute: Anwendungsfall (useCase), Geschäft (bizId) und Szenario (szenario), um die Identität zu identifizieren. Die Verwendung der Erweiterungspunkte des COLA-Frameworks kann die logische Isolierung verschiedener Geschäftsidentitäten auf Codeebene unterstützen, da unterschiedliche Logik in verschiedenen Implementierungsklassen verstreut ist, was dem Öffnungs- und Schließprinzip des Softwaredesigns entspricht. Wenn der Spring-Kontext der Anwendung initialisiert wird, beginnt das COLA-Framework, Beans mit Erweiterungsanmerkungen für die Erweiterungspunktregistrierung zu scannen, die in einer Map-Struktur gespeichert sind. Der Schlüssel ist eine Zeichenfolgenverkettung aus useCase, bizId und Szenario, und der Wert ist Bohne. Zur Laufzeit wird die Implementierungsklasse des Erweiterungspunkts über die Geschäftsidentität lokalisiert und dann wird die vom Erweiterungspunkt implementierte Logik ausgeführt. Bei der Suche nach der Erweiterungspunktimplementierung wird das dreistufige Routing unterstützt. Zunächst wird der Erweiterungspunkt gemäß dem UseCase+bizId+scenario-Standardwert gesucht Es wurde nicht gefunden, es wird gemäß dem Standardwert von useCase + bizId + Szenario gefunden. Das spezifische Prinzip ist in der Abbildung dargestellt: Für einfache Geschäftsszenarien gibt es nicht viele nicht funktionale Anforderungen an eine hohe Skalierbarkeit und Geschäftsisolation des Anwendungssystems. Da jedoch dasselbe Anwendungssystem mehr Unternehmen unterstützt und Geschäftsszenarien komplexer werden, ist es notwendig, einheitliche Erweiterungslösungen auf Architekturebene bereitzustellen, um die sich ändernden Geschäftsregeln zu festigen. Dies trägt nicht nur zur Vereinheitlichung technischer Spezifikationen bei, sondern reduziert auch die harte Codierung IF-ELSE, Strategiemodus usw. werden durch die Komplexität des Verständnisses und der Konsistenz der Spezifikationen aufgrund inkonsistenter Entwicklerebenen verursacht. Durch den Erweiterungspunktmechanismus kann das Business Center verschiedene Dienste auf der Geschäftsidentitäts- und Framework-Ebene verwalten, z. B. SAAS-Verwaltungsmieter. Verschiedene Geschäftsidentitäten können vordefinierte Erweiterungspunkte in verschiedenen Szenarien erweitern. Alibabas Business Middle Office basiert ebenfalls auf der Idee von Erweiterungspunkten und realisiert die Trennung und Entkopplung von Kerngeschäftslogik und technischen Details, sodass die gemeinsame Geschäftseinheit Hunderte von Geschäftsbereichen innerhalb der Gruppe unterstützen kann. Beispiele für Service-Orchestrierung + Erweiterungspunktanwendung Nach der Überprüfung der Funktionen wurden die Szenarien des E-Commerce-Transaktionssystems klassifiziert. Zunächst wurden Knoten mit geringem Benutzerbewusstsein und minimalen Auswirkungen auf Benutzer, selbst wenn Probleme auftraten, für Rekonstruktionsversuche ausgewählt B. unbezahlte Bestellungen, werden mit der Zeit geschlossen und der Benutzer storniert die Bestellung. Nehmen Sie als Beispiel das Szenario, in dem ein Benutzer eine Bestellung storniert. Vor der Änderung besteht die Logik für die Stornierung von Bestellungen durch Benutzer darin, den Bestellstatus in den Status „Storniert“ zu ändern und dann denselben Prozess auszuführen -codiert. Der Pseudocode ist wie in der Abbildung dargestellt: Nach der Änderung wurde er sorgfältig entsprechend den Merkmalen jedes Unternehmens angeordnet. Wenn das Gebrauchtwagengeschäft beispielsweise keine Gutscheine verwendet, Dann ist dieser Link nicht erforderlich. Im Hinblick auf die allgemeine Fähigkeit von Punkten wurden die Wanlitong-Punkte erweitert. Der Pseudocode ist wie in der Abbildung dargestellt: Das Hotel- und Flugticketgeschäft des Reisegeschäfts verfügt nicht über das traditionelle Konzept des Warenbestands, sodass keine Notwendigkeit mehr besteht, Warenbestände zurückzugeben, sondern dies Abstrahieren Sie eine neue allgemeine Funktion: Stornieren Sie Lieferantenbestellungen und legen Sie zwei Erweiterungspunkte für die Stornierung von Hotellieferantenbestellungen und die Stornierung von Flugticketlieferantenbestellungen fest. Der Pseudocode ist wie in der Abbildung dargestellt: Der Anwendungseffekt des gesamten Systems ist offensichtlich und spiegelt sich hauptsächlich in der Leistungsverbesserung und der Verbesserung der menschlichen Effizienz wider. Die Leistungsverbesserung spiegelt sich hauptsächlich in der verkürzten Reaktionszeit des Systems wider. Der TP99-Verbesserungsprozentsatz der Produktionsumgebung der Schnittstelle zum Stornieren von Bestellungen nach einer Änderung beträgt etwa 30 %. Die Verbesserung der menschlichen Effizienz spiegelt sich hauptsächlich im Vergleich der Zeit wider, die zum Testen der Stornierung von Bestellungen und des Hinzufügens neuer Prozessknoten benötigt wird. Vor der Änderung sind die Codes zwischen den Geschäftsprozessen gekoppelt, um neue Knoten hinzuzufügen Testen der vorherigen Unternehmen Nach der Änderung ist es nicht erforderlich, für jedes Unternehmen einen Regressionstest durchzuführen. Geschäftskonfiguration In der Praxis der Plattformarchitektur extrahieren wir einheitlich die Kernkonfigurationen, die sich auf den Geschäftsfluss auswirken, und konfigurieren Attributwerte entsprechend der Geschäftsidentität, um sicherzustellen, dass die Standards der gesamten Transaktionsprozessverbindung stimmen Vereinheitlicht und reduziert den Bedarf an Transaktionen. Der Linkcode des Transaktionskerns wird häufig geändert, und verschiedene Unternehmen können flexibel an verschiedenen Knoten im selben Transaktionsprozess basierend auf unterschiedlichen Attributwerten umgeschaltet werden. Zum Beispiel: ob das Produkt automatisch in den Ressourcenpool verschoben wird, ob für die Bestellung ein Personalausweis erforderlich ist, ob ein Hinweis gesendet wird, wenn die Zahlung erfolgreich ist, ob der Empfang seit mehr als N Tagen nicht bestätigt wurde, ob Der Empfang wird automatisch bestätigt usw. Alle Konfigurationselemente werden durch die Konfigurationsverwaltung im Hintergrund vereinheitlicht. Darüber hinaus haben wir für alle Metadaten in der E-Commerce-Plattform, einschließlich Geschäftsidentitäten, auch die Verwaltung über das Konfigurationsmanagement-Backend vereinheitlicht und eine einheitliche API zur Bereitstellung externer Abfragedienste bereitgestellt. Entwicklungstools Ausgehend von den mehrdimensionalen Aspekten von Wirtschaft und Technologie entwickeln wir verschiedene praktische und praktische Gadgets für häufige Geschäftsprobleme oder technische Probleme, die bei der täglichen Arbeit auftreten, um die Arbeitseffizienz zu verbessern und Probleme schnell zu lösen . Positionierungs- und andere Effekte, wie z. B. Tools zur Nachrichtenverteilung und zum schnellen Berechnen von Produktpreisen und Tools zur Cache-Verwaltung; Da das Bewusstsein aller für den Werkzeugbau immer weiter zunimmt, tauchen immer wieder solche kleinen Werkzeuge auf und werden zu einem unverzichtbaren Werkzeugkasten für F&E-Personal zusammengefasst. Datenvisualisierung Die Leistungsindikatoren, Ressourcenauslastungsindikatoren, das Anrufvolumen und andere systemdimensionale Indikatoren des E-Commerce-Systems können über die Cloud-Plattform des Unternehmens einheitlich überwacht werden. Auf die gleiche Weise benötigen wir Bereitstellung einheitlicher Geschäftsdaten. Visuelle Tools bieten den Geschäftsparteien eine Referenz für relevante Entscheidungen. Zu diesem Zweck haben wir ein Großbildsystem zur Auftragsvisualisierung entwickelt, das einen Echtzeit- und Offline-Ansatz nutzt. Mit diesem System können Änderungen des Auftragsvolumens in Echtzeit aus mehreren Dimensionen wie Geschäftsbereich, Auftragsstatus und Region überwacht werden. Wenn die Schwankung des Auftragsvolumens innerhalb eines festgelegten Zeitraums unseren vorkonfigurierten Schwellenwert überschreitet, wird eine DingTalk-Nachricht gesendet, um den Geschäftspartner umgehend über die Aufmerksamkeit zu informieren. Darüber hinaus führen wir für Offline-Daten auch eine statistische Analyse von Daten aus mehreren Dimensionen nach Tag, Woche und Monat durch und senden diese schließlich in Form von E-Mail- und Office-APP-Nachrichten an die Geschäftspartei. Der Zweck dieser Mittel besteht darin, die visuelle Verwaltung von E-Commerce-Daten zu realisieren und Geschäftsanwendern komfortablere Tools für die umfassende Verwaltung und Kontrolle des E-Commerce-Geschäfts bereitzustellen. Wissensanhäufung Das Team, dem ich angehöre, ist ein professionelles Team im E-Commerce-Bereich innerhalb des Unternehmens und hat im Laufe der Jahre viel Erfahrung im Technologie- und Produktbetrieb gesammelt. Während des gesamten Aufbauprozesses der E-Commerce-Mittelplattform haben wir diese Erfahrungen und Lösungen für alltägliche Probleme auch als kontinuierliche Anhäufung von Reichtum genutzt. In der Vergangenheit haben wir Dokumentenverwaltungstools wie Wiki verwendet, um sie zusammenzufassen. Um aus diesem Wissen einen Mehrwert zu generieren, haben wir auch damit begonnen, ein eigenes E-Commerce-Wissensdatenbanksystem aufzubauen und alle Inhalte, die als Wissensakkumulation verwendet werden können, nach verschiedenen Bereichen in das Wissensdatenbanksystem einzugeben Schnelles Abrufen und Die Positionierungsfunktion kann technischem Personal und Produktbedienungspersonal dienen, das Bewusstsein aller für die Wissensanhäufung weiter schärfen und die Arbeitseffizienz aller verbessern. Epilog Vor zwanzig Jahren wurde das Internet erstmals in Form von Informationen angezeigt, und vor zehn Jahren gab es fast keine Online-Transaktionen, und Verbraucher konnten Produkte auf Taobao, Tmall, kaufen , und JD.com-Vertreter können in Online-Einkaufszentren die Waren kaufen, die sie für Online-Transaktionen benötigen. Heutzutage entstehen ständig verschiedene E-Commerce-Formen, und es hat sich zu einem blühenden Trend entwickelt, beispielsweise dem Content-E-Commerce Xiaohongshu. Interesse an E-Commerce Douyin Kuaishou und Social E-Commerce WeChat Business, Pinduoduo usw., Mitglieds-E-Commerce-Unternehmen Tmall 88vip, JD Plus usw. Diese Online-Transaktionsformulare beweisen voll und ganz, dass E-Commerce ein wichtiger Teil der Monetarisierung des Datenverkehrs im Internetbereich ist und zum Wasser, Strom und Kohle der Internet-Unternehmensinfrastruktur geworden ist. Der Aufbau einer E-Commerce-Mittelplattform ist nicht nur der Aufbau eines technischen Systems, sondern auch ein Prozess der Umgestaltung der Organisationsstruktur. Mit der Zeit wird der Raum für die Wertsteigerung des Middle Office jedoch immer enger. Dies erfordert die bewusste Suche nach Innovationspunkten, das Durchbrechen der Grenzen des bestehenden Systems und das Denken über Grenzen hinweg Nähern Sie sich dem Front-Office-Geschäft, führen Sie aktiv die Erkundung neuer Geschäftsfelder und die Aktualisierung der technischen Architektur durch. Exploring New Retail Bei der vergangenen Untersuchung des Geschäftsmodells des Automobil-E-Commerce haben wir herausgefunden, dass der Hauptschmerzpunkt darin liegt Unfähigkeit, 4S-Geschäfte zu umgehen, um Dienstleistungen anzubieten. In den letzten Jahren sind Tesla und neue inländische Automobilhersteller entstanden. Das aufkommende Direktvertriebsmodell hat die Ökologie des 4S-Vertriebssystems traditioneller Automobilunternehmen auf einen Schlag durchbrochen. So können wir sehen, dass das neue Modell der Online-Autobestellung + Offline-Einzelhandelsmodelle möglich wird. Durch die Aufrüstung der bestehenden Funktionen des E-Commerce-Systems unterstützen Produkte die SKU-Auswahl, Bestellungen unterstützen die Kombinationszahlung und Rückerstattung großer und kleiner Anzahlungen und es wird ein neues Liefersystem hinzugefügt, um Dienstleistungen für das Geschäft mit maßgeschneiderten Autos von Industrieverbänden und Unternehmen bereitzustellen Unterstützung neuer Offline-Automobilgeschäfte. Auch in Zukunft werden wir ein branchengerechtes Floating-Price-Modell für neue Energieoptionen und ein Service-Paket-Modell für optionale Produktpakete schaffen. Architektur-Upgrade Im ursprünglichen Bestellprozess für E-Commerce-Transaktionen sind die externen Dienste so konzipiert, dass sie mit einer relativ kleinen Granularität des Dienstes atomisiert werden , was zu relativ hohen Zugriffskosten für die Geschäftsseite und einer schlechten Benutzererfahrung führt. In Zukunft werden wir die Produktstärke und die betriebliche Effizienz des Unternehmens durch technische Maßnahmen wie das Hinzufügen von BFF-Ebenen, die Rationalisierung der Anrufkette und die Schaffung von E-Commerce-Zugangsgerüsten verbessern.

Das obige ist der detaillierte Inhalt vonEntwicklung der Autohome-E-Commerce-Systemarchitektur und Praxis der Plattformarchitektur. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!