Muitos aplicativos modernos precisam ser desenvolvidos em toda a empresa, às vezes até na Internet. Cada aplicativo deve atender aos requisitos de escalabilidade, disponibilidade, segurança, confiabilidade e resiliência.
Neste artigo, apresentarei alguns padrões de design que podem ajudá-lo facilmente a atingir os recursos acima. Abordarei cada padrão, como usar esse padrão na nuvem e quando usá-lo e quando não.
Alguns desses padrões não são tão novos, mas são muito úteis no mundo atual da nuvem da Internet.
Aqui está uma lista dos padrões que discutirei neste artigo:
- Disjuntor
- Segregação de responsabilidade de comando e consulta (CQRS)
- Sourcing de eventos
- Sidecar
- Backend-for-Frontend
- Strangler
Então vamos começar.
1. Disjuntor
Os sistemas distribuídos devem ser projetados com as falhas em mente. Existem microsserviços no mundo hoje em dia, e esses serviços dependem principalmente de outros serviços remotos. Esses serviços remotos podem não responder a tempo por vários motivos, como rede, download de aplicativos, etc. Na maioria dos casos, a implementação de novas tentativas deve ser capaz de resolver os problemas.
Mas às vezes pode haver problemas sérios, como degradação dos serviços ou falha completa dos serviços por si só. Não faz sentido continuar tentando novamente nesses casos. Nesse caso, o modelo do disjuntor pode ser útil.
O diagrama acima mostra uma implementação do circuito do disjuntor onde quando o serviço 1 percebe que o serviço de chamada 2 tem falhas / tempos limite contínuos em vez de tentar novamente, o serviço 1 desconecta as chamadas para o serviço 2 e retorna uma resposta em caso de falha.
Existem bibliotecas de código aberto populares, como Netflix Hystrix
ou Reselience4J, que podem ser usadas para implementar esse padrão com muita facilidade.
Se você estiver usando gateways de API ou proxies
como o Envoy , isso pode ser feito na própria camada de proxy.
Nota:É muito importante que logs e avisos suficientes sejam implementados quando a cadeia está aberta para controlar as solicitações recebidas durante esse tempo e que a equipe de operações esteja ciente disso.
Você também pode implementar um meio disjuntor para continuar atendendo clientes com deficiência.
Quando usar este padrão
- Quando um serviço depende de outro serviço remoto e, em alguns cenários, é provável que falhe.
- Quando o serviço tem uma dependência muito forte (como serviços de dados mestre).
Quando não usar este padrão
- Ao lidar com dependências locais, um disjuntor pode criar sobrecarga.
2. Command and Query Responsibility Segregation (CQRS) ( (CQRS))
CQRS é um modelo muito útil para aplicativos modernos de data warehouse. Ele é baseado no princípio de separar as operações de leitura (consulta) e gravação / atualização (comando) no armazenamento de dados.
Digamos que você esteja construindo um aplicativo que requer o armazenamento de dados em um banco de dados como MySQL / PostgreSQL, etc. Como todos sabem, ao gravar dados no armazenamento, uma operação deve passar por vários estágios - por exemplo, validação, modelagem e persistência - e, portanto, operações típicas de gravação / atualização demoram mais do que operações simples de leitura.
Ao usar o mesmo armazenamento de dados para executar operações de leitura e gravação ao mesmo tempo e em escala, você pode começar a ver problemas de desempenho.
Nesses casos, o modelo CQRS pode ser útil. O padrão CQRS sugere o uso de diferentes modelos de dados para operações de leitura e gravação. Algumas variações também sugerem o uso de armazenamentos de dados separados para esses modelos.
Observação: a maioria dos bancos de dados PaaS atualmente oferece a capacidade de criar réplicas legíveis ( Google Cloud SQL , Azure SQL DB , Amazon RDS
, etc.) de armazenamentos de dados, o que torna muito mais fácil obter a replicação de dados.
Muitos bancos de dados corporativos também fornecem esse recurso se você estiver lidando com bancos de dados locais.
Observação: algumas pessoas atualmente também optam por implementar réplicas legíveis como bancos de dados NoSQL rápidos e de alto desempenho, como MongoDB e Elasticsearch.
Quando usar este padrão
- Ao olhar para o escalonamento de um aplicativo, espera-se uma grande quantidade de leituras e gravações
- Quando você deseja configurar as operações de leitura e gravação separadamente.
- Quando suas operações de leitura são quase reais ou consistentes.
Quando não usar este padrão
- Quando você está construindo um aplicativo CRUD comum que não espera uma grande quantidade de leituras e gravações de uma só vez.
3. Fornecimento de eventos
Uma fonte de evento é um padrão de design interessante no qual uma sequência de eventos de domínio é armazenada como um log e uma exibição de log agregada fornece o estado atual do aplicativo.
Esse padrão é comumente usado para sistemas que não podem permitir bloqueios de armazenamento de dados e que precisam manter o histórico de auditoria e eventos - por exemplo, aplicativos como hotéis / conferências / assentos.
Dado um sistema de reserva de quarto de hotel em que os usuários devem fazer ou cancelar uma reserva. Aqui você precisa armazenar sua reserva e cancelamento como uma série de eventos. Os quartos disponíveis são mostrados em um resumo antes de cada reserva, revisando os registros de eventos.
Nota:A maioria dos provedores de serviços de nuvem oferece suporte a serviços de mensagens, como Google Pub / Sub, Azure Service Bus, AWS SQS, etc. Esses serviços, combinados com armazenamentos de dados consistentes fortes, podem ser usados para implementar esse esquema.
Quando usar este padrão
- Quando as operações normais de CRUD não são boas o suficiente para atender aos requisitos
- Normalmente adequado para sistemas de reserva de assentos, como ônibus, trens, conferências, cinemas, etc. - ou para sistemas de comércio eletrônico, que consistem em atividades como carrinhos de compras, pagamentos, etc.
- Quando houver necessidade de auditoria robusta e reprodução de eventos para criar o estado atual e passado dos aplicativos.
Quando não usar este padrão
- Quando as operações normais do CRUD são boas o suficiente para atender às necessidades do usuário.
4. Sidecar (padrão de design Sidecar)
O padrão Sidecar se tornou popular com o advento dos microsserviços. Nesse esquema, o componente do aplicativo é implantado em um processo ou contêiner separado. Isso ajuda a obter abstração e encapsulamento.
O Envoy Proxy é um dos proxies secundários mais populares e é amplamente utilizado. Ele ajuda a desacoplar a funcionalidade principal do aplicativo usando uma máquina secundária para isolar funções comuns, como rede, capacidade de observação e segurança.
Este tipo de sidecar pode ajudar no tipo abstrato de comunicação L4 / L7. Sidecars, como Envoy Proxies, ajudam até mesmo a alcançar maior segurança implementando TLS mútuo.
Você pode usar isso em combinação com uma grade de serviços para obter melhor conectividade e segurança entre diferentes microsserviços. Você pode ler mais sobre isso no meu artigo anterior .
Quando usar este padrão
- Quando você está lidando com vários microsserviços heterogêneos em um portfólio de produtos.
- Ao lidar com aplicativos legados que tendem a falhar em lidar com os desafios de interoperabilidade e segurança da nova era.
Quando não usar este padrão
- Quando você está lidando com um número limitado de serviços que precisam se comunicar entre si.
- Pequenas aplicações onde a implantação lateral de cadeiras de rodas pode ser antieconômica ou inconveniente de operar
5. Backend-for-Front (BFF)
Em um ciclo típico de desenvolvimento de produto, os engenheiros de back-end são responsáveis por criar serviços que interagem com data warehouses, enquanto os engenheiros de front-end cuidam da criação de interfaces de usuário. Os aplicativos hoje em dia devem ser desenvolvidos com dispositivos móveis e desktop em mente.
Embora a lacuna entre os dispositivos móveis e desktop esteja se aproximando em termos de hardware, a conectividade e o uso ainda são um desafio para os dispositivos móveis.
Em tais cenários, os modelos de BFF tornam-se bastante úteis. Aqui, espera-se que você crie / configure serviços internos para um front-end específico.
Para otimizar o desempenho de clientes móveis, você pode querer construir um serviço de back-end separado que responda com respostas leves e paginadas.
Você também pode usar esse padrão para agregar vários serviços para reduzir a comunicação de dados entre o back-end e o front-end.
Observação: atualmente, se você estiver usando um gateway de API, o padrão BFF pode ser facilmente implementado no próprio gateway e você não precisará servir serviços separados.
Quando usar este padrão
- Quando você deseja fornecer um produto / serviço a vários clientes, como clientes desktop e móveis.
- Quando você deseja otimizar sua resposta para um tipo específico de cliente.
- Quando você deseja reduzir o bate-papo entre clientes móveis e diferentes serviços.
- , .
- , .
6. Strangler ( )
Se você trabalha para uma organização que está se preparando para modernizar aplicativos, o Strangler Design Pattern é essencial. O padrão Strangler defende a construção de uma sobreposição de fachada em cima de seu legado e novo aplicativo, dando aos consumidores a capacidade de ver as coisas objetivamente.
Esse padrão separa os clientes da atividade de migração entre as partes antigas e novas do aplicativo.
Observação: em uma organização de TI típica, se você estiver migrando de um sistema ERP para outro, esse tipo de esquema será extremamente útil. Se você estiver usando a API do gateway, será mais fácil implementá-la no próprio gateway de proxy.
Você precisa decidir se deseja manter o add-in (fachada) no final da migração ou removê-lo.
Quando usar este padrão
- Quando você está migrando ou atualizando um aplicativo complexo e altamente dependente, como uma migração de ERP
Quando não usar este padrão
- Quando a migração é fácil e a substituição direta é a melhor opção.