Mapeando eShopOnContainers para Serviços do Azure
Gorjeta
Este conteúdo é um excerto do eBook, Architecting Cloud Native .NET Applications for Azure, disponível no .NET Docs ou como um PDF transferível gratuito que pode ser lido offline.
Embora não seja necessário, o Azure é adequado para dar suporte ao eShopOnContainers porque o projeto foi criado para ser um aplicativo nativo da nuvem. O aplicativo é construído com .NET, para que possa ser executado em contêineres Linux ou Windows, dependendo do host Docker. A aplicação é composta por vários microsserviços autónomos, cada um com os seus próprios dados. Os diferentes microsserviços apresentam diferentes abordagens, que vão desde operações CRUD simples até padrões DDD e CQRS mais complexos. Os microsserviços comunicam com os clientes através de HTTP e entre si através de comunicação baseada em mensagens. O aplicativo também suporta várias plataformas para clientes, uma vez que adota HTTP como um protocolo de comunicação padrão e inclui aplicativos móveis ASP.NET Core e Xamarin que rodam em plataformas Android, iOS e Windows.
A arquitetura do aplicativo é mostrada na Figura 2-5. À esquerda estão os aplicativos cliente, divididos em dispositivos móveis, Web tradicional e Web Single Page Application (SPA). À 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 ASP.NET Core MVC mostrado em amarelo. Este aplicativo e os aplicativos SPA móveis e da 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 "backends for front-ends" (BFF), o que significa que cada gateway é projetado para suportar um determinado cliente front-end. Os microsserviços individuais são listados à direita dos gateways de API e incluem lógica de negócios e algum tipo de armazenamento 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 Event Bus do sistema, que é usado para comunicação entre os microsserviços.
Figura 2-5. A arquitetura eShopOnContainers.
Todos os componentes do lado do servidor dessa arquitetura são mapeados facilmente para os serviços do Azure.
Orquestração e agrupamento de contêineres
Os serviços hospedados em contêiner do aplicativo, desde aplicativos MVC ASP.NET Core até microsserviços individuais de Catálogo e Pedidos, podem ser hospedados e gerenciados no Serviço Kubernetes do Azure (AKS). O aplicativo pode ser executado localmente no Docker e no Kubernetes, e os mesmos contêineres podem ser implantados em ambientes de preparação e produção hospedados no AKS. Esse processo pode ser automatizado, como veremos na próxima seção.
A AKS fornece serviços de gerenciamento para clusters individuais de contêineres. O aplicativo implantará contêineres separados para cada microsserviço no cluster AKS, conforme mostrado no diagrama de arquitetura acima. Essa abordagem permite que cada serviço individual seja dimensionado de forma independente 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 zero tempo de inatividade do sistema.
Gateway de API
O aplicativo eShopOnContainers tem vários clientes front-end e vários serviços back-end diferentes. Não há correspondência um-para-um entre os aplicativos cliente e os microsserviços que os suportam. Em tal cenário, pode haver uma grande complexidade ao escrever software cliente para interagir com os vários serviços de back-end de forma segura. Cada cliente precisaria lidar com essa complexidade por conta própria, resultando em duplicação e muitos lugares para fazer atualizações à medida que os serviços mudam ou novas políticas são implementadas.
O Azure API Management (APIM) ajuda as organizações a publicar APIs de forma consistente e gerenciável. O APIM consiste em três componentes: o Gateway de API e o portal de administração (o portal do Azure) e um portal do desenvolvedor.
O API Gateway 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 documentação de 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 a chaves 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, a leve API Gateway Ocelot pode ser usada. O aplicativo eShopOnContainers usa Ocelot por causa de sua simplicidade e porque pode ser implantado no mesmo ambiente de aplicativo que o próprio aplicativo. Saiba mais sobre eShopOnContainers, APIM e jaguatirica.
Outra opção se seu aplicativo estiver usando o AKS é implantar o Controlador de Entrada do Gateway do Azure como um pod dentro do cluster AKS. Essa abordagem permite que seu cluster se integre a um Gateway de Aplicativo do Azure, permitindo que o gateway balanceie a carga do tráfego para os pods AKS. Saiba mais sobre o Azure Gateway Ingress Controller for AKS.
Dados
Os vários serviços de back-end usados pelo eShopOnContainers têm diferentes requisitos de armazenamento. Vários microsserviços usam bancos de dados do 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 suporte a bancos de dados do SQL Server, o Azure tem produtos para tudo, desde bancos de dados únicos até pools elásticos altamente escaláveis do Banco de Dados SQL. Os microsserviços individuais podem ser configurados para se comunicar com seus próprios bancos de dados individuais do 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.
A aplicação eShopOnContainers armazena o cesto de compras atual do utilizador entre pedidos. Esse aspeto é 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 na produção ele pode utilizar o Cache do Azure para Redis. O Cache Redis do Azure é um serviço totalmente gerenciado que oferece alto desempenho e confiabilidade sem a necessidade de implantar e gerenciar instâncias ou contêineres Redis por conta própria.
O microsserviço Locations usa um banco de dados NoSQL MongoDB para sua persistência. Durante o desenvolvimento, o banco de dados pode ser implantado em seu próprio contêiner, enquanto na 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 SQL e APIs NoSQL comuns, incluindo MongoDB, Cassandra, Gremlin e Armazenamento de Tabela do Azure. O Azure Cosmos DB oferece um banco de dados como um serviço totalmente gerenciado e distribuído globalmente que pode ser dimensionado para atender às necessidades dos serviços que o usam.
Os dados distribuídos em aplicativos nativos da nuvem são abordados com mais detalhes no capítulo 5.
Barramento de Eventos
O aplicativo usa eventos para comunicar alterações entre diferentes serviços. Esta 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 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
Uma vez 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.
