Comunicação front-end de cliente

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

Quais são as opções?

Para manter as coisas simples, um cliente front-end pode se comunicar diretamente com os microsserviços de back-end, mostrados na Figura 4-2.

Figura 4-2. Comunicação direta de cliente com 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 seja simples de implementar, a comunicação direta do cliente seria aceitável apenas para aplicativos simples de microsserviço. Esse padrão associa firmemente 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ço de back-end.
• Uma superfície de ataque mais ampla à medida que os principais serviços de back-end são expostos diretamente.
• Duplicação de preocupações entre cortes em cada microsserviço.
• Código de cliente excessivamente complexo – os clientes devem manter o controle dos vários pontos de extremidade 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 de front-end e os serviços de 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 de gateway de API abstrai os microsserviços de núcleo de back-end. Implementado como uma API Web, ela atua como uma proxy reversa, roteando o tráfego de entrada para os microsserviços internos.

O gateway isola o cliente do particionamento e refatoração de serviço interno. Se você alterar um serviço de back-end, você o acomodará no gateway sem interromper o cliente. É também sua primeira linha de defesa para preocupações de corte cruzado, como identidade, cache, resiliência, medição e limitação. Muitas dessas preocupações de corte cruzado podem ser desativadas dos serviços principais de back-end para o gateway, simplificando os serviços de back-end.

É necessário ter cuidado para manter o Gateway de API simples e rápido. Normalmente, a lógica de negócios é mantida fora do gateway. Um gateway complexo corre o risco de se tornar um gargalo e, eventualmente, um monólito em si. Sistemas maiores geralmente expõem vários Gateways de API segmentados por tipo de cliente (móvel, Web, área de trabalho) ou funcionalidade de back-end. O padrão Back-end para Front-ends fornece direção para implementar vários gateways. O padrão é mostrado na Figura 4-4.

Figura 4-4. Padrão de back-end para front-end

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

Gateways simples

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

Para aplicativos nativos de nuvem simples do .NET, você pode considerar o Gateway de Ocelot. Software código aberto e criado para os microsserviços do .NET, é leve, rápido e escalonável. Como qualquer Gateway de API, sua principal funcionalidade é encaminhar solicitações HTTP de entrada para serviços downstream. Além disso, ele dá suporte a uma ampla variedade de funcionalidades configuráveis em um pipeline de middleware do .NET.

YARP (Mais um proxy reverso) é outro proxy reverso de código aberto liderado por um grupo de equipes de produtos da Microsoft. Baixado como um pacote do NuGet, o YARP conecta-se à estrutura do ASP.NET como middleware e é altamente personalizável. Você encontrará o YARP bem documentado com vários exemplos de uso.

Para aplicativos nativos de nuvem empresarial, há vários serviços gerenciados do Azure que podem ajudar a iniciar seus esforços.

Gateway de Aplicativo do Azure

Para requisitos simples de gateway, você pode considerar o Gateway de Aplicativo do Azure. Disponível como um serviço de PaaS do Azure, ele inclui recursos básicos de gateway, como roteamento de URL, término de SSL e um Firewall de Aplicativo Web. O serviço dá suporte a 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 de HTTP, não apenas em pacotes de rede do TCP de baixo nível.

Ao longo deste livro, anunciaremos a hospedagem de sistemas nativos de nuvem no Kubernetes. Um orquestrador de contêineres, o Kubernetes automatiza a implantação, a colocação em escala e os tratos 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 de Kubernetes do Azure.

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

Figura 4-5. Controlador de Entrada do Gateway de Aplicativo

O Kubernetes inclui um recurso interno que dá suporte ao balanceamento de carga de HTTP (Nível 7), chamado Entrada. A entrada define um conjunto de regras de como 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 Gateway de Aplicativo roteia o tráfego para os microsserviços em execução 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.

Gerenciamento de API do Azure

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

Figura 4-6. Gerenciamento de API do Azure

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

