Cenários de capacidade de teste do Service Fabric: comunicação de serviço
Microsserviços e estilos de arquitetura orientados a serviços aparecem naturalmente no Azure Service Fabric. Nesses tipos de arquiteturas distribuídas, os aplicativos de microsserviço componentizados geralmente são compostos por vários serviços que precisam conversar entre si. Mesmo nos casos mais simples, você geralmente tem pelo menos um serviço Web sem estado e um serviço de armazenamento de dados com estado que precisam se comunicar.
A comunicação serviço-a-serviço é um ponto de integração crítico de um aplicativo, porque cada serviço expõe uma API remota a outros serviços. Trabalhar com um conjunto de limites de API que envolve E/S geralmente requer algum cuidado, com uma boa quantidade de testes e validação.
Há várias considerações a serem feitas quando esses limites de serviço são conectados em um sistema distribuído:
- Protocolo de transporte. Você usará HTTP para maior interoperabilidade ou um protocolo binário personalizado para taxa de transferência máxima?
- Tratamento de erros. Como serão tratados os erros permanentes e transitórios? O que acontecerá quando um serviço for movido para um nó diferente?
- Tempos limite e latência. Em aplicativos multicamadas, como cada camada de serviço lidará com a latência através da pilha e para o usuário?
Quer você use um dos componentes internos de comunicação de serviço fornecidos pelo Service Fabric ou crie o seu próprio, testar as interações entre seus serviços é fundamental para garantir a resiliência em seu aplicativo.
Prepare-se para a mudança de serviços
As instâncias de serviço podem se mover ao longo do tempo. Isso é especialmente verdadeiro quando eles são configurados com métricas de carga para balanceamento de recursos ideal personalizado. O Service Fabric move suas instâncias de serviço para maximizar sua disponibilidade mesmo durante upgrades, failovers, escalonamento e outras situações que ocorrem durante a vida útil de um sistema distribuído.
À medida que os serviços se movem no cluster, seus clientes e outros serviços devem estar preparados para lidar com dois cenários quando conversam com um serviço:
- A instância de serviço ou réplica de partição foi movida desde a última vez que você falou com ela. Essa é uma parte normal de um ciclo de vida de serviço, e espera-se que aconteça durante a vida útil do seu aplicativo.
- A instância de serviço ou réplica de partição está em processo de movimentação. Embora o failover de um serviço de um nó para outro ocorra muito rapidamente no Service Fabric, pode haver um atraso na disponibilidade se o componente de comunicação do serviço for lento para iniciar.
Lidar com esses cenários de forma graciosa é importante para um sistema de bom funcionamento. Para isso, tenha em mente que:
- Cada serviço que pode ser conectado tem um endereço que escuta (por exemplo, HTTP ou WebSockets). Quando uma instância de serviço ou partição é movida, seu ponto de extremidade de endereço muda. (Ele se move para um nó diferente com um endereço IP diferente.) Se você estiver usando os componentes de comunicação internos, eles lidarão com a resolução de endereços de serviço para você.
- Pode haver um aumento temporário na latência do serviço à medida que a instância de serviço inicia seu ouvinte novamente. Isso depende da rapidez com que o serviço abre o ouvinte depois que a instância de serviço é movida.
- Todas as conexões existentes precisam ser fechadas e reabertas após a abertura do serviço em um novo nó. Um desligamento ou reinício normal do nó dá tempo para que as conexões existentes sejam desligadas normalmente.
Testá-lo: Mover instâncias de serviço
Usando as ferramentas de capacidade de teste do Service Fabric, você pode criar um cenário de teste para testar essas situações de diferentes maneiras:
Mova a réplica principal de um serviço com monitoração de estado.
A réplica primária de uma partição de serviço com monitoração de estado pode ser movida por vários motivos. Use isso para direcionar a réplica primária de uma partição específica para ver como seus serviços reagem à movimentação de maneira muito controlada.
PS > Move-ServiceFabricPrimaryReplica -PartitionId 6faa4ffa-521a-44e9-8351-dfca0f7e0466 -ServiceName fabric:/MyApplication/MyServicePare um nó.
Quando um nó é interrompido, o Service Fabric move todas as instâncias de serviço ou partições que estavam nesse nó para um dos outros nós disponíveis no cluster. Use isso para testar uma situação em que um nó é perdido do cluster e todas as instâncias de serviço e réplicas nesse nó precisam ser movidas.
Você pode parar um nó usando o cmdlet PowerShell Stop-ServiceFabricNode :
PS > Stop-ServiceFabricNode -NodeName Node_1
Manter a disponibilidade do serviço
Como plataforma, o Service Fabric foi projetado para fornecer alta disponibilidade de seus serviços. Mas, em casos extremos, problemas de infraestrutura subjacentes ainda podem causar indisponibilidade. É importante testar também estes cenários.
Os serviços com estado usam um sistema baseado em quórum para replicar o estado para alta disponibilidade. Isso significa que um quórum de réplicas precisa estar disponível para executar operações de gravação. Em casos raros, como uma falha de hardware generalizada, um quórum de réplicas pode não estar disponível. Nesses casos, você não poderá executar operações de gravação, mas ainda poderá executar operações de leitura.
Testá-lo: Indisponibilidade da operação de gravação
Usando as ferramentas de capacidade de teste no Service Fabric, você pode injetar uma falha que induz a perda de quórum como um teste. Embora esse cenário seja raro, é importante que os clientes e serviços que dependem de um serviço com estado estejam preparados para lidar com situações em que não podem fazer solicitações de gravação para ele. Também é importante que o próprio serviço estatal esteja ciente dessa possibilidade e possa comunicá-la graciosamente aos chamadores.
Você pode induzir a perda de quórum usando o cmdlet PowerShell Invoke-ServiceFabricPartitionQuorumLoss :
PS > Invoke-ServiceFabricPartitionQuorumLoss -ServiceName fabric:/Myapplication/MyService -QuorumLossMode QuorumReplicas -QuorumLossDurationInSeconds 20
Neste exemplo, definimos QuorumLossMode para QuorumReplicas indicar que queremos induzir a perda de quórum sem remover todas as réplicas. Desta forma, as operações de leitura ainda são possíveis. Para testar um cenário em que uma partição inteira não está disponível, você pode definir essa opção como AllReplicas.