Uber DOMA: microsserviços orientados a domínio

01 · CONTEXTO

Do monólito aos microsserviços

Por volta de 2012 e 2013, a Uber tinha basicamente dois serviços monolíticos e adotou uma arquitetura de microsserviços para resolver problemas operacionais. Uma única regressão no código monolítico podia derrubar a empresa inteira, e as implantações eram dolorosas e demoradas, com rollbacks frequentes.

Com microsserviços, um serviço pode cair e sofrer rollback sem derrubar o sistema inteiro. A Uber sugere ainda um modelo mental útil: pensar num microsserviço como uma biblioteca que cobra um preço de desempenho, a E/S de rede e a serialização, a cada função chamada.

02 · O PROBLEMA

Quando a complexidade vira o custo

Com a empresa maior, a Uber chegou a cerca de 2.200 microsserviços críticos. A troca de um único código monolítico por caixas-pretas cujo comportamento pode mudar a qualquer momento passou a causar comportamentos inesperados. Num caso relatado, investigar a causa-raiz de um problema exigiu passar por cerca de 50 serviços de 12 equipes diferentes.

1. Uma requisição entra pela borda e é repassada a um serviço, que chama outros em sequência; as chamadas entre serviços podem ir muito fundo.

2. Um pico de latência na dependência mais profunda pode causar uma cascata de problemas a montante.

3. Sem as ferramentas certas, enxergar o que realmente acontece nessa cadeia é impossível, o que torna a depuração difícil.

Outro sintoma: serviços que parecem independentes podem passar a precisar de implantação conjunta para qualquer mudança segura: nasce um monólito em rede.

03 · A IDEIA

Domínios e camadas

A resposta da Uber, chamada Domain-Oriented Microservice Architecture (DOMA), se apoia em princípios estabelecidos como Domain-driven Design, Clean Architecture e arquitetura orientada a serviços.

O primeiro princípio é orientar-se por coleções de microsserviços relacionados, os domínios. Um domínio pode reunir dezenas de serviços ou apenas um; busca de mapas, tarifas e matching entre passageiros e motoristas são exemplos. A organização de Maps, por exemplo, se divide em três domínios com 80 microsserviços atrás de três gateways.

O segundo princípio é o desenho em camadas: a camada do domínio define de quais dependências seus microsserviços podem depender, e cada camada só depende das que estão abaixo dela. Subindo na pilha, um domínio afeta menos serviços numa falha e é mais específico de produto.

A ordem da tabela vai do mais geral ao mais específico: cada camada seguinte é mais específica e tem raio de impacto menor.

04 · GATEWAYS

Um ponto de entrada por domínio

O terceiro princípio são os gateways: interfaces limpas tratadas como ponto único de entrada na coleção de serviços. O gateway esconde detalhes internos do domínio, e o consumidor passa a ter uma única dependência em vez de várias.

1. A camada de borda expõe os serviços ao mundo externo e conhece o aplicativo móvel.

2. A apresentação liga-se a recursos do aplicativo, enquanto o produto concentra a lógica de uma categoria de produto, agnóstica ao aplicativo.

3. O gateway é o ponto único de entrada no domínio de negócio; quem chama depende só dele.

4. Os serviços internos ficam escondidos atrás do gateway e podem mudar sem forçar migração a montante.

5. As camadas de baixo têm mais dependentes e, por isso, um raio de impacto maior; as de cima só dependem das que estão abaixo.

Isso pesa muito porque os serviços mudam o tempo todo. A Uber calculou que a meia-vida de um microsserviço era de um ano e meio, e duas das maiores reescritas de plataforma aconteceram atrás de gateways.

05 · EXTENSÕES

Estender sem alterar o núcleo

O quarto princípio é que um domínio não deve embutir lógica de outro domínio. Como as equipes precisam mesmo assim incluir lógica no domínio de outras, a Uber oferece pontos de extensão bem definidos. As extensões de lógica usam uma variação do padrão de provedor ou plugin, e as de dados evitam inchar os modelos da plataforma.

1. O endpoint de ficar online define a interface que cada extensão deve seguir, com tipo de requisição e resposta predefinidos.

2. Cada equipe registra uma extensão responsável por executar a sua verificação.

3. O endpoint percorre as respostas e verifica se alguma delas é falsa.

O resultado é desacoplar o código central de cada extensão e isolar as extensões entre si, já que elas não sabem que outra lógica está rodando.

06 · RESULTADOS E LIMITES

O que mudou e quando não adotar

Segundo a Uber, foram classificados 2.200 microsserviços em 70 domínios, com cerca de metade já implementada. Um consumidor inicial da arquitetura de extensões reduziu de três dias para três horas o tempo para priorizar e integrar uma funcionalidade. A própria empresa ressalta que o DOMA ainda era jovem, com sinais iniciais muito positivos.

Para organizações pequenas, o benefício operacional dos microsserviços provavelmente não compensa o aumento da complexidade. A Uber vê a evolução da arquitetura mais como aparar uma cerca viva do que como uma reescrita total.