Para desenvolvedores, o Gerenciamento de API oferece um portal de desenvolvedores que fornece acesso a serviços, documentação e código de exemplo para invocá-los. Os desenvolvedores podem usar a API Swagger/Open 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 em que os administradores expõem as APIs e gerenciam seu comportamento. O acesso ao serviço pode ser concedido, a integridade do serviço monitorada e a telemetria de serviço coletada. Os administradores aplicam políticas a cada ponto de extremidade para afetar o comportamento. As políticas são instruções predefinidas 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 após um erro. As políticas podem ser aplicadas em diferentes escopos de serviço para habilitar a ordenação determinística ao combinar políticas. O produto é fornecido com um grande número de políticas predefinidas.

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

• Restringir o acesso ao serviço.
• Impor a autenticação.
• Restringir chamadas de uma única origem, se necessário.
• Habilitar caching.
• Bloquear chamadas de endereços IP específicos.
• Controlar o fluxo do serviço.
• Converta solicitações de SOAP em REST ou entre formatos de dados diferentes, como de XML para JSON.

O Gerenciamento de API do Azure pode expor serviços de back-end hospedados em qualquer lugar, na nuvem ou no data center. Para serviços herdados que você pode expor em seus sistemas nativos de nuvem, ele dá suporte a APIs REST e SOAP. Mesmo outros serviços do Azure podem ser expostos por meio de Gerenciamento de API. É possível 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:

• Desenvolvedor
• Basic
• Standard
• Premium

A camada Desenvolvedor destina-se a cargas de trabalho e avaliação que não são de produção. As outras camadas oferecem progressivamente mais poder, recursos e SLAs (Contratos de Nível de Serviço) mais altos. A camada Premium fornece suporte a Rede Virtual do Azure e várias regiões. Todas as camadas têm um preço fixo por hora.

A nuvem do Azure também oferece uma camada sem servidor para Gerenciamento de API do Azure. Chamado de tipo 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 tipos de preço “pré-alocados” mostrados anteriormente, a camada de consumo fornece provisionamento instantâneo e preços de pagamento por ação.

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

• Os microsserviços implementados usando tecnologias sem servidor, como o Azure Functions e o Aplicativos Lógicos do Azure.
• Recursos de serviço de backup do Azure, como filas e tópicos do Barramento de Serviço, armazenamento do Azure e outros.
• O microsserviços em que o tráfego tem picos grandes 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. Ela se alinha perfeitamente com o modelo de computação sem servidor:

• Nenhuma infraestrutura a ser gerenciada.
• Não há capacidade ociosa.
• Alta disponibilidade.
• Colocação automática em escala.
• O custo é baseado no uso real.

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

Comunicação em tempo real

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

Os sistemas em tempo real geralmente são caracterizados por fluxos de dados de alta frequência e um grande número de conexões de cliente simultâneas. A implementação manual da conectividade em tempo real pode se tornar complexa rapidamente, exigindo uma 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 autoadesivas para afinidade do cliente.

O Serviço do Azure SignalR é um serviço do Azure totalmente gerenciado que simplifica a comunicação em tempo real para seus aplicativos nativos de nuvem. Detalhes de implementação técnica, como o provisionamento de capacidade, a colocação em escala e as conexões persistentes, são abstraídos. Eles são gerenciados para você com um contrato de nível de serviço de 99,9%. Você se concentra nos recursos do aplicativo, não em canalizar a infraestrutura.

Depois de habilitado, um serviço do HTTP baseado em nuvem pode enviar atualizações de conteúdo diretamente para clientes conectados, incluindo aplicativos de navegador, móveis e 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 de Server-Side e sondagem longa. Os desenvolvedores se concentram no envio de mensagens para todos ou subconjuntos específicos de clientes conectados.

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

Figura 4-7. Azure SignalR

Outra vantagem de Serviço do Azure SignalR vem com a implementação de serviços nativos de nuvem sem servidor. Talvez seu código seja executado sob demanda com os gatilhos do Azure Functions. Esse cenário pode ser complicado, pois seu código não mantém conexões longas com os clientes. O Serviço Azure SignalR pode lidar com essa situação, uma vez que o serviço já gerencia conexões para você.

O Serviço do Azure SignalR se integra de perto a outros serviços do Azure, como o Banco de Dados SQL do Azure, o Barramento de Serviço ou o Cache Redis, abrindo muitas possibilidades para seus aplicativos nativos de nuvem.