Implantar microsserviços com Aplicativos de Contêiner do Azure e Dapr

Este artigo descreve uma solução para executar um sistema de gerenciamento de pedidos que tem 10 microsserviços nos Aplicativos de Contêiner do Azure. A solução também usa práticas recomendadas de microsserviços por meio do Distributed Application Runtime (Dapr) e do dimensionamento controlado por eventos com o Kubernetes event-driven autoscaling (KEDA).

Dapr e Traefik são marcas comerciais de suas respetivas empresas. O uso destas marcas não implica qualquer endosso.

Arquitetura

Transfira um ficheiro PowerPoint desta arquitetura.

Fluxo de dados

Esta solução descreve um sistema fictício de gestão de encomendas Red Dog e a sua infraestrutura de suporte do Azure. A arquitetura é composta por um único ambiente de Aplicativos de Contêiner que hospeda 10 aplicativos de microsserviço .NET Core. A solução usa o SDK do Dapr para se integrar aos recursos do Azure por meio de blocos de construção de publicação-assinatura, estado e vinculação. Os serviços também usam regras de escala KEDA para permitir o dimensionamento com base em gatilhos de eventos e cenários de escala para zero.

O seguinte fluxo de dados corresponde ao diagrama anterior:

1. Traefik: O proxy básico para rotear solicitações de usuário da interface do usuário para os serviços de contabilidade e Makeline para o painel interativo.

2. UI: Um painel que mostra dados de pedidos e vendas agregados em tempo real para o sistema de gerenciamento de pedidos Red Dog.

3. Cliente virtual: um programa de simulação de clientes que simula clientes que fazem pedidos através do serviço de pedidos.

4. Serviço de encomendas: Uma API de criação, leitura, atualização e exclusão para fazer e gerenciar pedidos.

5. Serviço de contabilidade: um serviço que processa, armazena e agrega dados de pedidos. Ele transforma os pedidos dos clientes em métricas de vendas significativas que a interface do usuário apresenta.

6. Serviço de recebimento: Um programa de arquivo que gera e armazena recibos de pedidos para fins de auditoria e histórico.

7. Serviço de fidelidade: um serviço que gerencia o programa de fidelidade rastreando os pontos de recompensa do cliente com base nos gastos do pedido.

8. Serviço Makeline: Um serviço que gerencia uma fila de pedidos atuais aguardando para serem atendidos. Ele rastreia o processamento e a conclusão dos pedidos pelo serviço de trabalhador virtual.

9. Trabalhador virtual: um programa de simulação de trabalhador que simula a conclusão de pedidos de clientes.

Componentes

• O Application Insights é um serviço extensível de gerenciamento de desempenho de aplicativos que você pode usar para monitorar aplicativos ativos e detetar automaticamente anomalias de desempenho. Nessa arquitetura, você usa o Application Insights com o Azure Monitor para exibir os logs de contêiner e coletar métricas dos microsserviços.

• O Blob Storage é uma solução baseada na nuvem para armazenar grandes quantidades de dados não estruturados, como texto ou arquivos binários. Nessa arquitetura, um serviço de recebimento usa o Armazenamento de Blob por meio de uma vinculação de saída Dapr para armazenar os recibos de pedidos.

• O Cache Redis do Azure é um cache Redis gerenciado distribuído, na memória e escalável. Nessa arquitetura, ele é usado como um componente de armazenamento de estado Dapr para o serviço Makeline armazenar dados sobre os pedidos que estão sendo processados.

• O Azure Cosmos DB é um serviço de banco de dados gerenciado de vários modelos NoSQL. Nessa arquitetura, ele é usado como um componente de armazenamento de estado Dapr para o serviço de fidelidade para armazenar os dados de fidelidade dos clientes.

• O Azure Monitor é uma plataforma unificada que permite coletar, analisar e agir sobre dados de conteúdo do cliente de seus ambientes de infraestrutura do Azure. Nessa arquitetura, você usa o Azure Monitor com o Application Insights para exibir os logs de contêiner e coletar métricas dos microsserviços.

• O Service Bus é um agente de mensagens empresariais totalmente gerenciado que tem filas e tópicos de publicação-assinatura. Nessa arquitetura, você usa o Service Bus para a implementação do componente publish-subscribe do Dapr. Vários serviços usam esse componente. O serviço de pedidos publica mensagens no ônibus, e os serviços Makeline, contabilidade, lealdade e recebimento assinam essas mensagens.

• O Container Apps é um serviço de contêiner totalmente gerenciado e sem servidor usado para criar e implantar aplicativos modernos em escala. Nessa arquitetura, você hospeda todos os 10 microsserviços em Aplicativos de Contêiner e os implanta em um único ambiente de Aplicativos de Contêiner. Este ambiente serve como um limite seguro em torno do sistema.

