Comunicação com o cliente front-end

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.

Descarregar PDF

Em um sistema nativo da nuvem, os clientes front-end (aplicativos móveis, da Web e de desktop) exigem um canal de comunicação para interagir com microsserviços back-end independentes.

Quais são as opções?

Para simplificar, um cliente front-end pode se comunicar diretamente com os microsserviços back-end, mostrados na Figura 4-2.

Figura 4-2. Comunicação direta do cliente ao serviço

Com essa abordagem, cada microsserviço tem um ponto de extremidade público que é acessível por clientes front-end. Em um ambiente de produção, você colocaria um balanceador de carga na frente dos microsserviços, roteando o tráfego proporcionalmente.

Embora simples de implementar, a comunicação direta com o cliente seria aceitável apenas para aplicativos de microsserviços simples. Esse padrão une fortemente os clientes front-end aos principais serviços de back-end, abrindo a porta para muitos problemas, incluindo:

• Suscetibilidade do cliente à refatoração de serviços de back-end.
• Uma superfície de ataque mais ampla à medida que os principais serviços de back-end são diretamente expostos.
• Duplicação de preocupações transversais em cada microsserviço.
• Código de cliente excessivamente complexo - os clientes devem acompanhar vários endpoints e lidar com falhas de forma resiliente.

Em vez disso, um padrão de design de nuvem amplamente aceito é implementar um Serviço de Gateway de API entre os aplicativos front-end e os serviços back-end. O padrão é mostrado na Figura 4-3.

Figura 4-3. Padrão de gateway de API

Na figura anterior, observe como o serviço API Gateway abstrai os microsserviços principais de back-end. Implementado como uma API web, ele atua como um proxy reverso, roteando o tráfego de entrada para os microsserviços internos.

O gateway isola o cliente do particionamento e refatoração de serviços internos. Se você alterar um serviço de back-end, poderá acomodá-lo no gateway sem quebrar o cliente. É também a sua primeira linha de defesa para preocupações transversais, como identidade, cache, resiliência, medição e limitação. Muitas dessas preocupações transversais podem ser descarregadas dos serviços principais de back-end para o gateway, simplificando os serviços de back-end.

É preciso ter cuidado para manter o API Gateway simples e rápido. Normalmente, a lógica de negócios é mantida fora do gateway. Uma porta de entrada complexa corre o risco de se tornar um gargalo e, eventualmente, um monólito. Sistemas maiores geralmente expõem vários gateways de API segmentados por tipo de cliente (móvel, web, desktop) ou funcionalidade de back-end. O padrão Backend para Frontends fornece orientação para a implementação de vários gateways. O padrão é mostrado na Figura 4-4.

Figura 4-4. Backend para padrão de frontend

Observe na figura anterior como o tráfego de entrada é enviado para um gateway de API específico - com base no tipo de cliente: aplicativo Web, móvel ou de desktop. Essa abordagem faz sentido, pois os recursos de cada dispositivo diferem significativamente entre as limitações de fator de forma, desempenho e exibição. Normalmente, os aplicativos móveis expõem menos funcionalidade do que um navegador ou aplicativos de desktop. Cada gateway pode ser otimizado para corresponder às capacidades e funcionalidades do dispositivo correspondente.

Gateways simples

Para começar, você pode criar seu próprio serviço API Gateway. Uma pesquisa rápida no GitHub fornecerá muitos exemplos.

Para aplicativos simples nativos da nuvem .NET, você pode considerar o Ocelot Gateway. Open source e criado para microsserviços .NET, é leve, rápido e escalável. Como qualquer API Gateway, sua principal funcionalidade é encaminhar solicitações HTTP de entrada para serviços downstream. Além disso, ele suporta uma ampla variedade de recursos que são configuráveis em um pipeline de middleware .NET.

YARP (Yet Another Reverse proxy) é outro proxy reverso de código aberto liderado por um grupo de equipes de produto da Microsoft. Transferível como um pacote NuGet, o YARP liga-se à estrutura ASP.NET como middleware e é altamente personalizável. Você encontrará o YARP bem documentado com vários exemplos de uso.

Para aplicativos corporativos nativos da nuvem, há vários serviços gerenciados do Azure que podem ajudar a impulsionar seus esforços.

Gateway de Aplicação do Azure

Para requisitos de gateway simples, você pode considerar o Gateway de Aplicativo do Azure. Disponível como um serviço PaaS do Azure, ele inclui recursos básicos de gateway, como roteamento de URL, terminação SSL e um Firewall de Aplicativo Web. O serviço suporta recursos de balanceamento de carga de Camada 7. Com a Camada 7, você pode rotear solicitações com base no conteúdo real de uma mensagem HTTP, não apenas pacotes de rede TCP de baixo nível.

