Editar

Compartilhar via


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

Aplicativos de Contêiner do Azure
.NET
Banco de Dados SQL do Azure
Azure Cosmos DB
Cache do Azure para Redis

Este artigo descreve uma solução para executar um sistema de gerenciamento de pedidos com 10 microsserviços nos Aplicativos de Contêiner do Azure. A solução também usa práticas recomendadas de microsserviços por meio de Dapr e dimensionamento orientado por eventos com KEDA.

Dapr e Traefik são marcas comerciais de suas respectivas empresas. Nenhum endosso está implícito pelo uso dessas marcas.

Arquitetura

Diagrama que mostra um sistema de gerenciamento de pedidos com microsserviços em Aplicativos de Contêiner.

Baixe um arquivo do PowerPoint dessa arquitetura.

Fluxo de dados

Essa solução usa modelos Bicep para executar a implantação do sistema de gerenciamento de pedidos Reddog e da infraestrutura de suporte do Azure. A arquitetura é composta por um único ambiente de Aplicativos de Contêiner do Azure que hospeda 10 aplicativos de microsserviço .NET Core. Você usará o SDK do Dapr para .NET Core para fazer a integração aos recursos do Azure por meio de blocos de construção de publicação/assinatura (pub/sub) e Estado e Associação. Embora o Dapr normalmente ofereça flexibilidade ao implementar componentes, essa solução é baseada em uma opinião. Os serviços também fazem uso de regras de escala KEDA para permitir o dimensionamento com base em gatilhos de eventos e cenário de dimensionamento zero.

A lista a seguir descreve cada microsserviço e a configuração dos Aplicativos de Contêiner do Azure com os quais ele é implantado. Consulte o Repositório reddog-code no GitHub para visualizar o código.

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

  2. Interface do usuário: um painel que mostra dados de pedidos em tempo real e de vendas agregados para o sistema de gerenciamento de pedidos Reddog.

  3. Cliente virtual: um programa de simulação de cliente que simula clientes fazendo pedidos pelo serviço de pedidos.

  4. Serviço de pedidos: uma API CRUD 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 relevantes que são exibidas pela interface do usuário.

  6. Serviço de recebimento: um programa de arquivamento que gera e armazena recebimentos de pedidos para fins de auditoria e histórico.

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

  8. Serviço Makeline: um serviço responsável por gerenciar a fila dos pedidos atuais que estão aguardando processamento. Ele acompanha o processamento e a conclusão dos pedidos pelo serviço de trabalho virtual.

  9. Trabalho virtual: um programa de simulação de trabalho que simula a conclusão dos pedidos de clientes.

  10. Bootstrapper (não mostrado): um serviço que usa o Entity Framework Core para inicializar as tabelas no Banco de Dados SQL do Azure para uso com o serviço de contabilidade.

Serviço Entrada Componentes do Dapr Regras de escala KEDA
Traefik Externo Dapr não habilitado HTTP
UI Interna Dapr não habilitado HTTP
Cliente virtual Nenhum Invocação serviço a serviço N/D
Ordem de serviço Interna Publicação/assinatura: Barramento de Serviço do Azure HTTP
Serviço de contabilidade Interna Publicação/assinatura: Barramento de Serviço do Azure Tamanho do tópico do Barramento de Serviço do Azure, HTTP
Serviço de recebimento Interna Publicação/assinatura: Barramento de Serviço do Azure
Associação: Blob do Azure
Tamanho do tópico do Barramento de Serviço do Azure
Serviço de fidelidade Interna Publicação/assinatura: Barramento de Serviço do Azure
Estado: Azure Cosmos DB
Tamanho do tópico do Barramento de Serviço do Azure
Serviço Makeline Interna Publicação/assinatura: Barramento de Serviço do Azure
Estado: Azure Redis
Tamanho do tópico do Barramento de Serviço do Azure, HTTP
Trabalho virtual Nenhum Invocação serviço a serviço
Associação: Cron
N/D

Observação

Você também pode executar o Bootstrapper em um aplicativo de contêiner. No entanto, esse serviço é executado uma vez para a criação do banco de dados e, depois, dimensionado para zero depois de criar os objetos necessários no Banco de Dados SQL do Azure.

Componentes

