Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Azure DevOps
Arquitetos e desenvolvedores lutam para definir o tamanho correto para um microsserviço. As diretrizes muitas vezes enfatizam evitar extremos muito grandes ou muito pequenos, mas esse conselho pode ser vago na prática. Porém, se você começar de um modelo de domínio cuidadosamente projetado, poderá definir com mais facilidade o tamanho e o escopo corretos de cada microsserviço.
Este artigo usa um serviço de entrega de drones 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 a microsserviços
No artigo anterior, definimos um conjunto de contextos limitados para um aplicativo de Entrega de Drones. Em seguida, examinamos mais de perto um desses contextos limitados, o contexto limitado de envio e identificamos um conjunto de entidades, agregações e serviços de domínio para esse contexto limitado.
Agora estamos prontos para ir do modelo de domínio para o 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 limitado marca o limite de um modelo de domínio específico. Se você descobrir que um microsserviço combina diferentes modelos de domínio, talvez seja necessário voltar e refinar sua análise de domínio.
Em seguida, examine as agregações em seu modelo de domínio. As agregações geralmente são boas candidatas a microsserviços. Uma agregação bem projetada exibe muitas das características de um microsserviço bem projetado:
- Uma agregação é derivada de requisitos de negócios, em vez de preocupações técnicas, como acesso a dados ou mensagens.
- Uma agregação deve ter alta coesão funcional.
- Uma agregação é um limite de persistência.
- As agregações devem ser acopladas livremente.
Os serviços de domínio também são bons candidatos a 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. O aplicativo De Entrega por Drone mostra um exemplo.
Considere os requisitos não funcionais. Examine 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 em relação aos seguintes critérios:
Cada serviço tem uma única responsabilidade.
Não há chamadas tagarelas entre serviços. Se dividir a funcionalidade em dois serviços faz com que elas sejam excessivamente tagarelas, pode ser um sintoma de que essas funções pertencem ao mesmo serviço.
Cada serviço é pequeno o suficiente para ser criado por uma pequena equipe que trabalha 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 outras pessoas.
Os serviços não são firmemente acoplados e podem evoluir de forma independente.
Os limites de serviço são projetados para evitar problemas de consistência ou integridade de dados. Em alguns casos, manter a consistência de dados significa agrupar a funcionalidade relacionada em um único microsserviço. No entanto, a consistência forte nem sempre é necessária. Os sistemas distribuídos fornecem estratégias para lidar com a consistência eventual e os benefícios de serviços em decomposição geralmente superam a complexidade de gerenciá-lo.
Acima de tudo, é importante ser pragmático e lembrar que o design controlado pelo domínio é um processo iterativo. Quando estiver em dúvida, comece com microsserviços mais refinados. Dividir um microsserviço em dois serviços menores é mais fácil do que refatorar a funcionalidade em vários microsserviços existentes.
Exemplo: definindo microsserviços para o aplicativo de Entrega por Drone
A equipe de desenvolvimento identificou anteriormente as quatro agregações, Entrega, Pacote, Drone e Conta e dois serviços de domínio, Agendador e Supervisor.
Entrega e Pacote são candidatos óbvios para microsserviços. O Agendador e o Supervisor coordenam as atividades executadas por outros microsserviços, portanto, 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 por Drone e Conta. Outra opção é criar microsserviços de Drone e Conta dentro do contexto de envio limitado. Esses microsserviços seriam mediados 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 dessa orientação, portanto, criamos serviços fictícios para eles em nossa implementação de referência. Mas aqui estão alguns fatores a serem considerados nesta situação:
Qual é a sobrecarga de 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 limitado é um sistema herdado? Nesse caso, você pode criar um serviço que atua como uma camada anticorrupção para traduzir entre o sistema herdado e o aplicativo moderno.
Qual é a estrutura da equipe? É fácil se comunicar com a equipe responsável pelo outro contexto limitado? Caso contrário, criar um serviço que seja mediado entre os dois contextos pode ajudar a reduzir 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 de Ingestão separado para lidar com solicitações de cliente. Esse 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.
Requisitos não funcionais também levam a equipe a criar mais um serviço. Os serviços existentes se concentram no agendamento e na entrega de pacotes em tempo real. No entanto, o sistema também deve armazenar o histórico de entrega no armazenamento de longo prazo para análise de dados. Inicialmente, a equipe considerou fazer 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 pré-lançamento. Para obter mais informações, consulte considerações sobre dados. Como resultado, a equipe criou um serviço de Histórico de Entrega separado. Esse serviço escuta os eventos do DeliveryTracking do serviço de Entrega e os grava no armazenamento de longo prazo.
O diagrama a seguir mostra o design neste ponto:
Baixe um arquivo do Visio dessa arquitetura.
Próximas etapas
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.