• O Banco de Dados SQL é um serviço de banco de dados relacional, escalável e inteligente criado para a nuvem. Nessa arquitetura, ele serve como o armazenamento de dados para o serviço de contabilidade, que usa o Entity Framework Core para interagir com o banco de dados. O serviço bootstrapper é responsável pela configuração das tabelas SQL no banco de dados. Em seguida, ele é executado uma vez antes de estabelecer a conexão com o serviço de contabilidade.

• Traefik é um proxy reverso e balanceador de carga usado para rotear o tráfego de rede para microsserviços. Nessa arquitetura, use o recurso de configuração dinâmica do Traefik para fazer o roteamento baseado em caminho a partir da interface do usuário, que é um aplicativo de página única Vue.js. Essa configuração também permite chamadas diretas de API para os serviços back-end para teste.

Alternativas

Nessa arquitetura, você implanta um proxy Traefik para habilitar o roteamento baseado em caminho para a API Vue.js. Existem muitos proxies alternativos de código aberto que você pode usar para essa finalidade. Dois outros projetos comuns são NGINX e HAProxy.

Toda a infraestrutura do Azure, exceto o Banco de Dados SQL, usa componentes Dapr para interoperabilidade. Um benefício do Dapr é que você pode trocar todos esses componentes alterando a configuração de implantação de aplicativos de contêiner. Nesse cenário, o Service Bus, o Azure Cosmos DB, o Cache do Azure para Redis e o Armazenamento de Blob exibem alguns dos mais de 70 componentes Dapr disponíveis. Uma lista de corretores alternativos de publicação-assinatura, armazenamentos de estado e ligações de saída estão disponíveis nos documentos do Dapr.

Detalhes do cenário

Os microsserviços são um estilo arquitetônico amplamente adotado. Eles fornecem benefícios como escalabilidade, agilidade e implantações independentes. Você pode usar contêineres como um mecanismo para implantar aplicativos de microsserviços e, em seguida, usar um orquestrador de contêineres como o Kubernetes para simplificar as operações. Há muitos fatores a considerar para arquiteturas de microsserviços em grande escala. Normalmente, a plataforma de infraestrutura requer uma compreensão significativa de tecnologias complexas, como orquestradores de contêineres.

O Container Apps é um serviço de contêiner sem servidor totalmente gerenciado para executar aplicativos modernos em escala. Ele permite que você implante aplicativos em contêineres por meio de uma abstração da plataforma subjacente. Usando esse método, você não precisa gerenciar uma infraestrutura complicada.

Essa arquitetura usa a integração de aplicativos de contêiner com uma versão gerenciada do Dapr. O Dapr é um projeto de código aberto que ajuda os desenvolvedores a superar os desafios inerentes em aplicativos distribuídos, como gerenciamento de estado e invocação de serviços.

Container Apps também fornece uma versão gerenciada do KEDA. O KEDA permite que seus contêineres sejam dimensionados automaticamente com base em eventos de entrada de serviços externos, como o Service Bus e o Cache do Azure para Redis.

Você também pode habilitar a entrada HTTPS em Aplicativos de Contêiner sem criar mais recursos de rede do Azure. Você pode usar o proxy Envoy, que também permite cenários de divisão de tráfego.

Para obter mais informações, consulte Comparar aplicativos de contêiner com outras opções de contêiner do Azure.

Este artigo descreve uma solução para executar um sistema de gerenciamento de pedidos que tem 10 microsserviços em aplicativos de contêiner. A solução também usa as melhores práticas de microsserviços por meio do Dapr e do dimensionamento controlado por eventos com o KEDA.

Potenciais casos de utilização

Esta solução aplica-se a qualquer organização que utilize microsserviços sem estado e com monitoração de estado para sistemas distribuídos. A solução é melhor para bens de consumo embalados e indústrias de fabricação que têm um sistema de pedidos e atendimento.

As seguintes soluções têm designs semelhantes:

• Arquitetura de microsserviços no Azure Kubernetes Service (AKS)
• Arquitetura de microsserviços no Azure Functions
• Arquiteturas orientadas a eventos

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que você pode usar para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Well-Architected Framework.

Fiabilidade

A confiabilidade ajuda a garantir que seu aplicativo possa cumprir os compromissos que você assume com seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para Confiabilidade.

O Container Apps é construído sobre uma base do Kubernetes, que opera como a infraestrutura subjacente. Os mecanismos de resiliência são incorporados ao Kubernetes que monitoram e reiniciam contêineres, ou pods, se houver problemas. Os mecanismos de resiliência incluem um balanceador de carga interno que distribui o tráfego entre várias réplicas de cada aplicativo de contêiner. Essa redundância permite que o sistema permaneça operacional, mesmo que uma réplica fique indisponível.

Segurança

A segurança fornece garantias contra ataques deliberados e o uso indevido de seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação de revisão de design para segurança.

