Architekturentwicklung und Designerforschung von Ele.me

Einführung

Ein Industriemodell und schnell produzieren. „Schnell“ steht an erster Stelle und es besteht keine Notwendigkeit, zu viel Energie in die architektonische Gestaltung zu stecken. Erst wenn die Website in die Expansionsphase eintritt, muss sie mehr Energie in die Architektur investieren, um den Datenverkehr der Website zu bewältigen, wenn sie explodiert. Ele.me gibt es seit 8 Jahren und mittlerweile hat das tägliche Bestellvolumen 9 Millionen überschritten. Außerdem verfügen wir über eine relativ vollständige Website-Struktur.

1. Website-Infrastruktur

Zu Beginn haben wir ein Framework verwendet, das die Erweiterung von SOA erleichterte. Wir verwenden das SOA-Framework, um zwei Dinge zu lösen:

1. Arbeitsteilung und Zusammenarbeit

In den Anfängen der Website gab es möglicherweise nur 1 bis 5 Programmierer. Damals war jeder einfach mit der gleichen Sache beschäftigt. Sie alle verstehen die Arbeit des anderen und lösen Probleme oft durch „Anschreien“.

Aber wenn die Anzahl der Personen zunimmt, ist diese Methode offensichtlich nicht durchführbar. Es ist unmöglich, dass eine Person den Code aktualisiert und dann die Codes aller anderen Personen erneut online stellt, oder? Daher müssen wir uns mit der Frage der Arbeitsteilung und Zusammenarbeit befassen.

2. Schnelle Expansion

In der Vergangenheit lag das Bestellvolumen möglicherweise zwischen 1.000 und 10.000. Obwohl es sich verzehnfacht hat, ist das Gesamtvolumen nicht sehr hoch und der Druck auf einer Website ist nicht so groß. Wenn das Bestellvolumen tatsächlich von 100.000 auf 1.000.000 und von 1.000.000 auf 2.000.000 steigt, erhöht sich die Zahl zwar nur um das Zehnfache, stellt aber eine große Herausforderung für die Architektur der gesamten Website dar.

Unser Hintergrund ist, dass wir von 1 Million im Jahr 2014 auf jetzt 9 Millionen gewachsen sind. Das technische Team ist von anfangs mehr als 30 Mitarbeitern auf mittlerweile mehr als 900 Mitarbeiter angewachsen. In dieser Zeit sind Arbeitsteilung und Zusammenarbeit eine große Herausforderung. Die Aufteilung und Integration von Diensten und die Aufteilung und Integration von Teams erfordern ein Rahmensystem, das sie unterstützt. Dies ist auch eine Aufgabe des SOA-Rahmens.

Sehen Sie sich unsere aktuelle Situation an. Die Mitte zeigt unser gesamtes Architektursystem, und die rechte Seite zeigt einige Grundlagen im Zusammenhang mit der Servitisierung, einschließlich grundlegender Komponenten oder Dienste.

Lass uns zuerst über die Sprache sprechen. Unsere ursprüngliche Website basierte auf PHP und wurde dann langsam umgestaltet.

Die Gründer sind allesamt College-Studenten, die ihr eigenes Unternehmen gründen, daher ist Python natürlich eine gute erste Wahl. Bisher ist Python auch eine gute Wahl, aber warum sollten wir auf Java und Go erweitern?

Viele Leute können Python schreiben, aber nicht viele Leute können es wirklich gut. Wenn das Unternehmen wächst, werden mehr Entwickler benötigt. Unter Berücksichtigung der ausgereiften ökologischen Umgebung von Java und des entstehenden Go-Ökosystems haben wir uns schließlich für ein Ökosystem entschieden, in dem Python, Java und Go in mehreren Sprachen koexistieren.

WebAPI führt hauptsächlich einige allgemeine Vorgänge aus, die nichts mit der Geschäftslogik zu tun haben, wie etwa HTTPS-Offloading, Strombegrenzung und Sicherheitsüberprüfung.

Service Orchestrator ist eine Service-Orchestrierungsschicht, die die Protokollkonvertierung interner und externer Netzwerke sowie die Aggregation und Anpassung von Diensten durch Konfiguration realisiert.

