Identificar os limites dos microsserviços
Qual é o tamanho certo para um microsserviço? Muitas vezes ouve-se algo como "não muito grande nem muito pequeno" – e embora isso seja certamente correto, não é muito útil na prática. Mas se você começar a partir de um modelo de domínio cuidadosamente projetado, é muito mais fácil raciocinar sobre microsserviços.
Este artigo usa um serviço de entrega por drone como um exemplo em execução. Você pode ler mais sobre o cenário e a implementação de referência correspondente aqui.
Do modelo de domínio aos microsserviços
No artigo anterior, definimos um conjunto de contextos limitados para uma aplicação de Entrega por Drone. Em seguida, examinamos mais de perto um desses contextos limitados, o contexto limitado de Envio, e identificamos um conjunto de entidades, agregados e serviços de domínio para esse contexto limitado.
Agora estamos prontos para ir do modelo de domínio ao design do aplicativo. Aqui está uma abordagem que você pode usar para derivar microsserviços do modelo de domínio.
Comece com um contexto limitado. Em geral, a funcionalidade em um microsserviço não deve abranger mais de um contexto limitado. Por definição, um contexto delimitado marca o limite de um modelo de domínio específico. Se você achar que um microsserviço mistura diferentes modelos de domínio, isso é um sinal de que talvez seja necessário voltar e refinar sua análise de domínio.
Em seguida, veja as agregações no seu modelo de domínio. Os agregados são muitas vezes bons candidatos para microsserviços. Um agregado bem projetado exibe muitas das características de um microsserviço bem projetado, tais como:
- Um agregado é derivado de requisitos de negócios, em vez de preocupações técnicas, como acesso a dados ou mensagens.
- Um agregado deve ter uma elevada coesão funcional.
- Um agregado é um limite de persistência.
- Os agregados devem ser fracamente acoplados.
Os serviços de domínio também são bons candidatos para microsserviços. Os serviços de domínio são operações sem estado em várias agregações. Um exemplo típico é um fluxo de trabalho que envolve vários microsserviços. Veremos um exemplo disso no aplicativo Drone Delivery.
Finalmente, considere os requisitos não funcionais. Analise fatores como tamanho da equipe, tipos de dados, tecnologias, requisitos de escalabilidade, requisitos de disponibilidade e requisitos de segurança. Esses fatores podem levá-lo a decompor ainda mais um microsserviço em dois ou mais serviços menores, ou fazer o oposto e combinar vários microsserviços em um.
Depois de identificar os microsserviços em seu aplicativo, valide seu design de acordo com os seguintes critérios:
- Cada serviço tem uma única responsabilidade.
- Não há chamadas chatas entre os serviços. Se dividir a funcionalidade em dois serviços faz com que eles sejam excessivamente tagarelas, pode ser um sintoma de que essas funções pertencem ao mesmo serviço.
- Cada serviço é pequeno o suficiente para que possa ser construído por uma pequena equipe trabalhando de forma independente.
- Não há interdependências que exigirão que dois ou mais serviços sejam implantados em lock-step. Deve ser sempre possível implantar um serviço sem reimplantar nenhum outro serviço.
- Os serviços não estão estreitamente ligados e podem evoluir de forma independente.
- Seus limites de serviço não criarão problemas com a consistência ou integridade dos dados. Às vezes, é importante manter a consistência dos dados colocando a funcionalidade em um único microsserviço. Dito isto, considere se você realmente precisa de uma forte consistência. Existem estratégias para lidar com a eventual consistência em um sistema distribuído, e os benefícios de serviços em decomposição geralmente superam os desafios de gerenciar uma eventual consistência.
Acima de tudo, é importante ser pragmático e lembrar que o design orientado por domínio é um processo iterativo. Em caso de dúvida, comece com microsserviços de grão mais grosso. Dividir um microsserviço em dois serviços menores é mais fácil do que refatoração de funcionalidade em vários microsserviços existentes.
Exemplo: Definição de microsserviços para a aplicação Drone Delivery
Lembre-se que a equipe de desenvolvimento identificou os quatro agregados — Entrega, Pacote, Drone e Conta — e dois serviços de domínio, Agendador e Supervisor.
Entrega e Embalagem são candidatos óbvios para microsserviços. O Agendador e o Supervisor coordenam as atividades realizadas por outros microsserviços, por isso faz sentido implementar esses serviços de domínio como microsserviços.
Drone e Conta são interessantes porque pertencem a outros contextos limitados. Uma opção é que o Agendador chame diretamente os contextos limitados pelo Drone e pela Conta. Outra opção é criar microsserviços de Drone e Conta dentro do contexto delimitado de Envio. Esses microsserviços mediariam entre os contextos limitados, expondo APIs ou esquemas de dados mais adequados ao contexto de envio.
Os detalhes dos contextos limitados por Drone e Conta estão além do escopo desta orientação, por isso criamos serviços simulados para eles em nossa implementação de referência. Mas aqui estão alguns fatores a considerar nesta situação:
Qual é a sobrecarga da rede de chamar diretamente para o outro contexto limitado?
O esquema de dados para o outro contexto limitado é adequado para esse contexto ou é melhor ter um esquema adaptado a esse contexto limitado?
O outro contexto delimitado é um sistema legado? Nesse caso, você pode criar um serviço que atue como uma camada anticorrupção para traduzir entre o sistema herdado e o aplicativo moderno.
Qual é a estrutura da equipa? É fácil comunicar com a equipa responsável pelo outro contexto limitado? Caso contrário, a criação de um serviço que faça a mediação entre os dois contextos pode ajudar a mitigar o custo da comunicação entre equipes.
Até agora, não consideramos nenhum requisito não funcional. Pensando nos requisitos de taxa de transferência do aplicativo, a equipe de desenvolvimento decidiu criar um microsserviço Ingestion separado que é responsável por ingerir as solicitações do cliente. Esse microsserviço implementará o nivelamento de carga colocando as solicitações de entrada em um buffer para processamento. O Agendador lerá as solicitações do buffer e executará o fluxo de trabalho.
Requisitos não funcionais levaram a equipe a criar um serviço adicional. Todos os serviços até agora têm sido sobre o processo de agendamento e entrega de pacotes em tempo real. Mas o sistema também precisa armazenar o histórico de cada entrega em armazenamento de longo prazo para análise de dados. A equipe considerou tornar isso responsabilidade do serviço de Delivery. No entanto, os requisitos de armazenamento de dados são bastante diferentes para análise histórica versus operações em voo (consulte Considerações sobre dados). Portanto, a equipe decidiu criar um serviço de Histórico de Entrega separado, que ouvirá os eventos do DeliveryTracking do serviço de Entrega e gravará os eventos no armazenamento de longo prazo.
O diagrama a seguir mostra o design neste ponto:
Baixe um arquivo Visio desta arquitetura.
Próximos passos
Neste ponto, você deve ter uma compreensão clara da finalidade e funcionalidade de cada microsserviço em seu design. Agora você pode arquitetar o sistema.