Identificar os limites dos microsserviços
Arquitetos e desenvolvedores lutam para definir o tamanho correto para um microsserviço. As orientações enfatizam frequentemente evitar extremos de demasiado grandes ou demasiado pequenos, mas esses conselhos podem ser vagos na prática. Mas se você começar a partir de um modelo de domínio cuidadosamente projetado, poderá definir mais facilmente o tamanho e o escopo corretos de cada microsserviço.
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, 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:
- 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 inclui vários microsserviços. A aplicação Drone Delivery mostra um exemplo.
Considere 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 fazer com que você divida um microsserviço em vários serviços menores. Em outros casos, eles podem fazer com que você mescle vários microsserviços em um único microsserviço.
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 exijam que dois ou mais serviços sejam implantados juntos. Cada serviço deve ser implantável de forma independente, sem a necessidade de reimplantar outros.
Os serviços não estão intimamente ligados e podem evoluir de forma independente.
Os limites de serviço são projetados para evitar problemas com a consistência ou integridade dos dados. Em alguns casos, manter a consistência dos dados significa agrupar a funcionalidade relacionada em um único microsserviço. No entanto, nem sempre é necessária uma forte consistência. Os sistemas distribuídos fornecem estratégias para lidar com a consistência eventual, e os benefícios dos serviços em decomposição geralmente superam a complexidade do gerenciamento.
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
A equipe de desenvolvimento identificou previamente 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 delimitado é 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, a equipe não considerou nenhum requisito não funcional. Depois de avaliar as necessidades de taxa de transferência do aplicativo, a equipe de desenvolvimento cria um microsserviço Ingestion separado para lidar com as solicitações do cliente. Este microsserviço implementa o nivelamento de carga colocando solicitações de entrada em um buffer para processamento. Em seguida, o Agendador lê as solicitações do buffer e implementa o fluxo de trabalho.
Os requisitos não funcionais também levam a equipe a criar mais um serviço. Os serviços existentes concentram-se na programação e entrega de encomendas em tempo real. No entanto, o sistema também deve armazenar o histórico de entrega em armazenamento de longo prazo para análise de dados. Inicialmente, a equipe considerou tornar essa tarefa parte do serviço de entrega. Mas os requisitos de armazenamento de dados para análise histórica diferem dos requisitos para operações em voo. Para obter mais informações, consulte Considerações sobre dados. Como resultado, a equipe criou um serviço separado de Histórico de Entregas. Este serviço escuta os eventos DeliveryTracking do serviço de Entrega e grava-os 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.