Ubers Domain-Oriented Microservice Architecture

DOMA ist der Ansatz, den Uber mit 2.200 Microservices gewählt hat, um die Flexibilität von MSA zu erhalten und zugleich die Komplexität zu reduzieren.

• Basierend auf DDD, SOA, OO, CA usw. und für große verteilte Systeme in großen Organisationen ausgelegt

• Ein Artikel, in dem sich Ubers langjährige Erfahrung mit dem Betrieb von MSA verdichtet

Grundprinzipien von DOMA

1. Microservices werden pro Domain als Sammlung gebündelt

2. Es werden Domain-Sammlungen erstellt, die als Layer bezeichnet werden, sodass innerhalb jedes Layers Abhängigkeiten erlaubt sind → Layer Design

3. Für jede Sammlung wird ein Gateway erstellt, das als Single Entry-point eine saubere Schnittstelle bereitstellt

4. Jede Domain sollte von anderen Domains unabhängig sein. Da jedoch häufig Logik aus anderen Domains einbezogen werden muss, wird dafür eine gut unterstützende Extension-Architektur bereitgestellt

** Ubers Umsetzung

• Domains

→ Eine logisch gruppierte Sammlung aus einem oder mehreren Microservices.

→ Je nach Domain kann es mehr als 10 Services geben oder auch nur einen

→ Beispiel: Kartensuche, Preise, Matching-Plattform (Fahrgast und Fahrer) bilden jeweils eine Domain

→ Sie folgt nicht der Organisationsstruktur des Unternehmens; Ubers Kartenorganisation besteht aus 3 Domains, 80 Microservices und 3 Gateways

• Layer Design

→ Die Antwort auf die Frage: "Welche Services dürfen andere Services aufrufen?"

→ "separation of concerns at scale" oder "dependency management at scale"

→ Uber verwendet 5 Layer

1. Infrastructure : Funktionen, die von allen Organisationen genutzt werden können, z. B. Storage/Networking

2. Business : Funktionen, die auf Business-Ebene genutzt werden können und nicht auf bestimmte Produktkategorien oder LOBs wie Rides, Eats oder Freight beschränkt sind

3. Product : Funktionen, die mit bestimmten Produktkategorien und LOBs verbunden sind, aber auch gemeinsam in mehreren Apps verwendet werden können, etwa "Request a ride"

4. Presentation : Funktionen rund um nutzerbezogene Anwendungen (mobil / Web)

5. Edge : Die sichere Bereitstellung von Uber-Services nach außen; verbunden auch mit mobilen Anwendungen

• Gateways

→ Nicht grundlegend anders als ein API Gateway für Microservices. Es sollte jedoch als Single Entry-point verstanden werden, der mit einer Domain verbunden ist

→ Dadurch entsteht intern nur eine einzige Abhängigkeit nach außen, was Migration, Discovery und die Systemkomplexität insgesamt reduziert

• Extensions

→ Ein Mechanismus, um Domains zu erweitern, ohne die Implementierung eines Services zu ändern oder dessen Stabilität zu beeinträchtigen

1. Logic-Erweiterung : Erweiterung der Service-Logik mithilfe von Provider- oder Plugin-Patterns

2. Data-Erweiterung : Ein Mechanismus zum Anhängen beliebiger Daten, um ein Anwachsen der Core-Daten zu verhindern. Nutzt den Any-Typ von Protobuf

3. Custom-Erweiterung : Jedes Team erweitert passend zur Domain mit einem geeigneten Pattern

Der Effekt: Die Onboarding-Zeit sinkt um 25 bis 50 %.

2.200 Microservices wurden in 70 Domains aufgeteilt.

Bei Uber wurde die Halbwertszeit von Microservices auf 1,5 Jahre berechnet. Das heißt: Alle 1,5 Jahre verschwinden 50 % der Microservices.

Ohne Gateways würde jedes solche Verschwinden in eine Migrationshölle führen.

Bei Uber hat sich gezeigt, dass mit DOMA entworfene Plattformen deutlich leichter skalierbar und einfacher zu warten sind.

Praktische Ratschläge für andere Unternehmen

• Startups :

→ Fragen wie "Wann sollten wir MSA einführen?" und "Ist das für unsere Organisation sinnvoll?" sind entscheidend.

→ MSA bringt Organisationen mit vielen Engineers operative Vorteile, kann aber auch die Komplexität erhöhen und die Entwicklung von Funktionen erschweren

→ In kleinen Organisationen kann es statt operativer Vorteile auch nur zu mehr architektonischer Komplexität und höheren Kosten führen

→ Eine langsame Einführung ist ebenfalls möglich. Wenn man sich für MSA entscheidet, sollte man es als "großes verteiltes Programm" verstehen und die Microservices entsprechend voneinander trennen

→ Die ersten Microservices sind wichtig, wenn sie zentrale Geschäftsfunktionen beschreiben und langfristig Bestand haben sollen

• Mittelgroße Unternehmen :

→ Wenn sich das Unternehmen in mehrere Teams aufteilt und sich die Zuständigkeiten zwischen Plattformen zu verzweigen beginnen, wird MSA nützlicher

→ In dieser Phase kann man Hierarchien zwischen Microservices in Betracht ziehen; wenn mehr Services genutzt werden, wird Abhängigkeitsmanagement wichtiger

→ Die Anzahl der Microservices ist noch nicht sehr hoch, daher ist Clustering womöglich nicht sinnvoll, aber ein Domain-orientiertes Denken ist nützlich

• Große Unternehmen :

→ In großen Engineering-Organisationen mit Hunderten Engineers, Microservices und Abhängigkeiten ist DOMA voll nützlich

→ Eine einfache Gruppierung in Domains mit Gateways ist möglich, und Gateways sind auch beim Refactoring oder Neuschreiben von Legacy-Systemen hilfreich

Auch bei Uber führen nach und nach immer mehr Teams DOMA ein. (An der Entwicklung arbeiteten über 2 Jahre hinweg etwa 60 Personen aus allen Organisationen von Uber gemeinsam mit.)

[algedian]

https://eng.uber.com/microservice-architecture/

Jetzt scheint es gut sichtbar zu sein, aber in der Version in der Wayback Machine sehen die Abbildungen etwas anders aus.

[xguru]

Ah, jetzt ist es wieder da, haha. Ich habe es in den ursprünglichen Zustand zurückversetzt.

Offenbar war die Abbildung mit den sichtbaren detaillierten Servicenamen das Problem.

[jaeyeonling]

Der Artikel scheint gelöscht worden zu sein T.T

[xguru]

Ach so, stimmt. Zumindest in der Wayback Machine ist es noch zu sehen.

https://web.archive.org/web/20200803012939/…

[jaeyeonling]

Vielen Dank :)