Ao longo deste livro, evangelizamos a hospedagem de sistemas nativos da nuvem no Kubernetes. Um orquestrador de contêineres, o Kubernetes automatiza a implantação, o dimensionamento e as preocupações operacionais de cargas de trabalho em contêineres. O Gateway de Aplicativo do Azure pode ser configurado como um gateway de API para o cluster do Serviço Kubernetes do Azure.

O Application Gateway Ingress Controller permite que o Gateway de Aplicativo do Azure trabalhe diretamente com o Serviço Kubernetes do Azure. A Figura 4.5 mostra a arquitetura.

Figura 4-5. Controlador de Entrada do Gateway de Aplicação

O Kubernetes inclui um recurso interno que suporta balanceamento de carga HTTP (Nível 7), chamado Ingress. O Ingress define um conjunto de regras para como as instâncias de microsserviço dentro do AKS podem ser expostas ao mundo exterior. Na imagem anterior, o controlador de entrada interpreta as regras de entrada configuradas para o cluster e configura automaticamente o Gateway de Aplicativo do Azure. Com base nessas regras, o Application Gateway roteia o tráfego para microsserviços executados dentro do AKS. O controlador de entrada escuta as alterações nas regras de entrada e faz as alterações apropriadas no Gateway de Aplicativo do Azure.

API Management do Azure

Para sistemas nativos da nuvem de escala moderada a grande, você pode considerar o Gerenciamento de API do Azure. É um serviço baseado em nuvem que não apenas resolve suas necessidades de API Gateway, mas fornece uma experiência administrativa e de desenvolvedor completa. O Gerenciamento de API é mostrado na Figura 4-6.

Figura 4-6. API Management do Azure

Para começar, o Gerenciamento de API expõe um servidor gateway que permite acesso controlado a serviços back-end com base em regras e políticas configuráveis. Esses serviços podem estar na nuvem do Azure, em seu data center local ou em outras nuvens públicas. Chaves de API e tokens JWT determinam quem pode fazer o quê. Todo o tráfego é registado para fins analíticos.

Para desenvolvedores, o Gerenciamento de API oferece um portal do desenvolvedor que fornece acesso a serviços, documentação e código de exemplo para invocá-los. Os desenvolvedores podem usar Swagger/Open API para inspecionar pontos de extremidade de serviço e analisar seu uso. O serviço funciona nas principais plataformas de desenvolvimento: .NET, Java, Golang e muito mais.

O portal do editor expõe um painel de gerenciamento onde os administradores expõem APIs e gerenciam seu comportamento. O acesso ao serviço pode ser concedido, a integridade do serviço monitorada e a telemetria do serviço coletada. Os administradores aplicam políticas a cada ponto de extremidade para afetar o comportamento. As políticas são instruções pré-criadas que são executadas sequencialmente para cada chamada de serviço. As políticas são configuradas para uma chamada de entrada, chamada de saída ou invocadas em caso de erro. As políticas podem ser aplicadas em diferentes escopos de serviço para permitir uma ordenação determinística ao combinar políticas. O produto é fornecido com um grande número de políticas pré-criadas.

Aqui estão exemplos de como as políticas podem afetar o comportamento de seus serviços nativos da nuvem:

• Restrinja o acesso ao serviço.
• Impor autenticação.
• Acelere as chamadas de uma única fonte, se necessário.
• Ative a colocação em cache.
• Bloqueie chamadas de endereços IP específicos.
• Controle o fluxo do serviço.
• Converter solicitações de SOAP para REST ou entre diferentes formatos de dados, como de XML para JSON.

O Gerenciamento de API do Azure pode expor serviços back-end hospedados em qualquer lugar – na nuvem ou no data center. Para serviços herdados que você pode expor em seus sistemas nativos da nuvem, ele suporta APIs REST e SOAP. Até mesmo outros serviços do Azure podem ser expostos por meio do Gerenciamento de API. Você pode colocar uma API gerenciada sobre um serviço de suporte do Azure, como o Barramento de Serviço do Azure ou os Aplicativos Lógicos do Azure. O Gerenciamento de API do Azure não inclui suporte interno ao balanceamento de carga e deve ser usado em conjunto com um serviço de balanceamento de carga.

O Gerenciamento de API do Azure está disponível em quatro camadas diferentes:

• Programador
• Básica
• Standard
• Premium

