L’architecture de microservices orientée domaine d’Uber

DOMA est la méthode adoptée par Uber, qui exploite 2 200 microservices, pour réduire la complexité tout en conservant la flexibilité de la MSA

• Conçue à partir de DDD, SOA, OO, CA, etc., puis adaptée aux systèmes distribués de grande ampleur dans les grandes organisations

• Un article qui condense la longue expérience d’Uber dans l’exploitation de la MSA sur une période assez longue

Principes de base de DOMA

1. Regrouper les microservices en collections par domaine

2. Créer des collections de domaines appelées Layers, et autoriser les dépendances à l’intérieur de chaque layer → Layer Design

3. Créer des Gateways offrant une interface propre comme point d’entrée unique pour chaque collection

4. Chaque domaine doit être indépendant des autres domaines. Mais comme il faut souvent inclure de la logique d’autres domaines, une architecture d’Extensions est fournie pour bien le prendre en charge

** Implémentation chez Uber

• Domains

→ Ensemble d’un ou plusieurs microservices regroupés logiquement.

→ Selon le domaine, il peut y avoir plus de 10 services, ou un seul

→ Ex.) la recherche cartographique, la tarification, la plateforme de matching (passagers et conducteurs) constituent chacun un domaine

→ Cela ne suit pas la structure organisationnelle de l’entreprise : chez Uber, l’organisation liée à la cartographie comprend 3 domaines, 80 microservices et 3 gateways

• Layer Design

→ Réponse à la question « quels services peuvent appeler d’autres services ? »

→ « separation of concerns at scale » ou « dependency management at scale »

→ Uber est structuré en 5 Layers

1. Infrastructure : fonctionnalités que toute l’organisation peut utiliser, comme le stockage et le réseau

2. Business : fonctionnalités utilisables à l’échelle métier, non limitées à une catégorie de produit spécifique ni à une LOB (Line Of Business) comme Rides, Eats ou Freight

3. Product : fonctionnalités liées à une catégorie de produit ou à une LOB spécifique, mais pouvant aussi être partagées entre plusieurs apps, comme « Request a ride »

4. Presentation : fonctionnalités liées aux applications destinées aux utilisateurs (mobile / web)

5. Edge : exposition sécurisée des services Uber vers l’extérieur, en lien aussi avec les applications mobiles

• Gateways

→ Ce n’est pas très différent d’un API Gateway de microservices. Il faut plutôt le voir comme un point d’entrée unique (Single Entry-point) relié à un Domain

→ Comme cela crée une dépendance unique vers l’extérieur, les migrations, la découverte et la complexité globale du système diminuent

• Extensions

→ Mécanisme permettant d’étendre un domaine sans modifier l’implémentation du service ni affecter sa stabilité

1. Extension de logique : extension de la logique du service via les patterns Provider ou Plugin

2. Extension de données : mécanisme permettant d’attacher des données arbitraires pour éviter que les données cœur n’augmentent trop. Utilise le type Any de Protobuf

3. Extension custom : chaque équipe étend selon un pattern adapté à son domaine

Effet observé : une réduction de 25 à 50 % du temps d’onboarding

Les 2 200 microservices ont été répartis en 70 domaines.

Chez Uber, la demi-vie des microservices a été estimée à 1,5 an. Autrement dit, tous les 1,5 an, 50 % des microservices disparaissent

Sans gateway, chaque disparition de ce type déclencherait un véritable enfer de migration.

Chez Uber, il a été démontré que les plateformes conçues avec DOMA sont beaucoup plus faciles à faire évoluer et à maintenir.

Conseils pratiques pour les autres entreprises

• Startups :

→ Les questions importantes sont : « quand faut-il adopter la MSA ? » et « est-ce adapté à notre organisation ? »

→ La MSA offre des avantages opérationnels aux organisations comptant beaucoup d’ingénieurs, mais elle augmente aussi la complexité et peut rendre le développement de fonctionnalités plus difficile

→ Dans une petite organisation, elle peut n’apporter qu’une hausse de la complexité architecturale sans bénéfice opérationnel réel, avec des coûts plus élevés

→ Une adoption progressive ne pose pas de problème, et si l’on décide d’aller vers la MSA, il faut penser en termes de « programme distribué à grande échelle » et bien séparer les microservices entre eux

→ Les premiers microservices sont importants lorsqu’ils décrivent les fonctions cœur du métier, et ils ont vocation à durer longtemps

• Entreprises de taille intermédiaire :

→ Quand l’entreprise se divise en plusieurs équipes et que les préoccupations se différencient selon les plateformes, la MSA devient plus utile

→ À ce stade, on peut commencer à réfléchir à une hiérarchie entre microservices, et la gestion des dépendances devient importante à mesure que davantage de services sont utilisés

→ Le nombre de microservices n’est pas encore forcément élevé, donc le clustering peut ne pas avoir de sens, mais une réflexion orientée domaine reste utile

• Grandes entreprises :

→ Pour une grande organisation d’ingénierie, avec des centaines d’ingénieurs, des microservices et des dépendances, DOMA est pleinement utile

→ Il devient facile de regrouper les services en domaines avec des gateways, et les gateways sont aussi utiles pour refactorer ou réécrire du legacy

Chez Uber aussi, de plus en plus d’équipes adoptent progressivement DOMA. (Le système aurait été conçu sur 2 ans avec la participation d’environ 60 personnes issues de l’ensemble de l’organisation Uber.)

[algedian]

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

Ça semble bien s’afficher maintenant… mais il me semble que les images sont un peu différentes de celles de la machine Wayback.

[xguru]

Ah, c’est revenu à la vie haha, je l’ai remis comme avant.

On dirait que le schéma où l’on voyait les noms détaillés des services était le problème.

[jaeyeonling]

On dirait que l’article a été supprimé T.T

[xguru]

Ah oui, en effet. Pour l’instant, on peut le consulter via la Wayback Machine.

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

[jaeyeonling]

Merci :)