Contexto

Você está desenvolvendo um aplicativo empresarial do lado do servidor. Ele deve oferecer suporte a uma variedade de clientes diferentes, incluindo navegadores de desktop, navegadores móveis e aplicativos móveis nativos. O aplicativo também pode expor uma API para consumo de terceiros. Ele também pode se integrar a outros aplicativos por meio de serviços da Web ou de um agente de mensagens. O aplicativo lida com solicitações (solicitações e mensagens HTTP) executando a lógica de negócios; acessar um banco de dados; troca de mensagens com outros sistemas; e retornando uma resposta HTML / JSON / XML. Existem componentes lógicos correspondentes a diferentes áreas funcionais do aplicativo.

Problema

Qual é a arquitetura de implantação do aplicativo?

Forças

• Há uma equipe de desenvolvedores trabalhando no aplicativo
• Novos membros da equipe devem se tornar produtivos rapidamente
• O aplicativo deve ser fácil de entender e modificar
• Você deseja praticar a implantação contínua do aplicativo
• Você deve executar várias instâncias do aplicativo em várias máquinas para satisfazer os requisitos de escalabilidade e disponibilidade
• Você deseja aproveitar as vantagens de tecnologias emergentes (frameworks, linguagens de programação, etc)

Solução

Defina uma arquitetura que estrutura a aplicação como um conjunto de fracamente acoplado, serviços de colaboração. Esta abordagem corresponde ao eixo Y do Scale Cube. Cada serviço é:

• Altamente passível de manutenção e teste – permite ra PID e desenvolvimento e implantação frequentes
• Fracamente acoplado a outros serviços – permite que uma equipe trabalhe de forma independente a maior parte do tempo em seu (s) serviço (s) sem ser afetado por alterações em outros serviços e sem afetar outros serviços li>
• Independentemente implantável – permite que uma equipe implante seu serviço sem ter que coordenar com outras equipes
• Capaz de ser desenvolvido por uma equipe pequena – essencial para alta produtividade, evitando o alto nível de comunicação de grandes equipes

Os serviços se comunicam usando protocolos síncronos, como HTTP / REST, ou protocolos assíncronos, como AMQP. Os serviços podem ser desenvolvidos e implantados independentemente uns dos outros. Cada serviço tem seu próprio banco de dados para ser dissociado de outros serviços. A consistência de dados entre os serviços é mantida usando o padrão Saga

Para saber mais sobre a natureza de um serviço, leia este artigo.

Exemplos

Aplicativos fictícios de comércio eletrônico em

Vamos imaginar que você esteja construindo um aplicativo de comércio eletrônico que recebe pedidos de clientes, verifica o estoque e o crédito disponível e os envia. O aplicativo consiste em vários componentes, incluindo StoreFrontUI, que implementa a interface do usuário , junto com alguns serviços de back-end para verificação de crédito, manutenção de estoque e pedidos de envio. O aplicativo consiste em um conjunto de serviços.

Mostre-me o código

Por favor, veja os aplicativos de exemplo desenvolvidos por Chris Richardson. Esses exemplos no Github ilustram vários aspectos da arquitetura de microsserviço.

Contexto resultante

Benefícios

Esta solução tem vários benefícios:

• Permite a entrega e implantação contínuas de aplicativos grandes e complexos.
  • Melhor capacidade de manutenção – cada serviço é relativamente pequeno e, portanto, mais fácil de entender e mudar
  • Melhor testabilidade – os serviços são menores e mais rápidos de testar
  • Melhor implantabilidade – serviços pode ser implantado de forma independente
  • Ele permite que você organize o esforço de desenvolvimento em torno de várias equipes autônomas. Cada equipe (as chamadas duas pizzas) possui e é responsável por um ou mais serviços. Cada equipe pode desenvolver, testar, implantar e dimensionar seus serviços independentemente de todas as outras equipes.
• Cada microsserviço é relativamente pequeno:
  • Mais fácil para um desenvolvedor para entender
  • O IDE é mais rápido, tornando os desenvolvedores mais produtivos
  • O aplicativo é iniciado mais rápido, o que torna os desenvolvedores mais produtivos e acelera as implantações
