Einführung
In jüngster Zeit wurden die Nachteile serviceorientierter Architekturen und insbesondere von Microservice-Architekturen (MA) aktiv diskutiert. Noch vor wenigen Jahren waren viele aufgrund ihrer zahlreichen Vorteile bereit, auf MA zu migrieren: Flexibilität in Form unabhängiger Bereitstellungen, transparente Eigentumsverhältnisse, erhöhte Systemstabilität und bessere Trennung von Bedenken. In letzter Zeit hat sich die Situation jedoch geändert: Der Microservice-Ansatz wurde zunehmend wegen seiner Tendenz kritisiert, die Komplexität ernsthaft zu erhöhen, was es manchmal schwierig macht, selbst triviale Funktionen zu implementieren . (Wir haben darüber im Vortrag " Microservices: Größe ist wichtig, auch wenn Sie Kubernetes haben " gesprochen - ca.
Uber verfügt derzeit über rund 2.200 kritische Microservices, und wir haben alle Vor- und Nachteile dieses Ansatzes selbst erlebt. In den letzten zwei Jahren hat Uber versucht, die Komplexität der Microservice-Landschaft zu reduzieren und gleichzeitig die Vorteile der Architektur beizubehalten. Mit diesem Beitrag möchten wir unseren generischen Ansatz für Microservice-Architekturen vorstellen, der als domänenorientierte Microservice-Architektur (DOMA) bezeichnet wird.
Während es in den letzten Jahren populär war, Microservice-Architekturen für ihre Mängel zu kritisieren, haben nur wenige es gewagt, zu verkünden, dass sie vollständig aufgegeben werden sollten. Ihre betrieblichen Vorteile sind allzu wichtig; Darüber hinaus scheint es keine (oder äußerst begrenzte) Alternativen zu diesem Ansatz zu geben. Das Ziel unseres generischen Ansatzes ist es, Organisationen zu unterstützen, die die Gesamtsystemkomplexität reduzieren und gleichzeitig die Flexibilität von MA beibehalten möchten.
In diesem Artikel werden DOMA, die Herausforderungen, die zu diesem Ansatz in Uber geführt haben, seine Vorteile für Plattform- und Produktteams und schließlich einige Tipps für diejenigen erläutert, die auf diese Architektur migrieren möchten.
Was ist ein Microservice?
Microservices sind eine Erweiterung serviceorientierter Architekturen. Im Gegensatz zu den ziemlich großen "Diensten" der 2000er Jahre erfüllen Microservices eine bestimmte Aufgabe. Diese Anwendungen werden über das Netzwerk gehostet und sind zugänglich und bieten eine genau definierte Schnittstelle. Andere Anwendungen greifen über einen Remote Procedure Call (RPC) auf diese Schnittstelle zu .
Ein Schlüsselmerkmal von MA ist die Art und Weise, wie Code veröffentlicht, aufgerufen und bereitgestellt wird. Große monolithische Anwendungen werden normalerweise in gekapselte Komponenten mit genau definierten Schnittstellen unterteilt. Diese Schnittstellen werden dann direkt aus dem Prozess heraus und nicht über das Netzwerk aufgerufen. In diesem Sinne kann ein Mikrodienst als eine Art Bibliothek mit geringerer Leistung (aufgrund der Auswirkung von Netzwerkverzögerungen und Zeit auf die Serialisierung / Deserialisierung) betrachtet werden, wenn eine seiner Funktionen aufgerufen wird.
Wenn wir uns Microservices auf diese Weise vorstellen, fragen wir uns vielleicht, warum wir überhaupt eine Microservice-Architektur benötigen. Die klassische Antwort auf diese Frage liegt in der Möglichkeit, einzelne Komponenten unabhängig voneinander bereitzustellen und einfach zu skalieren .... Bei einer großen, monolithischen Anwendung muss die Organisation den gesamten Code gleichzeitig bereitstellen oder freigeben. Infolgedessen enthält jede neue Version viele Änderungen. Bereitstellungen werden riskant und zeitaufwändig. Jeder Fehler kann das gesamte System zum Erliegen bringen.
Daher wechseln Unternehmen zu Microservices, um die Verwendung zu vereinfachen und gleichzeitig die Leistung zu beeinträchtigen . Sie müssen auch die zusätzlichen Kosten für die Wartung der für Microservices erforderlichen Infrastruktur tragen. Die Erfahrung zeigt, dass ein solcher Kompromiss in vielen Situationen sinnvoll ist. Gleichzeitig ist es ein gewichtiges Argument gegen einen vorzeitigen Übergang zu MA.
Motivation
Zum Zeitpunkt des Übergangs zu Microservices (um 2012-2013) hatten wir bei Uber zwei monolithische Hauptdienste und standen vor vielen betrieblichen Problemen, die Microservices erfolgreich lösen:
- Verfügbarkeitsrisiken. Jeder Fehler in der Codebasis des Monolithen kann das gesamte System (in diesem Fall den gesamten Uber) löschen.
- Riskante und kostspielige Bereitstellungen. Sie waren sehr schwer durchzuführen und mussten oft auf die vorherige Version zurückgesetzt werden.
- Schlechte Trennung der Verantwortungsbereiche. Es war sehr schwierig zu verfolgen, wer für was in der kolossalen Codebasis verantwortlich war. Bei exponentiellem Wachstum verwischte die Eile manchmal die Grenzen zwischen Logik und Komponenten.
- Ineffiziente Arbeit. Die oben genannten Probleme zusammen erschwerten es den Teams, unabhängig oder unabhängig voneinander zu arbeiten.
Mit anderen Worten, da die Anzahl der Ingenieure bei Uber von zehn auf Hunderte anstieg und eine große Anzahl von Teams auftauchte, die ihre eigenen Teile des Technologie-Stacks besaßen, verband die monolithische Architektur zunehmend das Schicksal dieser Teams und erlaubte ihnen nicht, unabhängig zu arbeiten.
Deshalb haben wir uns entschlossen, zu MA zu wechseln. Infolgedessen sind unsere Systeme flexibler geworden und haben es den Teams ermöglicht, autonomer zu werden .
- Systemzuverlässigkeit. Die Gesamtsystemzuverlässigkeit steigt mit dem Übergang zu MA. Ein einzelner Dienst kann abstürzen (und auf eine frühere Version zurückgesetzt werden), ohne dass das gesamte System abstürzt.
- . - : « ?», — .
- . , . , , , , .
- . .
- . .
Es ist keine Übertreibung zu sagen, dass Uber ohne MA sein derzeitiges Ausmaß und Qualitätsniveau nicht hätte erreichen können.
Jedoch, wie das Unternehmen und die Zahl der Ingenieure von Hunderten bis Tausenden erhöht weiter wachsen, haben wir begonnen , eine Reihe von Problemen mit dem deutlich erhöht im Zusammenhang zu bemerken , Systemkomplexität . Im Fall von MA opfern wir eine einzelne monolithische Codebasis im Austausch gegen eine Reihe von "Black Boxes", deren Funktionalität sich jederzeit ändern und zu unerwartetem Verhalten führen kann.
Zum Beispiel mussten Ingenieure ~ 50 Services in 12 verschiedenen Teams analysieren, um einem Problem auf den Grund zu gehen.
Das Verständnis der Abhängigkeiten zwischen Diensten kann sehr schwierig werden, da sie auf vielen Ebenen miteinander interagieren können. Ein Anstieg der Verzögerungen in der n-ten Abhängigkeit kann zu einer Lawine von Problemen bei vorgelagerten Diensten führen. Darüber hinaus ist es ohne die entsprechenden Tools unmöglich zu verstehen, was passiert ist. All dies macht das Debuggen sehr schwierig.
Ubers Microservice-Architektur ab Mitte 2018 von Jaeger
Um die einfachste Funktion zu implementieren, muss ein Ingenieur häufig mit vielen Diensten arbeiten, für die völlig unterschiedliche Teams und Personen verantwortlich sind. Infolgedessen wird viel Zeit für die Organisation von Teamarbeit, Besprechungen, Entwurfsberatungen und Codeüberprüfungen (Kernüberprüfungen) aufgewendet. Der anfängliche Vorteil der Eigentümertransparenz verschwimmt allmählich, da Teams ständig in die Dienste des anderen eindringen, Datenmodelle ändern und sogar im Auftrag von Dienstbesitzern bereitstellen. Dies kann zu Netzwerkmonolithen führen, in denen Dienste nur unabhängig zu sein scheinen. Tatsächlich müssen sie jedoch zusammen bereitgestellt werden, um Änderungen sicher vornehmen zu können.
Ein Beispiel für ein derart komplexes System in Uber (~ 2018) mit zehn Kontaktpunkten zur einfachen Integration (noch vor DOMA).
Infolgedessen haben wir eine Verlangsamung des Entwicklungsprozesses, Instabilität bei Service-Eigentümern, zeitaufwändigere Migrationen usw. Leider gibt es kein Zurück für Organisationen, die bereits zu MA gewechselt sind. Die Situation wird perfekt durch den bekannten Satz veranschaulicht: " Es ist unmöglich, mit ihnen zu leben, und man kann sie nicht erschießen ."
Domänenspezifische Microservice-Architektur
Stellen Sie sich Microservices als E / A-verknüpfte Bibliotheken und Microservices-Architektur als riesige, verteilte Anwendung vor. In diesem Fall können wir bekannte Architekturlösungen verwenden, um zu überlegen, wie wir unseren Code am besten organisieren können.
Daher kann sich eine domänenorientierte Microservice-Architektur (DOMA) auf gut etablierte Methoden zur Organisation von Code stützen, z. B. domänenorientiertes Design , saubere Architektur , serviceorientierte Architektur sowie objekt- und schnittstellenorientierte Entwicklungsmuster.Wir sehen DOMA als innovativ in dem Sinne, dass es eine relativ neue Möglichkeit ist, bestehende Designprinzipien in den global verteilten Systemen großer Organisationen zu nutzen .
Hier sind einige grundlegende DOMA-Konzepte und verwandte Begriffe:
- Anstatt einzelne Mikrodienste zu betrachten, betrachten wir Gruppen von ihnen. Und wir nennen sie Domains (Domains) .
- Als nächstes kombinieren wir die Domänen der sogenannten Schichten (die Schichten) . Die Schicht, zu der eine Domäne gehört, bestimmt, welche Abhängigkeiten für Mikrodienste in dieser Domäne verfügbar sind. Wir nennen die resultierende Architektur der Mehrschicht (des Schichtdesigns) .
- , . (gateways).
- , , , 'hardcode' , . (, - ), (extension architecture) .
Mit anderen Worten, strukturierte Architektur, Domain-Gateways und vorgefertigte DOMA-Erweiterungspunkte verwandeln Microservice-Architekturen von etwas Komplexem in etwas Greifbares und Greifbares: einen strukturierten Satz flexibler, wiederverwendbarer und abgestufter Komponenten.
Der Rest dieses Artikels konzentriert sich auf die Implementierung von DOMA durch Uber und seine Vorteile. Unternehmen, die diesen Ansatz anwenden möchten, erhalten praktische Ratschläge.
Implementierung in Uber
Domänen
Uber-Domänen sind Sammlungen eines oder mehrerer Mikrodienste, die auf der Grundlage einer logischen Kombination von Funktionen verknüpft sind. Es stellt sich natürlich die Frage, wie groß die Domain sein soll. In diesem Fall geben wir keine Anweisungen. Einige Domänen können Dutzende von Diensten enthalten, andere nur eine. Hier ist es wichtig, sorgfältig über die logische Rolle jeder Vereinigung nachzudenken . Zum Beispiel haben wir Suchdienste auf der Karte, Tarifdienste und Auswahldienste (Vergleich von Fahrern und Passagieren) in separate Domänen gruppiert. Darüber hinaus wiederholen sie nicht immer die Organisationsstruktur des Unternehmens. Uber Maps ist in drei Domänen unterteilt, wobei 80 Microservices hinter drei verschiedenen Gateways versteckt sind.
Schichtbasierte Architektur
Die Multilayer-Architektur beantwortet die Frage, welcher Dienst und welcher innerhalb der Grenzen von MA Uber kommunizieren kann. Das heißt, es kann als globale Verteilung von Verantwortungsbereichen oder als Mechanismus für das globale Abhängigkeitsmanagement angesehen werden.
Die geschichtete Architektur hilft, den Radius des Schadens nach Ausfällen zu verstehen und die Spezifität des Produkts in Bezug auf die Anzahl der abhängigen Dienste von Uber widerzuspiegeln. Wenn Sie von unten nach oben wechseln, wird die Anzahl der im Fehlerfall betroffenen Dienste verringert und der Anwendungsbereich des Produkts wird eingeschränkt . Umgekehrt hängt eine größere Anzahl von Diensten von der Funktionalität auf den unteren Ebenen ab, sodass der Radius des Schadens infolge eines Fehlers in der Regel größer ist und das Spektrum der zu lösenden Geschäftsaufgaben größer ist. Die folgende Abbildung veranschaulicht dieses Konzept.
Man kann sich vorstellen, dass sich die oberen Ebenen auf Funktionen konzentrieren, die für eine bestimmte (enge) Benutzererfahrung verantwortlich sind (z. B. mobile Funktionen), während die unteren von globaleren Geschäftsfunktionen (z. B. Kontoverwaltung oder Reisen über den Mitfahrgelegenheitsmarkt) bewohnt werden. ... Jede Schicht hängt nur von den darunter liegenden Schichten ab, was Konzepte wie Explosionsradius und Domänenintegration klarer macht.
Es ist erwähnenswert, dass sich die Funktionalität in diesem Diagramm häufig von schmal nach breit nach unten bewegt. Sie können sich eine einfache Funktion vorstellen, die mit der Zeit an Bedeutung gewinnt ("Plattform"), wenn sich die Anforderungen ändern. Tatsächlich wird diese Art der Abwärtsmigration erwartet, und viele der Kerngeschäftsplattformen von Uber begannen als Funktion für Fahrer oder Passagiere. Im Laufe der Zeit ist sie gewachsen und hat sich als neue Unternehmen (wie Uber Eats oder Uber Freight) verallgemeinert ) und verbinden Sie weitere Abhängigkeiten mit ihnen.
Innerhalb von Uber unterscheiden wir die folgenden fünf Ebenen.
- . , . — Uber , .
- -. , Uber , , Rides (), Eats ( ) Freight ( ).
- . , , . , «request a ride» ( ) , Rides: Rider, Rider «Lite», m.uber.com, ..
- . , (/), .
- . Uber . .
Wie Sie sehen können, stellt jede nachfolgende Ebene eine immer engere Kombination von Funktionen dar und hat einen kleineren Trefferradius (mit anderen Worten, weniger Komponenten hängen von der Funktionalität innerhalb dieser Ebene ab).
Gateways
Der Begriff API-Gateway ist in Microservice-Architekturen bereits gut etabliert . Unsere Definition unterscheidet sich nicht wesentlich von der etablierten - außer dass wir Gateways eher als einen einzigen Einstiegspunkt in die entsprechende Gruppe von Diensten betrachten (die wir als Domain bezeichnen ). Der Erfolg eines Gateways hängt von einer gut gestalteten API-Architektur ab: Dieses Diagramm zeigt das allgemeine
Design eines Gateways. Es abstrahiert von den Details der internen Struktur von Domänen: eine Reihe von Diensten, Tabellen mit Daten, ETL-Pipelines usw. Andere Domänen haben nur Zugriff auf Schnittstellen: API für Remoteprozeduraufrufe, Ereignisse und Anforderungen im Messagingsystem.
Da die vorgelagerten Verbraucher nur auf einem Dienst ausgeführt werden, bieten Gateways zahlreiche Vorteile in Bezug auf zukünftige Migrationen , Erkennbarkeit und eine allgemeine Reduzierung der Systemkomplexität, wenn vorgelagerte Dienste nur eine Abhängigkeit aufweisen (anstatt von mehreren nachgelagerten Diensten abhängig zu sein) kann in der Domain existieren). Aus Sicht des OO-Designs sind Gateways Schnittstellendefinitionen und ermöglichen es uns, mit einer internen „Implementierung“ (dh einer Gruppe von Mikrodiensten) alles zu tun, was wir wollen.
Erweiterungen
Erweiterungen (Erweiterungen) sind , wie der Name schon sagt, ein Mechanismus zum Erweitern von Domänen. Die grundlegende Definition eines solchen Add-Ons besteht darin, dass es einen Mechanismus zum Erweitern der Funktionalität eines Dienstes bereitstellt, ohne die Interna dieses Dienstes zu ändern oder seine allgemeine Zuverlässigkeit zu beeinträchtigen. In unserem Uber gibt es zwei Erweiterungsmodelle: die Logik (Logikerweiterungen) und auf Datenbasis (Daten die Erweiterungen) . Das Erweiterungskonzept ermöglichte es uns, die Architektur so zu skalieren, dass mehrere Teams unabhängig voneinander arbeiten konnten.
Logische Erweiterungen
Logische Erweiterungen bieten einen Mechanismus zum Erweitern der zugrunde liegenden Logik eines Dienstes. Für sie verwenden wir eine Art Provider- oder Plugin- Muster mit einer Schnittstelle, die für jeden Dienst separat definiert wird. Auf diese Weise können Teams ihre Logik nur über die Schnittstelle und ohne Beeinträchtigung des Hauptplattformcodes implementieren.
Angenommen, der Treiber ist online. Wir führen normalerweise verschiedene Überprüfungen durch, um sicherzustellen, dass es einen Online-Status haben darf (aus Sicherheits-, Compliance- usw.). Jeder von ihnen hat sein eigenes Team. Eine Möglichkeit, dies zu tun, besteht darin, jeden Befehl zu zwingen, Logik auf demselben Endpunkt zu schreiben. Dies kann jedoch die Komplexität erhöhen. Jede Prüfung erfordert eine andere - und völlig unabhängige - Logik.
Bei logischen Endpunkterweiterungen namens go online gehendefiniert die Schnittstelle, der jede Erweiterung mit einem vordefinierten Anforderungs- und Antworttyp übereinstimmen soll. Jedes Team registriert eine Erweiterung, die für die Implementierung dieser Logik verantwortlich ist. In diesem Fall können sie einfach einige Informationen über den Treiber abrufen und einen logischen Wert (bool) zurückgeben , der bestimmt, ob der Treiber den Online-Status "verdient" oder nicht. Und der Endpunkt selbst (online gehen) durchläuft diese Antworten einfach und stellt fest, ob eine davon falsch ist .
Dieser Ansatz trennt den Kerncode von den Erweiterungen und stellt eine Isolation zwischen ihnen bereit. Die Erweiterungen wissen jedoch nicht, welche andere Logik ausgeführt wird. Dies macht es einfach, zusätzliche Funktionen zu erstellen, beispielsweise für die Beobachtbarkeit oder das Markieren von Merkmalen .
Datengesteuerte Erweiterungen
Diese Art der Erweiterung bietet einen Mechanismus zum Anhängen beliebiger Daten an die Schnittstelle, um ein unnötiges Aufblähen der Datenmodelle der zugrunde liegenden Plattform zu vermeiden. In Datenerweiterungen verwenden wir aktiv Funktionen wie Any von Protobuf, mit denen Anfragen beliebige Daten hinzugefügt werden können. Dienste speichern diese Daten häufig oder geben sie an eine logische Erweiterung weiter, sodass die Hauptplattform diesen beliebigen Kontext niemals deserialisiert (und daher nichts "weiß"). Jede Implementierung verursacht einen gewissen Infrastrukturaufwand im Austausch für eine stärkere Typisierung. Eine einfachere Alternative ist das JSON-Format zur Darstellung beliebiger Daten:
Beliebige Ergänzungen
Zusätzlich zu Booleschen und Datenerweiterungen haben viele Teams bei Uber benutzerdefinierte Erweiterungsvorlagen entwickelt, die ihren Domänen entsprechen. Beispielsweise verwenden die meisten Integrationen im Zusammenhang mit der Präsentationsarchitektur eine DAG-basierte Taskausführungslogik.
Leistungen
DOMA hat fast jedes große Uber-Unternehmen in gewissem Maße beeinflusst. Im vergangenen Jahr haben wir uns hauptsächlich auf die Geschäftsschicht konzentriert. Es bietet eine allgemeine Logik für die verschiedenen Geschäftsbereiche eines Unternehmens.
DOMA ist für Uber relativ neu und wir werden in Zukunft definitiv mehr Informationen und Beispiele unserer Architektur teilen. Die ersten Ergebnisse waren ermutigend: Sie vereinfachten die Arbeit der Entwickler erheblich und reduzierten die Gesamtkomplexität des Systems.
Produkte und Plattformen
DOMA ist das Ergebnis einer Zusammenarbeit zwischen den verschiedenen Produkt- und Plattformteams von Uber. In vielen Fällen sind die Kosten für die Plattformunterstützung um eine Größenordnung gesunken. Produktteams haben von der Spezifität und der beschleunigten Entwicklung profitiert.
Zum Beispiel konnte ein früher Plattformkonsument unserer Erweiterungsarchitektur die Zeit für die Priorisierung und Integration einer neuen Funktion von drei Tagen auf drei Stunden reduzieren, indem er die Codeüberprüfungszeiten reduzierte, die Planung durchführte und die Kundenerziehung beschleunigte.
Reduzierte Komplexität
Früher mussten Produktteams mit vielen nachgelagerten Diensten innerhalb einer Domäne arbeiten, jetzt müssen sie nur noch einen anrufen. Durch die Reduzierung der Anzahl der Kontaktpunkte bei der Einführung einer neuen Funktion wurde die Implementierungszeit um 25 bis 30% reduziert. Darüber hinaus konnten wir 2.200 Services auf 70 Domains verteilen. Etwa die Hälfte von ihnen wurde umgesetzt, und für die Mehrheit gibt es einen Plan für die Umsetzung in der einen oder anderen Form.
Zukünftige Migrationen
Bei Uber haben wir berechnet, dass der Microservice eine Halbwertszeit von 1,5 Jahren hat. Mit anderen Worten, alle anderthalb Jahre verlieren 50% unserer Dienstleistungen ihre Relevanz. Ohne Gateways kann eine Microservice-Architektur zur Hölle der Migration werden. Sich ständig ändernde Microservices erfordern ständige Upstream-Migrationen. Mithilfe von Gateways können Teams Abhängigkeiten von nachgelagerten Domänendiensten vermeiden. Dies bedeutet, dass sich diese Dienste ändern können, ohne auf Upstream migrieren zu müssen.
Zwei der größten Plattform-Upgrades von Uber im letzten Jahr wurden hinter Gateways durchgeführt. Diese Plattformen verfügen über Hunderte von abhängigen Diensten, und ohne Gateways müssten alle vorhandenen Verbraucher migriert werden. Es wäre unglaublich teuer, eine vollständige Neugestaltung der Plattform unrealistisch zu machen.
Neue Geschäftsbereiche und Produkte
DOMA-basierte Frameworks haben sich als viel erweiterbarer und einfacher zu warten erwiesen. Die meisten Teams bei Uber, die zu DOMA gewechselt sind, haben dies getan, weil es zu teuer wurde, neue Geschäftsbereiche zu unterhalten.
Praktische Ratschläge
In diesem Abschnitt habe ich einige praktische Tipps für Unternehmen zusammengestellt, die an DOMA interessiert sein könnten. Das Leitprinzip dabei ist, dass nach unserer Erfahrung eine ausgereifte und durchdachte Microservice-Architektur auf inkrementellen Verschiebungen in die richtige Richtung zur richtigen Zeit basiert. In der Realität ist es fast unmöglich, MA vollständig neu zu schreiben.
Daher betrachten wir die Entwicklung von MA als eine Art Prozess des "Schneidens einer Hecke", dank dessen es in die richtige Richtung wächst, und nicht als eine einmalige, willkürliche Anstrengung. Es ist ein dynamischer und schrittweiser Prozess.
Startups
Die wichtigsten Fragen hier sind: "Wann sollten wir nach MA ziehen?" und "Ist das für unsere Organisation sinnvoll?" Wie wir oben gesehen haben, bieten Microservices in Unternehmen mit einer großen Anzahl von Ingenieuren zwar einen betrieblichen Vorteil, tragen aber auch zur Gesamtkomplexität bei, die die Implementierung neuer Funktionen erschweren kann.
In kleinen Organisationen ist es unwahrscheinlich, dass der betriebliche Vorteil die erhöhte Komplexität der Architektur kompensiert. Darüber hinaus benötigen MAs normalerweise dedizierte technische Ressourcen, um sie zu unterstützen. Dies kann für ein Unternehmen im Frühstadium zu teuer oder in Bezug auf die Priorisierung einfach nicht optimal sein.
Vor diesem Hintergrund ist es möglicherweise ratsam, den Übergang zu Microservices für eine Weile zu verschieben. Wenn sich die Organisation für den Wechsel zu Microservices entscheidet, empfehlen wir, die Analogie einer großen verteilten Anwendung zu verwenden und im Voraus über die Aufteilung der Problembereiche zwischen den Diensten nachzudenken. Denken Sie auch daran, dass die frühesten Microservices wahrscheinlich die wichtigsten und langlebigsten sind, da sie einen wichtigen Teil des Geschäfts beschreiben.
Mittleres Geschäft
Der Nutzen von MA steigt in mittelständischen Unternehmen mit vielen Teams, in denen die Verantwortungsbereiche zwischen verschiedenen Funktionen und Plattformen allmählich verschwimmen.
Hier können Sie über die Hierarchie der Mikrodienste nachdenken. Das Abhängigkeitsmanagement kann in den Vordergrund treten, da einige Dienste für die Führung eines Unternehmens viel kritischer werden können und sich mehr Teams auf sie verlassen.
Frühzeitige Investitionen in die Plattformierung können sich später auszahlen. Durch die Schaffung von Geschäftsplattformen, die nicht von anderen Produkten abhängig sind, können die Anhäufung technischer Schulden und das Eindringen willkürlicher Produktlogik in die Hauptdienste der Plattform vermieden werden. Vielleicht sollte zu diesem Zeitpunkt ein Erweiterungsmechanismus eingeführt werden, um dieses Ziel zu erreichen.
Da die Anzahl der Mikrodienste noch gering ist, ist es möglicherweise noch nicht sinnvoll, sie zu bündeln. Es ist jedoch anzumerken, dass eine Domäne im Kontext der DOMA-Implementierung in Uber durchaus einen einzelnen Dienst enthalten kann, sodass ein "domänenorientierter" Gedankengang immer noch nicht schadet.
Großes Geschäft
Große Engineering-Organisationen können Hunderte von Spezialisten, Microservices und viele Abhängigkeiten haben. Unter diesen Bedingungen erreicht DOMA sein volles Potenzial. Sicherlich werden solche Unternehmen offensichtliche Cluster von Mikrodiensten haben, die leicht zu Domänen mit Gateways vor ihnen kombiniert werden können. Ältere Dienste müssen häufig umgestaltet / neu geschrieben und anschließend migriert werden. Dies bedeutet, dass Gateways bald echte Vorteile in Bezug auf die einfache Migration bringen werden (sofern sie natürlich bereits bereitgestellt sind).
Die Bedeutung einer transparenten und verständlichen Hierarchie wird ebenfalls zunehmen: Einige Dienste werden für bestimmte Funktionen oder Funktionsgruppen „Produkte“ sein, während andere mehrere Produkte unterstützen und als „Plattformen“ fungieren. In dieser Phase ist es wichtig, die willkürliche Produktlogik von den Plattformen zu trennen, um eine massive betriebliche Belastung der Plattformteams zu vermeiden und das Risiko einer globalen Systeminstabilität zu minimieren.
Abschließende Gedanken
Bei Uber entwickeln wir DOMA aktiv weiter, da immer mehr Teams darauf migrieren. Die Hauptidee hinter DOMA ist, dass eine Microservice-Architektur nur ein großes verteiltes Programm ist. Und für seine Entwicklung können dieselben Prinzipien angewendet werden wie für jede andere Software. DOMA ist nur ein Ansatz für das praktische Denken über diese Prinzipien. Wir hoffen, Sie finden es nützlich und freuen uns auf Ihr Feedback!
DOMA selbst ist das Ergebnis einer funktionsübergreifenden Anstrengung von fast 60 Ingenieuren aus allen Uber-Abteilungen. Ich möchte den folgenden Personen für ihre Beiträge zu dieser Arbeit in den letzten 2 Jahren meinen besonderen Dank aussprechen:
Alex Zylman, Alexandre Wilhelm, Allen Lu, Ankit Srivastava, Anthony Tran, Anupam Dikshit, Anurag Biyani, Daniel Wolf, Deepti Chedda, Dmitriy Bryndin, Gaurav Tungatkar, Jacob Greenleaf, Jaikumar Ganesh, Jennie Ngyabuae, Joeoshier , Kusha Kapoor, Linda Fu, Madan Thangavelu, Nimish Sheth, Parth Shah, Shawn Burke, Simon Newton, Steve Sherwood, Uday Kiran Medisetty und Waleed Kadous.
Danksagung: Diese Arbeit hat viele bestehende Entwurfsmuster in der Branche kombiniert, um Probleme in Uber zu lösen, und auch einige neue Muster (wie Erweiterungen) vorgeschlagen. Wir sind der Industrie dankbar, dass sie daran gearbeitet hat. Wir sind auch den Linkedin-Ingenieuren, die an Superblocks gearbeitet haben, dankbar, dass sie ihre Erfahrungen mit uns geteilt haben.
PS vom Übersetzer
Lesen Sie auch in unserem Blog:
- «: , Kubernetes»;
- « 2018 ».