Auf der rechten Seite des Architekturdiagramms befinden sich einige Hilfssysteme rund um diese serviceorientierten Frameworks, beispielsweise das Jobsystem zur regelmäßigen Ausführung einer Aufgabe. Wir haben fast 1.000 Dienste. Wie überwachen wir diese Systeme? Es muss also ein Überwachungssystem geben. Als zu Beginn nur mehr als 30 Personen anwesend waren, konnten wir besser zur Maschine rennen, um nach Protokollen zu suchen. Bei mehr als 900 Personen können jedoch nicht alle zentral zur Maschine gehen, um nach Protokollen zu suchen Es ist ein Protokollierungssystem erforderlich. Andere Systeme werden hier nicht einzeln beschrieben.

Rom wurde nicht an einem Tag erbaut, die Infrastruktur ist ein evolutionärer Prozess. Wir haben nur begrenzte Energie. Was sollten wir also zuerst tun?

2. Serviceaufteilung

Wenn die Website größer wird, kann die ursprüngliche Struktur nicht mit der Entwicklungsgeschwindigkeit mithalten. Das erste, was wir tun müssen, ist:

Teilen Sie das große Repo in ein kleines Repo auf, teilen Sie den großen Dienst in kleine Dienste auf und teilen Sie unsere zentralisierten Basisdienste in verschiedene physische Maschinen auf.

Allein die Aufteilung der Dienste dauerte mehr als ein Jahr, was ein relativ langer Prozess ist.

In diesem Prozess müssen wir zunächst eine gute Definition der API erstellen. Denn sobald Ihre API online ist, sind die Kosten für die Durchführung einiger Änderungen recht hoch. Viele Menschen verlassen sich auf Ihre API, und oft wissen Sie nicht, wer auf Ihre API angewiesen ist.

Dann abstrahieren Sie einige grundlegende Dienste. Viele ursprüngliche Dienste sind tatsächlich im ursprünglichen Geschäftscode gekoppelt. Wenn das Geschäft beispielsweise sehr einfach und eng gekoppelt ist, spielt der Code keine Rolle. Wenn jedoch immer mehr Unternehmen expandieren und Zahlungsdienste benötigen, müssen Sie für jedes Unternehmen einen Code erstellen (z. B. eine Zahlungsfunktion). ? Daher müssen wir diese grundlegenden Dienste wie Zahlungsdienste, SMS-Dienste, Push-Dienste usw. extrahieren.

Demontageleistungen scheinen sehr einfach und wenig wert zu sein, aber genau das müssen wir von Anfang an tun. Tatsächlich können in diesem Zeitraum alle vorherigen Architekturen verschoben werden, denn wenn Sie keine architektonischen Anpassungen vornehmen, werden die Menschen nicht sterben, aber wenn Sie die Dienste nicht abbauen, werden die Menschen wirklich sterben.

Die Aufteilung von Diensten muss ein langer Prozess sein, aber tatsächlich ist es ein sehr schmerzhafter Prozess und erfordert viel System-Engineering der unterstützenden Systeme.

3. Freigabesystem

Release ist der größte Instabilitätsfaktor. Viele Unternehmen haben strenge Beschränkungen für Veröffentlichungszeitfenster, zum Beispiel:

• Nur zwei Tage pro Woche zum Posten;
• Absolut nicht am Wochenende gepostet;
• Posten ist während der Hauptgeschäftszeiten absolut nicht gestattet;
• Warte...

Wir haben festgestellt, dass das größte Problem bei der Veröffentlichung darin besteht, dass es nach der Veröffentlichung keinen einfachen ausführbaren Rollback-Vorgang gibt. Wer führt den Rollback-Vorgang durch? Kann das Freigabepersonal ihn durchführen oder ist dafür eine spezielle Person erforderlich? Wenn es sich um einen Verlag handelt, ist der Verlag nicht 24 Stunden am Tag online. Was soll ich tun, wenn es ein Problem gibt und ich niemanden finden kann? Wenn es eine bestimmte Person gibt, die das Rollback durchführt, und es keinen einfachen und einheitlichen Rollback-Vorgang gibt, muss diese Person mit dem Code des Herausgebers vertraut sein, was grundsätzlich nicht möglich ist.

Wir benötigen also ein Veröffentlichungssystem, das einen einheitlichen Rollback-Vorgang definiert. Alle Dienste müssen dem vom Veröffentlichungssystem definierten Rollback-Vorgang folgen.