• Isolamento de falhas aprimorado. Por exemplo, se houver vazamento de memória em um serviço, apenas esse serviço será afetado. Os outros serviços continuarão a lidar com as solicitações. Em comparação, um componente com comportamento inadequado de uma arquitetura monolítica pode derrubar todo o sistema.
• Elimina qualquer compromisso de longo prazo com uma pilha de tecnologia. Ao desenvolver um novo serviço, você pode escolher uma nova pilha de tecnologia. Da mesma forma, ao fazer grandes alterações em um serviço existente, você pode reescrevê-lo usando uma nova pilha de tecnologia.

Desvantagens

Esta solução tem uma série de desvantagens:

• Os desenvolvedores devem lidar com a complexidade adicional de criar um sistema distribuído:
  • Os desenvolvedores devem implementar o mecanismo de comunicação entre serviços e lidar com a falha parcial
  • Implementar solicitações que abrangem vários serviços é mais difícil
  • Testar as interações entre serviços é mais difícil
  • Implementar solicitações que abrangem vários serviços requer coordenação cuidadosa entre as equipes
  • Ferramentas / IDEs de desenvolvedor são orientadas para a construção de aplicativos monolíticos e não fornecem suporte explícito para o desenvolvimento de aplicativos distribuídos.
• Complexidade de implantação. Na produção, há também a complexidade operacional de implantar e gerenciar um sistema composto por muitos serviços diferentes.
• Maior consumo de memória. A arquitetura de microsserviço substitui N instâncias de aplicativos monolíticos por instâncias de serviços NxM. Se cada serviço for executado em sua própria JVM (ou equivalente), o que geralmente é necessário para isolar as instâncias, haverá a sobrecarga de M vezes o número de tempos de execução da JVM. Além disso, se cada serviço é executado em sua própria VM (por exemplo, instância EC2), como é o caso da Netflix, a sobrecarga é ainda maior.

Problemas

Existem muitos problemas que você deve resolver.

Quando usar a arquitetura de microsserviço?

Um desafio de usar essa abordagem é decidir quando faz sentido usá-la. Ao desenvolver a primeira versão do um aplicativo, muitas vezes você não tem os problemas que essa abordagem resolve. Além disso, usar uma arquitetura elaborada e distribuída tornará o desenvolvimento mais lento. Isso pode ser um grande problema para startups, cujo maior desafio é frequentemente como evoluir rapidamente o modelo de negócios e o acompanhamento aplicativo. Usar divisões do eixo Y pode tornar muito mais difícil iterar rapidamente. Mais tarde, no entanto, quando o desafio é como escalar e você precisa usar a decomposição funcional, as dependências emaranhadas podem dificultar a decomposição de seu aplicativo monolítico em um conjunto de serviços.

Como decompor o aplicativo ção em serviços?

Outro desafio é decidir como particionar o sistema em microsserviços. Isso é uma arte, mas há uma série de estratégias que podem ajudar:

• Decompor por capacidade de negócios e definir serviços correspondentes às capacidades de negócios.
• Decompor por subdomínio de design orientado por domínio.
• Decompor por verbo ou caso de uso e definir serviços responsáveis por ações específicas . por exemplo. um Shipping Service que é responsável por enviar pedidos completos.
• Decompor por substantivos ou recursos, definindo um serviço que é responsável por todas as operações em entidades / recursos de um determinado modelo. por exemplo. um Account Service que é responsável por gerenciar contas de usuário.

O ideal é que cada serviço tenha apenas um pequeno conjunto de responsabilidades. (Tio) Bob Martin fala sobre o projeto de classes usando o Princípio de Responsabilidade Única (SRP). O SRP define a responsabilidade de uma classe como um motivo para mudar e afirma que uma classe deve ter apenas um motivo para mudar. Faz sentido aplicar o SRP ao design de serviço também.

Outra analogia que ajuda no design de serviço é o design de utilitários Unix. O Unix fornece um grande número de utilitários, como grep, cat e find. Cada utilitário faz exatamente uma coisa, muitas vezes excepcionalmente bem, e deve ser combinado com outros utilitários usando um script de shell para executar tarefas complexas.

