Em um post recente, a engenheira do Uber Emily Reinhold descreveu como eles quebraram uma API monolítica em uma arquitetura de microserviços modular e flexível. Ela destacou algumas escolhas importantes de design e arquitetura que foram chave para o esforço de migração do Uber.
O processo de migração para microserviços, Reinhold diz, teve o objetivo de alcançar uma melhor escalabilidade em três aspectos diferentes: manipular o tráfego crescente; adicionar novas funcionalidades com facilidade; e, a adoção de uma arquitetura que pode facilmente adaptar-se ao crescimento da empresa.
Os engenheiros do Uber tomoram algumas decisões de design em geral destinadas a reduzir o acoplamento entre os microserviços:
- Adotar MVCS, uma extensão da bem conhecida abordagem Model-View-Controller, que inclui explicitamente uma camada de serviço, que hospeda a lógica da aplicação. Isto permitiu ao Uber desacoplar a lógica de negócios da camada de persistência, tornando-se assim mais fácil modificar essa última.
- Substituir o PostgreSQL pelo UDR, o armazenamento de dados globalmente replicado do Uber para permitir trajetos simultaneos a partir de vários datacenters.
De forma semelhante, os engenheiros do Uber tomaram decisões arquiteturais importantes destinadas a lidar com as consequências de ter um elevado número de serviços:
- Rede assíncrona: para lidar com o aumento no número de solicitações de serviço, os engenheiros do Uber confiaram no Tornado, uma biblioteca Python de rede assíncrona baseada em loop de eventos que mostrou ser capaz de escalar a dezenas de milhares de conexões abertas simultaneamente. Uma das vantagens de usar o Tornado foi sua capacidade de integrar-se bem ao código Python de rede existente no Uber, que foi estruturado em torno de um paradigma síncrono;
- Descoberta de serviços e resiliência: com o crescente número de serviços, uma funcionalidade chave é descobrir serviços e identificar pontos de falha. Isto inclui a coleta de métricas como taxas de falhas e violações de SLA, detectar hosts com problemas, funcionando como disjuntor para evitar falhas em cascata. O Uber endereçou estas preocupações usando TChannel sobre Hyperbahn, um protocolo de multiplexação de rede e de framing para a RPC que eles desenvolveram e transformaram em código aberto;
- Definições de interface rígidas: Uber escolheu Thrift para definir interfaces de serviço utilizando uma IDL (Interface Definition Language - linguagem para definição de interfaces) e para gerar arquivos de origem do lado do cliente para uma variedade de linguagens. O Thrift torna possível detectar qualquer consumidor tentando fazer uma chamada que não esteja em conformidade com a definição de interface.
Por último, Reinhold explica, o Uber mantém um ambiente de produção saudável através da aplicação de três princípios:
- executar testes de carga para identificar gargalos e pontos de ruptura;
- usar containers para utilizar mais eficientemente o hardware;
- simular interrupção de serviço para garantir que o sistema é capaz de se recuperar e identificar suas vulnerabilidades.
Emily Reinhold também discutiu estes temas na última QCon em Nova York.