Es ist eine zwingende Voraussetzung für alle, sich mit dem Veröffentlichungssystem in Ele.me zu verbinden. Alle Systeme müssen mit dem Veröffentlichungssystem verbunden sein. Der Rahmen des Veröffentlichungssystems ist für das Unternehmen tatsächlich sehr wichtig und muss in der ersten Prioritätswarteschlange berücksichtigt werden.

4. Service-Framework

Der nächste Schritt ist das Service-Framework von Ele.me, das ein großes Repo in ein kleines Repo und einen großen Service in einen kleinen Service aufteilt, um unsere Services so unabhängig wie möglich zu machen. Dies erfordert eine Reihe verteilter Service-Frameworks zur Unterstützung.

Das Framework für verteilte Dienste umfasst Dienstregistrierung, Erkennung, Lastausgleich, Routing, Flusskontrolle, Leistungsschalter, Verschlechterung und andere Funktionen, die hier nicht einzeln besprochen werden. Wie bereits erwähnt, ist Ele.me ein mehrsprachiges Ökosystem, einschließlich Python und Java. Unser serviceorientiertes Framework ist ebenfalls mehrsprachig. Dies wird Auswirkungen auf unsere spätere Auswahl einiger Middleware haben, beispielsweise der DAL-Schicht.

5. DAL-Datenzugriffsschicht

Wenn das Geschäftsvolumen zunimmt, wird die Datenbank zum Engpass.

In der Anfangsphase kann die Leistung der Datenbank durch ein Upgrade der Hardware verbessert werden. Zum Beispiel:

• Upgrade auf eine Maschine mit mehr CPUs;
• Ersetzen Sie die Festplatte durch eine SSD oder etwas Fortgeschritteneres.

Aber Hardware-Verbesserungen haben letztendlich eine Kapazitätsgrenze. Darüber hinaus betreiben viele Geschäftspartner die Datenbank direkt, wenn sie Code schreiben. Es gab viele Fälle, in denen die Datenbank explodierte, sobald der Dienst online ging. Nachdem die Datenbank zerstört wurde, gibt es keine andere Möglichkeit, das Unternehmen wiederherzustellen, es sei denn, die Datenbank wird wiederhergestellt.

Wenn die Daten in der Datenbank normal sind, kann das Unternehmen tatsächlich entschädigt werden. Wenn wir also die DAL-Serviceschicht aufbauen, besteht das erste, was wir tun müssen, darin, den Strom zu begrenzen, und andere Dinge können beiseite gelegt werden. Für die Wiederverwendung von Verbindungen verwendet unser Python-Framework dann ein Multiprozess-, Single-Thread- und Coroutine-Modell.

Tatsächlich können nicht mehrere Prozesse eine Verbindung gemeinsam nutzen. Beispiel: 10 Python-Prozesse werden auf einer Maschine bereitgestellt und jeder Prozess verfügt über 10 Datenbankverbindungen. Bei einer Erweiterung auf 10 Maschinen gibt es 1.000 Datenbankverbindungen. Für Datenbanken sind Verbindungen eine sehr teure Sache, und unsere DAL-Schicht muss Verbindungen wiederverwenden.

Bei dieser Verbindungswiederverwendung geht es nicht um die Verbindungswiederverwendung des Dienstes selbst, sondern um die Verbindungswiederverwendung auf der DAL-Schicht. Das heißt, der Dienst verfügt über 1.000 Verbindungen zur DAL-Schicht. Nach der Verbindungswiederverwendung kann die Datenbank nur ein Dutzend Verbindungen aufrechterhalten. Sobald festgestellt wird, dass es sich bei einer Datenbankanforderung um eine Transaktion handelt, hilft Ihnen DAL dabei, die entsprechende Beziehung dieser Verbindung beizubehalten. Wenn die Transaktion endet, wird die Datenbankverbindung zur Nutzung durch andere wieder in den gemeinsam genutzten Pool gestellt.

Dann räuchern und verschmelzen. Die Datenbank kann auch verschmelzen. Wenn die Datenbank raucht, werden wir einige Datenbankanforderungen abbrechen, um sicherzustellen, dass die Datenbank nicht abstürzt.

6. Service-Governance

