Comunicação de cliente no front-end

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 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 entre cliente e serviço

Com essa abordagem, cada microsserviço tem um endpoint público acessível por clientes de 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 acopla estreitamente os clientes front-end aos serviços principais do back-end, causando 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 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 principais de back-end. Implementada como uma API Web, ela 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, 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 da área de trabalho. Essa abordagem faz sentido, pois as funcionalidades de cada dispositivo diferem significativamente em termos de formato, desempenho e limitações de exibição. Normalmente, os 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 do .NET simples, você pode considerar o Gateway de Ocelot. Software livre e criado para microsserviços do .NET, ele é 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 recursos que são configuráveis em um pipeline de middleware do .NET.

YARP (Ainda Outro Proxy Reverso) é um proxy reverso de software livre liderado por grupos de produtos da Microsoft. Baixado como um pacote NuGet, o YARP conecta-se à estrutura ASP.NET como middleware e é altamente personalizável. Você encontrará 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, terminação 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 HTTP, não apenas em pacotes de rede TCP de baixo nível.

Ao longo deste livro, evangelizamos a hospedagem de sistemas nativos de 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 de Kubernetes do Azure .

O Controlador de Entrada do Gateway de Aplicativo permite que o Gateway de Aplicativo do Azure funcione 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 HTTP (Nível 7), chamado de Entrada. Ingress define um conjunto de regras para expor como as instâncias de microsserviços dentro do AKS podem ser acessadas pelo 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 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 de escala moderada a grande, 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 completa. O 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 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 desenvolvedor 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 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 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 após um erro. As políticas podem ser aplicadas em escopos de serviço diferentes 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 cache.
• Bloqueie 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. 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 backup 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 de 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
• Básico
• Padrão
• Prêmio

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 energia, recursos e SLAs (contratos de nível de serviço) mais altos. A camada Premium fornece suporte à Rede Virtual do Azure e a 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 o Gerenciamento de API do Azure. Conhecido como o 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:

• Microsserviços implementados usando tecnologias sem servidor, como o Azure Functions e os 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 subjacente, 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 a ser gerenciada.
• Não há 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 de 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 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 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. Implementar manualmente a 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 Azure Redis Cache e um conjunto de balanceadores de carga configurados com sessões persistentes para afinidade com o 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 provisionamento de capacidade, dimensionamento e 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 no encanamento de infraestrutura.

Uma vez habilitado, um serviço 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 Server-Side e Long Polling. 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 que se conectam a um aplicativo nativo de nuvem com o Azure SignalR habilitado.

Figura 4-7. Azure SignalR

Outra vantagem do 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 gatilhos do Azure Functions. Esse cenário pode ser complicado porque seu código não mantém conexões longas com clientes. O Serviço do Azure SignalR pode lidar com essa situação, pois 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 Banco de Dados SQL do Azure, Barramento de Serviço ou Cache Redis, abrindo muitas possibilidades para seus aplicativos nativos de nuvem.