A arquitetura de microsserviços orientada a domínios da Uber

DOMA é a abordagem adotada pela Uber, que tem 2.200 microsserviços, para reduzir a complexidade mantendo a flexibilidade de uma MSA

• Projetada a partir de conceitos de DDD, SOA, OO, CA etc., adaptados para sistemas distribuídos de grande escala em organizações grandes

• Um texto que condensa a longa experiência da Uber operando MSA por bastante tempo

Princípios básicos da DOMA

1. Reunir microsserviços em coleções por domínio

2. Criar coleções de domínios chamadas Layers, permitindo dependências dentro de cada camada → Layer Design

3. Criar Gateways que fornecem interfaces limpas como ponto único de entrada para cada coleção

4. Cada domínio deve ser independente dos demais. Porém, como muitas vezes é necessário incorporar lógica de outros domínios, é oferecida uma arquitetura de Extensions para dar bom suporte a isso

** Implementação da Uber

• Domains

→ Conjunto de um ou mais microsserviços agrupados logicamente.

→ Um domínio pode ter mais de 10 serviços, ou apenas um

→ Ex.) busca de mapas, tarifas, plataforma de matching (passageiros e motoristas) etc. formam um domínio

→ Não segue a estrutura organizacional da empresa, então a organização de mapas da Uber é composta por 3 domínios, 80 microsserviços e 3 gateways

• Layer Design

→ A resposta para "quais serviços podem chamar outros serviços?" → "separation of concerns at scale" ou "dependency management at scale" → A Uber é composta por 5 Layers

1. Infrastructure : funcionalidades que toda a organização pode usar, como storage/networking etc.

2. Business : funcionalidades utilizáveis no nível de negócio, não limitadas a uma categoria específica de produto nem a uma LOB (Line Of Business) como Rides, Eats ou Freight

3. Product : funcionalidades relacionadas a uma categoria específica de produto e LOB, mas que também podem ser usadas em vários apps, como "Request a ride"

4. Presentation : funcionalidades relacionadas a aplicações voltadas ao usuário (mobile / web)

5. Edge : forma de expor com segurança os serviços da Uber para o exterior, com integração também com aplicações mobile

• Gateways

→ Não são muito diferentes de um API Gateway de microsserviços. A diferença é que devem ser vistos como o ponto único de entrada (Single Entry-point) conectado ao Domain

→ Como internamente passa a existir uma única dependência em relação ao exterior, migração, descoberta e complexidade do sistema diminuem de forma geral

• Extensions

→ Mecanismo para expandir domínios sem alterar a implementação do serviço nem afetar sua estabilidade

1. Extensão de lógica : expande a lógica do serviço usando padrões Provider ou Plugin

2. Extensão de dados : mecanismo para anexar dados arbitrários e evitar o crescimento dos dados centrais. Usa o tipo Any do Protobuf

3. Extensão customizada : cada equipe expande com padrões adequados ao seu domínio

O efeito foi uma redução de 25~50% no tempo de onboarding.

Os 2.200 microsserviços foram separados em 70 domínios.

Na Uber, a meia-vida dos microsserviços foi calculada em 1,5 ano. Ou seja, a cada 1,5 ano, 50% dos microsserviços desaparecem.

Sem gateways, cada vez que isso acontece surge um inferno de migração.

Na Uber, ficou comprovado que plataformas projetadas com DOMA são muito mais fáceis de escalar e manter.

Conselhos práticos para outras empresas

• Startups :

→ Perguntas como "quando devemos adotar MSA?" e "isso faz sentido para a nossa organização?" são importantes.

→ MSA traz vantagens operacionais para organizações com muitos engenheiros, mas aumenta a complexidade e pode tornar o desenvolvimento de funcionalidades mais difícil

→ Em organizações pequenas, pode acabar trazendo apenas aumento da complexidade arquitetural em vez de vantagens operacionais, além de mais custo.

→ Também não há problema em adotar aos poucos e, se decidir seguir para MSA, é preciso pensar nisso como um "programa distribuído em larga escala" e separar bem os microsserviços entre si.

→ Os primeiros microsserviços serão importantes para descrever as funções centrais do negócio e provavelmente durarão bastante tempo

• Empresas de porte médio :

→ Quando a empresa passa a se dividir em várias equipes e os interesses entre plataformas começam a se ramificar, MSA se torna mais útil

→ Nessa fase, já dá para considerar uma hierarquia entre microsserviços, e conforme mais serviços passam a ser usados, a gestão de dependências se torna importante

→ Como ainda não há tantos microsserviços, clustering pode não fazer muito sentido, mas pensar de forma orientada a domínios continua sendo útil

• Grandes empresas :

→ Em grandes organizações de engenharia, com centenas de engenheiros, microsserviços e dependências, DOMA é totalmente útil

→ É fácil agrupar em domínios com gateways, e os gateways também são úteis ao refatorar ou reescrever sistemas legados

Na Uber, cada vez mais equipes estão adotando DOMA gradualmente. (Segundo a Uber, cerca de 60 pessoas de toda a organização participaram juntas da criação ao longo de 2 anos.)

[algedian]

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

Agora parece estar visível, mas acho que a imagem está um pouco diferente da que está no Wayback Machine.

[xguru]

Opa, voltou à vida de novo haha. Deixei como estava antes.

Parece que o problema era a imagem em que aparecia o nome detalhado do serviço.

[jaeyeonling]

Parece que o texto foi removido T.T

[xguru]

Nossa, é verdade. Por enquanto, dá para ver no Wayback Machine.

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

[jaeyeonling]

Obrigado :)