A lista a seguir descreve vários recursos de segurança que são omitidos nessa arquitetura, juntamente com outras recomendações e considerações:

• Essa arquitetura não usa pontos de extremidade privados, que permitem uma conectividade mais segura e privada aos serviços do Azure, atribuindo-lhes um endereço IP da sua rede virtual. Quando pontos de extremidade privados são usados, o acesso à rede pública pode ser desativado. Essa abordagem mantém o tráfego no backbone da Microsoft e aprimora a segurança e a conformidade.

• A atividade da rede deve ser monitorizada continuamente para detetar e prevenir abusos. Você pode obter essa abordagem usando um Firewall do Azure e tabelas de rotas. As tabelas de rotas permitem que o tráfego que sai de uma rede virtual seja passado primeiro pelo firewall. Esse processo é uma etapa importante para garantir que sua arquitetura não fique vulnerável a ataques de exfiltração de dados.

• Use um firewall de aplicativo da Web (WAF) para se proteger contra vulnerabilidades comuns. Use o Azure Front Door ou o Azure Application Gateway para implementar um WAF nessa arquitetura.

• Considere usar o recurso interno de autenticação e autorização para aplicativos de contêiner, conhecido como Easy Auth. O Easy Auth lida com a integração com provedores de identidade fora do seu aplicativo Web, o que pode reduzir a quantidade de código que você precisa manter.

• Use a identidade gerenciada para identidades de carga de trabalho. A identidade gerenciada elimina a necessidade de os desenvolvedores gerenciarem credenciais de autenticação. Por exemplo, a arquitetura básica autentica no SQL Server por meio de senha em uma cadeia de conexão. Quando possível, use IDs do Microsoft Entra para autenticar no SQL Server do Azure.

Otimização de Custos

A Otimização de Custos concentra-se em formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de projeto para Otimização de custos.

Use a calculadora de preços do Azure para estimar o custo dos serviços nessa arquitetura.

Excelência Operacional

A Excelência Operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Lista de verificação de revisão de design para excelência operacional.

Você pode usar o Azure Monitor e o Application Insights para monitorar Aplicativos de Contêiner. Você pode exibir logs de contêiner navegando no portal até o painel Logs em cada aplicativo de contêiner e, em seguida, executando a seguinte consulta Kusto. Este exemplo mostra logs para o aplicativo de serviço Makeline.

ContainerAppConsoleLogs_CL |
    where ContainerAppName_s contains "make-line-service" |
    project TimeGenerated, _timestamp_d, ContainerGroupName_s, Log_s |
    order by _timestamp_d asc

O mapa do aplicativo no Application Insights também mostra como os serviços se comunicam em tempo real. Em seguida, você pode usá-los para depurar cenários. Navegue até o mapa do aplicativo no recurso do Application Insights para exibir algo como o mapa a seguir.

Para obter mais informações, consulte Monitorar um aplicativo em aplicativos de contêiner.

Eficiência de desempenho

A Eficiência de Desempenho refere-se à capacidade da sua carga de trabalho de escalar para atender às demandas dos usuários de forma eficiente. Para obter mais informações, consulte Lista de verificação de revisão de design para Eficiência de desempenho.

Essa solução depende muito da implementação KEDA em Container Apps para dimensionamento controlado por eventos. Quando você implanta o atendimento virtual ao cliente, ele faz pedidos continuamente. Esse dimensionamento faz com que o serviço de pedidos seja dimensionado por meio do escalador HTTP KEDA. À medida que o serviço de pedidos publica os pedidos no barramento de serviço, os escaladores KEDA do barramento de serviço fazem com que os serviços de contabilidade, recebimento, Makeline e fidelidade aumentem. Os aplicativos de contêiner UI e Traefik também configuram escaladores HTTP KEDA para que os aplicativos sejam dimensionados à medida que mais usuários acessam o painel.

Quando o cliente virtual não está em execução, todos os microsserviços nesta solução são dimensionados para zero, exceto os serviços de trabalhador virtual e Makeline. O trabalhador virtual não diminui porque verifica continuamente o cumprimento de pedidos. Para obter mais informações, consulte Definir regras de dimensionamento em aplicativos de contêiner.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Autor principal:

• Alice Gibbons - Brasil | Black Belt Global Nativa da Nuvem

Outros contribuidores:

• Lynn Orrell - Brasil | Especialista Principal de Soluções (GBB)
• Kendall Roden - Brasil | Gerente de Programa Sênior

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Próximos passos

• Documentos de aplicativos de contêiner
• Comparar aplicativos de contêiner com outras opções de contêiner do Azure

Recursos relacionados

• Arquitetura de microsserviços no AKS
• Arquitetura avançada de microsserviços AKS
• Integração contínua e entrega contínua para aplicativos AKS com o Azure Pipelines