Nach dem Service-Framework geht es um die Frage der Service-Governance. Service Governance ist tatsächlich ein großes Konzept. Die erste besteht darin, Punkte zu vergraben. Sie müssen viele Überwachungspunkte vergraben.

Wenn beispielsweise eine Anfrage vorliegt, ob die Anfrage erfolgreich ist oder fehlgeschlagen ist und wie lang die Antwortzeit der Anfrage ist, stellen Sie alle Überwachungsindikatoren in das Überwachungssystem ein. Wir verfügen über einen großen Überwachungsbildschirm mit vielen Überwachungsindikatoren. Es gibt ein engagiertes Team, das diesen Bildschirm 72 Stunden am Tag überwacht. Wenn es Schwankungen in der Kurve gibt, wird jemand gefunden, der das Problem löst. Das andere ist das Alarmsystem. Die auf einem Überwachungsbildschirm angezeigten Dinge sind immer begrenzt und können nur die sehr wichtigen Schlüsselindikatoren anzeigen. Zu diesem Zeitpunkt ist ein Alarmsystem erforderlich.

Rom wurde nicht an einem Tag erbaut und die Infrastruktur ist ein evolutionärer Prozess. Unsere Ressourcen und unsere Zeit sind immer begrenzt. Wie können wir als Architekt und CTO mit solch begrenzten Ressourcen wichtigere Dinge produzieren?

Wir haben viele Systeme gebaut und haben das Gefühl, dass wir gute Arbeit geleistet haben, aber in Wirklichkeit sind wir nicht in die Steinzeit zurückgekehrt, weil es immer mehr Probleme und immer mehr Anforderungen gibt Ich habe das Gefühl, dass Ihr System immer noch Mängel aufweist. Es gibt viele Funktionen, die ich ändern möchte.

Beim Flusskontrollsystem muss der Benutzer beispielsweise immer noch eine Parallelitätsnummer konfigurieren. Erfordert diese Parallelitätsnummer also überhaupt keine Konfiguration durch den Benutzer? Ist es möglich, die Anzahl der Parallelität basierend auf dem Status unseres Dienstes selbst automatisch zu steuern?

Dann gibt es noch die SDK-Upgrade-Methode, die eine sehr schmerzhafte Sache ist. Beispielsweise wurde unser Service Framework 2.0 im Dezember letzten Jahres veröffentlicht, und einige Leute verwenden immer noch 1.0. Ist es möglich, ein verlustfreies Upgrade des SDK zu erreichen? Wir können den Zeitpunkt und den Rhythmus des Upgrades selbst steuern.

Außerdem unterstützt unsere aktuelle Überwachung nur die Aggregation auf demselben Dienst und ist nicht in Cluster oder Maschinen unterteilt. Werden zukünftige Indikatoren in Cluster und Maschinen unterteilt? Um das einfachste Beispiel zu nennen: Wenn ein Dienst 10 Maschinen umfasst, liegt möglicherweise nur auf einer Maschine ein Problem vor, aber alle seine Indikatoren werden gleichmäßig auf die anderen 9 Maschinen verteilt. Sie sehen lediglich einen Anstieg der gesamten Servicelatenz, aber es ist möglich, dass nur eine Maschine den gesamten Servicecluster verlangsamt. Aber wir sind noch nicht in der Lage, in mehr Dimensionen zu überwachen.

Es gibt auch einen intelligenten Alarm. Dieser Alarm muss schneller und umfassender sein. Zu Spitzenzeiten werden täglich mehr als 1.000 Alarme pro Minute verschickt. Sind alle tausend Alarme nützlich? Wenn man die Polizei zu oft ruft, ist das gleichbedeutend damit, die Polizei überhaupt nicht anzurufen. Alle waren müde und hörten auf zu schauen. Wie kann ich diesen Alarm genauer unterscheiden? Gibt es eine intelligentere Linkanalyse? Sollten wir in Zukunft keine Überwachungsindikatoren in unsere Überwachung einbeziehen, sondern eine Linkanalyse, damit wir klar erkennen können, welchem ​​Knoten das Problem entspricht.

Diese Fragen betreffen einen Grundsatz unserer Arbeit: Solange die Dinge ausreichen, müssen wir uns auf Regentage vorbereiten und eine gewisse Vorplanung treffen können.

Das obige ist der detaillierte Inhalt vonArchitekturentwicklung und Designerforschung von Ele.me. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!