A camada Desenvolvedor destina-se a cargas de trabalho e avaliação que não sejam de produção. Os outros níveis oferecem progressivamente mais poder, recursos e SLAs (Service Level Agreements, contratos de nível de serviço) mais altos. A camada Premium fornece suporte à Rede Virtual do Azure e a várias regiões. Todos os níveis têm um preço fixo por hora.

A nuvem do Azure também oferece uma camada sem servidor para o Gerenciamento de API do Azure. Conhecido como o nível de preço de consumo, o serviço é uma variante do Gerenciamento de API projetado em torno do modelo de computação sem servidor. Ao contrário dos níveis de preços "pré-alocados" mostrados anteriormente, o nível de consumo fornece provisionamento instantâneo e preços de pagamento por ação.

Ele habilita os recursos do API Gateway para os seguintes casos de uso:

• Microsserviços implementados usando tecnologias sem servidor, como Azure Functions e Azure Logic Apps.
• Recursos de serviço de suporte do Azure, como filas e tópicos do Barramento de Serviço, armazenamento do Azure e outros.
• Microsserviços onde o tráfego tem grandes picos ocasionais, mas permanece baixo na maioria das vezes.

A camada de consumo usa os mesmos componentes de gerenciamento de API de serviço subjacentes, mas emprega uma arquitetura totalmente diferente com base em recursos alocados dinamicamente. Ele se alinha perfeitamente com o modelo de computação sem servidor:

• Nenhuma infraestrutura para gerenciar.
• Sem capacidade ociosa.
• Alta disponibilidade.
• Dimensionamento automático.
• O custo é baseado no uso real.

A nova camada de consumo é uma ótima opção para sistemas nativos da nuvem que expõem recursos sem servidor como APIs.

Comunicação em tempo real

A comunicação em tempo real, ou push, é outra opção para aplicativos front-end que se comunicam com sistemas back-end nativos da nuvem por HTTP. Aplicativos, como tickers financeiros, educação on-line, jogos e atualizações de progresso de trabalho, exigem respostas instantâneas e em tempo real do back-end. Com a comunicação HTTP normal, não há como o cliente saber quando novos dados estão disponíveis. O cliente deve pesquisar continuamente ou enviar solicitações para o servidor. Com comunicação em tempo real, o servidor pode enviar novos dados para o cliente a qualquer momento.

Os sistemas em tempo real são frequentemente caracterizados por fluxos de dados de alta frequência e um grande número de conexões simultâneas de clientes. A implementação manual de conectividade em tempo real pode rapidamente se tornar complexa, exigindo infraestrutura não trivial para garantir escalabilidade e mensagens confiáveis para clientes conectados. Você pode se encontrar gerenciando uma instância do Cache Redis do Azure e um conjunto de balanceadores de carga configurados com sessões fixas para afinidade de cliente.

O Serviço Azure SignalR é um serviço do Azure totalmente gerenciado que simplifica a comunicação em tempo real para seus aplicativos nativos da nuvem. Os detalhes técnicos da implementação, como provisionamento de capacidade, dimensionamento e conexões persistentes, são abstraídos. Eles são tratados para você com um contrato de nível de serviço de 99,9%. Você se concentra nos recursos do aplicativo, não no encanamento da infraestrutura.

Uma vez habilitado, um serviço HTTP baseado em nuvem pode enviar atualizações de conteúdo diretamente para clientes conectados, incluindo navegador, aplicativos móveis e de desktop. Os clientes são atualizados sem a necessidade de sondar o servidor. O Azure SignalR abstrai as tecnologias de transporte que criam conectividade em tempo real, incluindo WebSockets, Eventos do Lado do Servidor e Sondagem Longa. Os desenvolvedores se concentram em enviar mensagens para todos ou subconjuntos específicos de clientes conectados.

A Figura 4-7 mostra um conjunto de Clientes HTTP se conectando a um aplicativo nativo da nuvem com o Azure SignalR habilitado.

Figura 4-7. Azure SignalR

Outra vantagem do Serviço Azure SignalR vem com a implementação de serviços nativos da nuvem sem servidor. Talvez seu código seja executado sob demanda com gatilhos do Azure Functions. Esse cenário pode ser complicado porque seu código não mantém conexões longas com clientes. O Azure SignalR Service pode tratar desta situação, uma vez que já faz a gestão das ligações por si.

O Serviço Azure SignalR integra-se estreitamente com outros serviços do Azure, como a Base de Dados SQL do Azure, o Service Bus ou a Cache Redis, abrindo muitas possibilidades para as suas aplicações nativas da nuvem.

AnteriorSeguinte