Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Dica
Esse conteúdo é um trecho do eBook, Architecting Cloud Native .NET Applications for 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 ao 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, que vão 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 mensagens. 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 ASP.NET aplicativos móveis Core e Xamarin que são executados em plataformas Android, iOS e Windows. (O Xamarin não tem suporte a partir de maio de 2024.)
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 deles 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. Esse aplicativo e os aplicativos móveis e web SPA se comunicam com os microsserviços individuais por meio de um ou mais gateways de API. Os gateways de API seguem o padrão "backend para frontend" (BFF), o que significa que cada gateway foi projetado para suportar um cliente específico de 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 repositório de persistência. Os diferentes serviços usam bancos de dados do SQL Server, instâncias de cache Redis e repositórios do MongoDB/CosmosDB. Na extrema direita está o Barramento de Eventos do sistema, que é usado para comunicação entre os microsserviços.
Figure 2-5. A arquitetura eShopOnContainers.
Os componentes do lado do servidor dessa arquitetura facilmente se integram aos serviços do Azure.
Orquestração e agrupamento de contêineres
Os serviços do aplicativo hospedados em contêiner, desde aplicativos ASP.NET Core MVC até microsserviços individuais de Catálogo e Ordenação, podem ser hospedados e gerenciados no AKS (o 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 zero do sistema.
Gateway de API
O aplicativo eShopOnContainers tem vários clientes front-end e vários serviços de back-end diferentes. Não há correspondência 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 muitos locais para 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 e o portal de administração (o portal do Azure) e um portal do desenvolvedor.
O Gateway de API aceita chamadas de API e as encaminha 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 API Gateway leve Ocelot pode ser usado. O aplicativo eShopOnContainers usa Ocelot devido à sua simplicidade e porque ele pode ser implantado no mesmo ambiente de aplicativo que o 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 dentro do cluster do AKS. Essa abordagem permite que seu cluster se integre a um Gateway de Aplicativo do Azure, permitindo que o gateway balancee o 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 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 ao SQL Server, o Azure oferece produtos para tudo, desde bancos de dados individuais até pools elásticos do Banco de Dados SQL altamente escaláveis. 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.
O aplicativo eShopOnContainers armazena a cesta de compras atual do usuário entre 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 serviços diferentes. 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 em 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 nativa da nuvem no capítulo 6.