Qual é o tamanho certo para um microsserviço? Muitas vezes ouve-se algo para o efeito de , "não muito grande e não muito pequeno" e, embora isso esteja certamente correto, não é muito útil na prática. No entanto, se começar a partir de um modelo de domínio cuidadosamente concebido, é muito mais fácil pensar em microsserviços.
Este artigo utiliza um serviço de entrega de drones como exemplo em execução. 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 vinculados para uma aplicação de Entrega por Drone. Em seguida, analisámos mais atentamente um destes contextos vinculados, o contexto vinculado ao Envio, e identificámos um conjunto de entidades, agregados e serviços de domínio para esse contexto vinculado.
Agora estamos prontos para passar do modelo de domínio para o design da aplicação. Eis uma abordagem que pode utilizar para obter microsserviços do modelo de domínio.
Comece com um contexto vinculado. De modo geral, a funcionalidade num microsserviço não deve abranger mais do que um contexto vinculado. Por definição, um contexto vinculado marca o limite de um modelo de domínio específico. Se descobrir que um microsserviço combina diferentes modelos de domínio juntos, é sinal de que talvez seja necessário voltar atrás e aperfeiçoar a análise de domínio.
Em seguida, observe as agregações no modelo de domínio. As agregações geralmente são bons candidatos para microsserviços. Uma agregação bem concebida apresenta muitas das características de um microsserviço bem concebido, como:
- Uma agregação deriva dos requisitos de negócio, em vez de questões técnicas, como acesso a dados ou mensagens.
- Uma agregação deve ter elevada coesão funcional.
- Uma agregação é um limite de persistência.
- As agregações devem ser conjugadas livremente.
Os serviços de domínio são também bons candidatos para microsserviços. Os serviços de domínio são operações sem estado em múltiplas agregações. Um exemplo típico é um fluxo de trabalho que envolve vários microsserviços. Veremos um exemplo disto na aplicação Entrega por Drone.
Por fim, considere requisitos não funcionais. Observe fatores como tamanho da equipa, tipos de dados, tecnologias, requisitos de escalabilidade, requisitos de disponibilidade e requisitos de segurança. Estes fatores podem levá-lo a decompor ainda mais um microsserviço em dois ou mais serviços mais pequenos ou fazer o oposto e combinar vários microsserviços num.
Depois de identificar os microsserviços na sua aplicação, valide a sua estrutura com base nos seguintes critérios:
- Cada serviço tem uma única responsabilidade.
- Não existem chamadas chata entre serviços. Se dividir a funcionalidade em dois serviços faz com que sejam excessivamente chatas, pode ser um sintoma que estas funções pertencem ao mesmo serviço.
- Cada serviço é pequeno o suficiente para que possa ser construído por uma pequena equipa que trabalhe de forma independente.
- Não existem inter-dependências que exijam a implementação de dois ou mais serviços no passo de bloqueio. Deve ser sempre possível implementar um serviço sem reimplementar outros serviços.
- Os serviços não estão fortemente acoplados e podem evoluir de forma independente.
- Os limites do serviço não irão criar problemas com a consistência ou integridade dos dados. Por vezes, é importante manter a consistência dos dados ao colocar a funcionalidade num único microsserviço. Dito isto, considere se precisa realmente de uma coerência forte. Existem estratégias para abordar a consistência eventual num sistema distribuído e os benefícios da decomposição dos serviços superam frequentemente os desafios da gestão da consistência eventual.
Acima de tudo, é importante ser pragmático e lembrar-se de que a estruturação baseada em domínio é um processo iterativo. Em caso de dúvida, comece com microsserviços mais genéricos. A divisão de um microsserviço em dois serviços mais pequenos é mais fácil do que a refatorização da funcionalidade em vários microsserviços existentes.
Exemplo: Definir microsserviços para a aplicação Entrega por Drone
Lembre-se de que a equipa de desenvolvimento identificou os quatro agregados ( Entrega, Pacote, Drone e Conta) e dois serviços de domínio, Scheduler e Supervisor.
Entrega e Pacote são candidatos óbvios para microsserviços. O Scheduler e o Supervisor coordenam as atividades realizadas por outros microsserviços, pelo que faz sentido implementar estes serviços de domínio como microsserviços.
O Drone e a Conta são interessantes porque pertencem a outros contextos vinculados. Uma opção é o Scheduler chamar diretamente os contextos vinculados por Drone e Conta. Outra opção é criar microsserviços Drone e Conta dentro do contexto vinculado ao Envio. Estes microsserviços mediariam entre os contextos vinculados, expondo APIs ou esquemas de dados mais adequados ao contexto de Envio.
Os detalhes dos contextos vinculados por Drone e Conta estão fora do âmbito desta documentação de orientação, pelo que criámos serviços fictícios para os mesmos na nossa implementação de referência. Mas eis alguns fatores a ter em conta nesta situação:
Qual é a sobrecarga de rede de chamar diretamente para o outro contexto vinculado?
O esquema de dados para o outro contexto vinculado é adequado para este contexto ou é melhor ter um esquema adaptado a este contexto vinculado?
O outro contexto vinculado é um sistema legado? Em caso afirmativo, poderá criar um serviço que aja como uma camada anti-corrupção para traduzir entre o sistema legado e a aplicação moderna.
Qual é a estrutura da equipa? É fácil comunicar com a equipa responsável pelo outro contexto vinculado? Caso contrário, a criação de um serviço que media entre os dois contextos pode ajudar a mitigar o custo da comunicação entre equipas.
Até ao momento, não considerámos quaisquer requisitos não funcionais. Pensando nos requisitos de débito da aplicação, a equipa de desenvolvimento decidiu criar um microsserviço de Ingestão separado responsável pela ingestão de pedidos de cliente. Este microsserviço irá implementar o nivelamento de carga ao colocar os pedidos recebidos numa memória intermédia para processamento. O Scheduler irá ler os pedidos da memória intermédia e executar o fluxo de trabalho.
Os requisitos não funcionais levaram a equipa a criar um serviço adicional. Até agora, todos os serviços têm sido sobre o processo de agendamento e entrega de pacotes em tempo real. Mas o sistema também precisa de armazenar o histórico de todas as entregas no armazenamento de longo prazo para análise de dados. A equipa considerou tornar esta responsabilidade do serviço de Entrega. No entanto, os requisitos de armazenamento de dados são bastante diferentes para a análise histórica versus operações em voo (veja Considerações de dados). Por conseguinte, a equipa decidiu criar um serviço de Histórico de Entrega separado, que irá escutar os eventos DeliveryTracking do serviço de Entrega e escrever os eventos no armazenamento de longo prazo.
O diagrama seguinte mostra a estrutura neste momento:
Transfira um ficheiro do Visio desta arquitetura.
Passos seguintes
Neste momento, deve ter uma compreensão clara do objetivo e funcionalidade de cada microsserviço na sua conceção. Agora pode arquitetar o sistema.