Esta solução usa os seguintes componentes:

  • Os grupos de recursos do Azure são contêineres lógicos para recursos do Azure. Você usa um único grupo de recursos para estruturar tudo relacionado a essa solução no portal do Azure.
  • Os Aplicativos de Contêiner do Azure são um serviço de contêiner totalmente gerenciado e sem servidor usado para criar e implantar aplicativos modernos em escala. Nessa solução, você está hospedando todos os 10 microsserviços nos Aplicativos de Contêiner do Azure e implantando-os em um único ambiente de Aplicativo de Contêiner. Esse ambiente funciona como um limite seguro ao redor do sistema.
  • O Barramento de Serviço do Azure é um agente de mensagens para empresas totalmente gerenciado e completo, com filas e tópicos de publicação/assinatura. Nessa solução, use-o para a implementação do componente de publicação/assinatura Dapr. Vários serviços usam esse componente. O serviço de pedidos publica mensagens no barramento, e os serviços Makeline, de contabilidade, de fidelidade e de recebimento se inscrevem para receber essas mensagens.
  • Azure Cosmos DB é um serviço de banco de dados gerenciado e multimodelo NoSQL. Use-o como componente de armazenamento de estado Dapr para o serviço de fidelidade armazenar os dados de fidelidade do cliente.
  • Cache do Azure para Redis é um cache Redis gerenciado distribuído, na memória e escalonável. 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 Banco de Dados SQL do Azure é um serviço de banco de dados inteligente, escalonável, relacional desenvolvido para a nuvem. Crie-o 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 por configurar as tabelas SQL no banco de dados e, em seguida, é executado uma vez antes de estabelecer a conexão com o serviço de contabilidade.
  • O Armazenamento de Blobs do Azure armazena enormes quantidades de dados não estruturados, como arquivos binários ou de texto. O serviço de recebimento usa o Armazenamento de Blobs por meio de uma associação de saída Dapr para armazenar os recebimentos de pedidos.
  • O Traefik é um proxy reverso moderno e balanceador de carga que facilita a implantação de microsserviços. Nessa solução, 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 (SPA) Vue.js. Essa configuração também permite chamadas de API diretas para os serviços de back-end, para fins de teste.
  • O Azure Monitor permite coletar, analisar e tomar medidas com base nos dados de conteúdo do cliente em seus ambientes de infraestrutura do Azure. Use-o com o Application Insights para ver os logs de contêiner e coletar métricas dos microsserviços.

Alternativas

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

Toda a infraestrutura do Azure, exceto o Banco de Dados SQL do Azure, usa componentes do Dapr para interoperabilidade. Um dos benefícios do Dapr é que você pode trocar todos esses componentes alterando a configuração da implantação de aplicativos de contêiner. Nesse caso, o Barramento de Serviço do Azure, o Azure Cosmos DB, o Cache para Redis e o Armazenamento de Blobs foram escolhidos para demonstrar alguns dos mais de 70 componentes do Dapr disponíveis. Uma lista de agentes de publicação/assinatura, armazenamentos de estado e associações de saída alternativos está disponível na documentação do Dapr.

Detalhes do cenário

Os microsserviços são um estilo de arquitetura cada vez mais popular que pode ter muitos benefícios, como alta escalabilidade, ciclos de desenvolvimento mais curtos e mais simplicidade. Você pode usar contêineres como 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 que precisam ser considerados para as arquiteturas de microsserviços em grande escala. Normalmente, a plataforma de infraestrutura requer um conhecimento relevante de tecnologias complexas, como os orquestradores de contêineres.

Os Aplicativos de Contêiner do Azure são um serviço de contêiner sem servidor e totalmente gerenciado para executar aplicativos modernos em escala. O serviço permite implantar aplicativos conteinerizados por meio da abstração da plataforma subjacente. Dessa forma, você não precisará gerenciar uma infraestrutura complicada. Os Aplicativos de Contêiner do Azure usam tecnologias de código aberto.

Essa arquitetura usa a integração dos Aplicativos de Contêiner do Azure com uma versão gerenciada do Dapr (Distributed Application Runtime). O Dapr é um projeto de código aberto que ajuda os desenvolvedores com os desafios inerentes de aplicativos distribuídos, como gerenciamento de estado e invocação de serviço.

Os Aplicativos de Contêiner do Azure também fornecem uma versão gerenciada do KEDA (Kubernetes Event-Driven Autoscaling). O KEDA permite que os contêineres sejam dimensionados automaticamente com base em eventos recebidos de serviços externos, como o Barramento de Serviço do Azure e o Cache do Azure para Redis.

