Como mapear o eShopOnContainers para os Serviços do Azure
Dica
Esse conteúdo é um trecho do livro eletrônico, para Projetar os Aplicativos .NET nativos de nuvem para o Azure, disponível no .NET Docs ou como um PDF para download gratuito que pode ser lido offline.
Embora não seja necessário, o Azure é adequado para dar suporte aos eShopOnContainers porque o projeto foi criado para ser um aplicativo nativo de nuvem. O aplicativo é criado com o .NET, portanto, ele pode ser executado em contêineres do Linux ou do Windows, dependendo do host do Docker. O aplicativo é composto por vários microsserviços autônomos, cada um com seus próprios dados. Os diferentes microsserviços mostram diferentes abordagens, desde operações CRUD simples até padrões de DDD e CQRS mais complexos. Os microsserviços se comunicam com clientes por HTTP e entre si por meio da comunicação baseada em mensagem. O aplicativo também dá suporte a várias plataformas para clientes, pois adota HTTP como um protocolo de comunicação padrão e inclui aplicativos móveis ASP.NET Core e Xamarin que são executados em plataformas Android, iOS e Windows.
A arquitetura do aplicativo é mostrada na Figura 2-5. À esquerda estão os aplicativos cliente, divididos em tipos móveis, web tradicionais e SPA (Aplicativo de Página Única da Web). À direita estão os componentes do lado do servidor que compõem o sistema, cada um dos quais pode ser hospedado em contêineres do Docker e clusters do Kubernetes. O aplicativo Web tradicional é alimentado pelo aplicativo MVC ASP.NET Core mostrado em amarelo. Esse aplicativo e os aplicativos de SPA móvel e Web se comunicam com os microsserviços individuais por meio de um ou mais gateways de API. Os gateways de API seguem o padrão "back-ends para front-ends" (BFF), o que significa que cada gateway foi projetado para dar suporte a um determinado cliente front-end. Os microsserviços individuais são listados à direita dos gateways de API e incluem a lógica de negócios e algum tipo de repositório de persistência. Os diferentes serviços usam bancos de dados SQL Server, instâncias de cache Redis e repositórios MongoDB/CosmosDB. Na extrema direita está o Barramento de Eventos do sistema, que é usado para comunicação entre os microsserviços.
Figura 2-5. A arquitetura eShopOnContainers.
Os componentes do lado do servidor dessa arquitetura são mapeados facilmente para os serviços do Azure.
Orquestração e clustering de contêiner
Os serviços hospedados em contêiner do aplicativo, desde aplicativos MVC do ASP.NET Core até microsserviços individuais de Catálogo e Ordenação, podem ser hospedados e gerenciados no AKS (Serviço de Kubernetes do Azure). O aplicativo pode ser executado localmente no Docker e no Kubernetes, e os mesmos contêineres podem ser implantados em ambientes de preparo e produção hospedados no AKS. Esse processo pode ser automatizado como veremos na próxima seção.
O AKS fornece serviços de gerenciamento para clusters individuais de contêineres. O aplicativo implantará contêineres separados para cada microsserviço no cluster do AKS, conforme mostrado no diagrama de arquitetura acima. Essa abordagem permite que cada serviço individual seja dimensionado independentemente de acordo com suas demandas de recursos. Cada microsserviço também pode ser implantado de forma independente e, idealmente, essas implantações devem incorrer em tempo de inatividade do sistema zero.
Gateway de API
O aplicativo eShopOnContainers tem vários clientes front-end e vários serviços de back-end diferentes. Não há nenhuma correspondência de um para um entre os aplicativos cliente e os microsserviços que dão suporte a eles. Nesse cenário, pode haver muita complexidade ao escrever software cliente para interface com os vários serviços de back-end de maneira segura. Cada cliente precisaria lidar com essa complexidade por conta própria, resultando em duplicação e em muitos locais nos quais fazer atualizações à medida que os serviços mudam ou novas políticas são implementadas.
O APIM (Gerenciamento de API do Azure) ajuda as organizações a publicar APIs de forma consistente e gerenciável. O APIM consiste em três componentes: o Gateway de API, o portal de administração (o portal do Azure) e um portal do desenvolvedor.
O Gateway de API aceita chamadas de API e as roteia para a API de back-end apropriada. Ele também pode fornecer serviços adicionais, como verificação de chaves de API ou tokens JWT e transformação de API em tempo real sem modificações de código (por exemplo, para acomodar clientes que esperam uma interface mais antiga).
O portal do Azure é onde você define o esquema de API e empacota APIs diferentes em produtos. Você também configura o acesso do usuário, exibe relatórios e configura políticas para cotas ou transformações.
O portal do desenvolvedor serve como o principal recurso para desenvolvedores. Ele fornece aos desenvolvedores a documentação da API, um console de teste interativo e relatórios sobre seu próprio uso. Os desenvolvedores também usam o portal para criar e gerenciar suas próprias contas, incluindo assinatura e suporte à chave de API.
Usando o APIM, os aplicativos podem expor vários grupos diferentes de serviços, cada um fornecendo um back-end para um cliente front-end específico. O APIM é recomendado para cenários complexos. Para necessidades mais simples, o Ocelot do Gateway de API leve pode ser usado. O aplicativo eShopOnContainers usa o Ocelot devido à sua simplicidade e porque ele pode ser implantado no mesmo ambiente de aplicativo do próprio aplicativo. Saiba mais sobre eShopOnContainers, APIM e Ocelot.
Outra opção se o aplicativo estiver usando o AKS é implantar o Controlador de Entrada do Gateway do Azure como um pod no cluster do AKS. Essa abordagem permite que o cluster se integre a um Gateway de Aplicativo do Azure, permitindo que o gateway balanceie a carga do tráfego para os pods do AKS. Saiba mais sobre o Controlador de Entrada do Gateway do Azure para AKS.
Dados
Os vários serviços de back-end usados pelo eShopOnContainers têm requisitos de armazenamento diferentes. Vários microsserviços usam bancos de dados SQL Server. O microsserviço Basket aproveita um cache Redis para sua persistência. O microsserviço Locations espera uma API do MongoDB para seus dados. O Azure dá suporte a cada um desses formatos de dados.
Para o suporte a banco de dados SQL Server, o Azure tem produtos para tudo, desde bancos de dados individuais até pools elásticos de Banco de Dados SQL altamente escalonáveis. Os microsserviços individuais podem ser configurados para se comunicar com seus próprios bancos de dados individuais SQL Server de forma rápida e fácil. Esses bancos de dados podem ser dimensionados conforme necessário para dar suporte a cada microsserviço separado, de acordo com suas necessidades.
O aplicativo eShopOnContainers armazena a cesta de compras atual do usuário entre as solicitações. Esse aspecto é gerenciado pelo microsserviço Basket que armazena os dados em um cache Redis. No desenvolvimento, esse cache pode ser implantado em um contêiner, enquanto em produção ele pode utilizar o Cache do Azure para Redis. O Cache do Azure para Redis é um serviço totalmente gerenciado que oferece alto desempenho e confiabilidade sem a necessidade de implantar e gerenciar instâncias ou contêineres do Redis por conta própria.
O microsserviço Locations usa um banco de dados NoSQL do MongoDB para sua persistência. Durante o desenvolvimento, o banco de dados pode ser implantado em seu próprio contêiner, enquanto em produção o serviço pode aproveitar a API do Azure Cosmos DB para MongoDB. Um dos benefícios do Azure Cosmos DB é sua capacidade de aproveitar vários protocolos de comunicação diferentes, incluindo uma API do SQL e APIs NoSQL comuns, incluindo MongoDB, Cassandra, Gremlin e Armazenamento de Tabelas do Azure. O Azure Cosmos DB oferece um banco de dados totalmente gerenciado e distribuído globalmente como um serviço que pode ser dimensionado para atender às necessidades dos serviços que o usam.
Os dados distribuídos em aplicativos nativos de nuvem são abordados com mais detalhes no capítulo 5.
Barramento de evento
O aplicativo usa eventos para comunicar alterações entre diferentes serviços. Essa funcionalidade pode ser implementada com várias implementações e, localmente, o aplicativo eShopOnContainers usa RabbitMQ. Quando hospedado no Azure, o aplicativo aproveitaria o Barramento de Serviço do Azure para suas mensagens. O Barramento de Serviço do Azure é um agente de mensagens de integração totalmente gerenciado que permite que aplicativos e serviços se comuniquem entre si de maneira desacoplada, confiável e assíncrona. O Barramento de Serviço do Azure dá suporte a filas individuais, bem como a tópicos separados para dar suporte a cenários de editor-assinante. O aplicativo eShopOnContainers aproveitaria tópicos com o Barramento de Serviço do Azure para dar suporte à distribuição de mensagens de um microsserviço para qualquer outro microsserviço que precisasse reagir a uma determinada mensagem.
Resiliência
Depois de implantado na produção, o aplicativo eShopOnContainers poderá aproveitar vários serviços do Azure disponíveis para melhorar sua resiliência. O aplicativo publica verificações de integridade, que podem ser integradas ao Application Insights para fornecer relatórios e alertas com base na disponibilidade do aplicativo. Os recursos do Azure também fornecem logs de diagnóstico que podem ser usados para identificar e corrigir bugs e problemas de desempenho. Os logs de recursos fornecem informações detalhadas sobre quando e como diferentes recursos do Azure são usados pelo aplicativo. Você aprenderá mais sobre os recursos de resiliência nativos da nuvem no capítulo 6.