Como manter a consistência dos dados?

Para garantir um acoplamento fraco, cada serviço tem seu próprio banco de dados. Manter a consistência de dados entre os serviços é um desafio porque as transações 2 phase-commit / distribuídas não são uma opção para muitos aplicativos. Em vez disso, um aplicativo deve usar o padrão Saga. Um serviço publica um evento quando seus dados mudam. Outros serviços consomem esse evento e atualizam seus dados. Existem várias maneiras de atualizar dados e publicar eventos de forma confiável, incluindo Event Sourcing e Adaptação do log de transações.

Como implementar consultas?

Outro desafio é implementar consultas que precisam recuperar dados pertencentes a vários serviços.

• A API Composição e padrões de segmentação de responsabilidade de consulta de comando (CQRS).

Existem muitos padrões relacionados ao padrão de microsserviços. A arquitetura monolítica é uma alternativa à arquitetura de microsserviço. Os outros padrões abordam problemas que você encontrará ao aplicar a arquitetura de microsserviço.

• Padrões de decomposição
  • Decompor por capacidade de negócios
  • Decompor por subdomínio
• O padrão Banco de dados por serviço descreve como cada serviço tem seu próprio banco de dados para garantir acoplamento fraco.
• O padrão API Gateway define como os clientes acessam os serviços em uma arquitetura de microsserviço.
• Os padrões de descoberta do lado do cliente e descoberta do lado do servidor são usados para encaminhar solicitações de um cliente para um instância de serviço disponível em uma arquitetura de microsserviço.
• Os padrões de mensagens e invocação de procedimento remoto são duas maneiras diferentes de os serviços se comunicarem.
• Os padrões de serviço único por host e vários serviços por host são duas estratégias de implantação diferentes.
• Padrões de interesses transversais: padrão de chassi de microsserviço e configuração externa
• Padrões de teste: Teste de componente de serviço e Teste de contrato de integração de serviço
• Circuito Breaker
• token de acesso
• padrões de observabilidade:
  • agregação de log
  • métricas de aplicativo
  • log de auditoria
  • Rastreamento distribuído
  • rastreamento de exceções
  • API de verificação de integridade
  • Log de implantações e alterações
• Padrões de IU:
  • Composição de fragmentos de página do lado do servidor
  • Composição de IU do lado do cliente

Usos conhecidos

A maioria dos sites de grande escala, incluindo Netflix, Amazon e eBay, evoluiu de uma arquitetura monolítica para uma arquitetura de microsserviço.

Netflix, que é um serviço de streaming de vídeo muito popular e responsável para até 30% do tráfego da Internet, tem uma arquitetura orientada a serviços em grande escala. Eles lidam com mais de um bilhão de chamadas por dia para sua API de streaming de vídeo de mais de 800 tipos diferentes de dispositivos. Cada API chama fãs para uma média de seis chamadas para serviços de back-end.

A Amazon.com originalmente tinha uma arquitetura de duas camadas. Para escalar, eles migraram para uma arquitetura orientada a serviços que consiste em centenas de serviços de back-end. Vários aplicativos chamam esses serviços, incluindo os aplicativos que implementam o site Amazon.com e a API de serviço da web. O aplicativo do site Amazon.com chama 100-150 serviços para obter o dados que costumavam construir uma página da web.

O site de leilão ebay.com também evoluiu de uma arquitetura monolítica para uma arquitetura orientada a serviços. A camada de aplicativo consiste em vários aplicativos independentes. Cada aplicativo implementa a lógica de negócios para uma área de função específica, como compra ou venda. Cada aplicativo usa divisões do eixo X e alguns aplicativos, como pesquisa, usam divisões do eixo Z.Ebay.com também aplica uma combinação de escala de estilo X, Y e Z ao camada de banco de dados.

Existem vários outros exemplos de empresas que usam a arquitetura de microsserviço.

Chris Richardson tem exemplos de aplicativos baseados em microsserviços.

Consulte também

Veja minha palestra sobre o Code Freeze 2018, que fornece uma boa introdução à arquitetura de microsserviço.