Também é possível habilitar a entrada HTTPS nos Aplicativos de Contêiner do Azure 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 explorar uma comparação entre os Aplicativos de Contêiner do Azure e outras plataformas de hospedagem de contêiner no Azure, consulte Comparação de 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 com 10 microsserviços nos Aplicativos de Contêiner do Azure. A solução também usa práticas recomendadas de microsserviços por meio de Dapr e dimensionamento orientado por eventos com KEDA.

Possíveis casos de uso

Essa solução se aplica a qualquer organização que use microsserviços sem estado e com estado para sistemas distribuídos. A solução é ideal para os setores de bens de consumo embalados e manufatura que tenham um sistema de pedidos e processamento.

Estas outras soluções têm designs semelhantes:

  • Arquitetura de microsserviços no AKS (Serviço de Kubernetes do Azure)
  • Arquitetura de microsserviços no Azure Functions
  • Arquiteturas orientadas por eventos

Considerações

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

Confiabilidade

A confiabilidade garante que seu aplicativo possa cumprir os compromissos que você assume com seus clientes. Para obter mais informações, confira Visão geral do pilar de confiabilidade.

Os Aplicativos de Contêiner do Azure são executados no Kubernetes em segundo plano. Mecanismos de resiliência são incorporados ao Kubernetes para monitorar e reiniciar os contêineres, ou pods, se ocorrer algum problema. Os mecanismos de resiliência se combinam com o balanceador de carga interno para executar várias réplicas de cada aplicativo de contêiner. Com essa redundância, a solução pode tolerar que uma instância fique indisponível.

Você pode usar o Azure Monitor e o Application Insights para monitorar Aplicativos de Contêiner do Azure. Você pode ver logs de contêiner navegando no portal até o painel Logs de cada aplicativo de contêiner e, depois, executar a consulta Kusto a seguir. Esse exemplo mostra logs do 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 de aplicativos no Application Insights também mostra como os serviços se comunicam em tempo real. Você pode usá-los para cenários de depuração. Navegue até o mapa de aplicativos no recurso Application Insights para ver algo parecido com o seguinte.

Captura de tela que mostra um mapa de aplicativo no Application Insights.

Para obter mais informações sobre como monitorar Aplicativos de Contêiner do Azure, consulte Monitorar um aplicativo nos Aplicativos de Contêiner do Azure.

Otimização de custo

Otimize custos analisando maneiras de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

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

Eficiência de desempenho

A eficiência do desempenho é a capacidade de escalar a carga de trabalho para atender às demandas com eficiência. Para obter mais informações, consulte Visão geral do pilar de eficiência de desempenho.

Essa solução depende muito da implementação do KEDA nos Aplicativos de Contêiner do Azure para dimensionamento orientado por eventos. Quando você implantar o atendimento ao cliente virtual, ele fará pedidos continuamente, o que faz com que o serviço de pedidos escale verticalmente por meio do dimensionador HTTP KEDA. Conforme o serviço de pedidos publica os pedidos no barramento de serviço, os dimensionadores KEDA do barramento de serviço escalam os serviços de contabilidade, recebimento, Makeline e fidelidade verticalmente. A interface do usuário e os aplicativos de contêiner 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 nessa solução são dimensionados para zero, com exceção dos serviços trabalho virtual e Makeline. O trabalho virtual não reduz verticalmente, pois está constantemente verificando o processamento de pedidos. Para obter mais informações sobre dimensionamento em aplicativos de contêiner, consulte Definir regras de dimensionamento em Aplicativos de Contêiner do Azure. Para obter mais informações sobre dimensionadores KEDA, leia a documentação do KEDA sobre dimensionadores.

Implantar este cenário

Para obter instruções de implantação, consulte a Demonstração do Reddog: implantação dos Aplicativos de Contêiner do Azure no GitHub.

A Demonstração do Reddog: integração a microsserviços é um modelo de aplicativo empacotado que se baseia nos ativos de código anteriores para demonstrar a integração dos Aplicativos de Contêiner do Azure, do Serviço de Aplicativo, do Functions e do Gerenciamento de API e provisiona a infraestrutura e implanta o código usando GitHub Actions.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

Outros colaboradores:

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas