Cenários de testabilidade do Service Fabric: Comunicação do serviço
Os microsserviços e os estilos de arquitetura orientados para o serviço surgem naturalmente no Azure Service Fabric. Nestes tipos de arquiteturas distribuídas, as aplicações de microsserviços componentes são normalmente compostas por vários serviços que precisam de falar entre si. Mesmo nos casos mais simples, geralmente tem, pelo menos, um serviço Web sem estado e um serviço de armazenamento de dados com estado que precisa de comunicar.
A comunicação serviço a serviço é um ponto de integração crítico de uma aplicação, uma vez que 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.
Existem inúmeras considerações a ter quando estes limites de serviço são ligados num sistema distribuído:
- Protocolo de transporte. Irá utilizar HTTP para aumentar a interoperabilidade ou um protocolo binário personalizado para o débito máximo?
- Processamento de erros. Como serão processados os erros permanentes e transitórios? O que acontecerá quando um serviço mudar para um nó diferente?
- Tempos limite e latência. Em aplicações com várias camadas, como é que cada camada de serviço processará a latência através da pilha e do utilizador?
Quer utilize um dos componentes de comunicação de serviço incorporados fornecidos pelo Service Fabric ou crie os seus próprios, testar as interações entre os seus serviços é fundamental para garantir a resiliência na sua aplicação.
Preparar a movimentação dos serviços
As instâncias de serviço podem mover-se ao longo do tempo. Isto é especialmente verdade quando são configurados com métricas de carga para balanceamento de recursos ideal personalizado. O Service Fabric move as instâncias de serviço para maximizar a disponibilidade, mesmo durante atualizações, ativações pós-falha, escalamento horizontal e outras situações que ocorrem ao longo da duração de um sistema distribuído.
À medida que os serviços se deslocam no cluster, os seus clientes e outros serviços devem estar preparados para lidar com dois cenários quando falam com um serviço:
- A instância de serviço ou a réplica de partição foi movida desde a última vez que falou com a mesma. Esta é uma parte normal de um ciclo de vida do serviço e deve ser esperado que ocorra durante a duração da sua aplicação.
- A instância de serviço ou a réplica de partição está em processo de movimentação. Embora a ativação pós-falha de um serviço de um nó para outro ocorra muito rapidamente no Service Fabric, poderá haver um atraso na disponibilidade se o componente de comunicação do seu serviço demorar a iniciar.
Lidar corretamente com estes cenários é importante para um sistema de execução suave. Para tal, tenha em atenção que:
- Todos os serviços que podem ser ligados têm um endereço que escuta (por exemplo, HTTP ou WebSockets). Quando uma instância de serviço ou partição se move, o respetivo ponto final de endereço muda. (Move-se para um nó diferente com um endereço IP diferente.) Se estiver a utilizar os componentes de comunicação incorporados, estes irão processar novamente os endereços de serviço.
- Pode haver um aumento temporário da latência do serviço à medida que a instância de serviço inicia novamente o serviço de escuta. Isto depende da rapidez com que o serviço abre o serviço de escuta após a instância de serviço ser movida.
- Todas as ligações existentes têm de ser fechadas e reabertas depois de o serviço abrir num novo nó. Um encerramento ou reinício gracioso do nó permite que as ligações existentes sejam encerradas corretamente.
Testar: Mover instâncias de serviço
Ao utilizar as ferramentas de teste do Service Fabric, pode criar um cenário de teste para testar estas situações de diferentes formas:
Mover a réplica primária de um serviço com estado.
A réplica primária de uma partição de serviço com estado pode ser movida por vários motivos. Utilize esta opção para direcionar a réplica primária de uma partição específica para ver como os seus serviços reagem à movimentação de uma forma muito controlada.
PS > Move-ServiceFabricPrimaryReplica -PartitionId 6faa4ffa-521a-44e9-8351-dfca0f7e0466 -ServiceName fabric:/MyApplication/MyServicePare um nó.
Quando um nó é parado, 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. Utilize esta opção 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ó têm de ser movidas.
Pode parar um nó com o cmdlet Stop-ServiceFabricNode do PowerShell:
PS > Stop-ServiceFabricNode -NodeName Node_1
Manter a disponibilidade do serviço
Como plataforma, o Service Fabric foi concebido para fornecer elevada disponibilidade dos seus serviços. Mas, em casos extremos, os problemas de infra-estruturas subjacentes ainda podem causar indisponibilidade. Também é importante testar estes cenários.
Os serviços com estado utilizam um sistema baseado em quórum para replicar o estado para elevada disponibilidade. Isto significa que tem de estar disponível um quórum de réplicas para realizar operações de escrita. Em casos raros, como uma falha de hardware generalizada, pode não estar disponível um quórum de réplicas. Nestes casos, não poderá realizar operações de escrita, mas continuará a conseguir realizar operações de leitura.
Testar: Indisponibilidade da operação de escrita
Ao utilizar as ferramentas de teste no Service Fabric, pode injetar uma falha que induz a perda de quórum como um teste. Embora tal cenário seja raro, é importante que os clientes e os serviços que dependem de um serviço com estado estejam preparados para lidar com situações em que não podem fazer pedidos de escrita. Também é importante que o próprio serviço com estado esteja ciente desta possibilidade e possa comunique-o graciosamente aos autores da chamada.
Pode induzir a perda de quórum com o cmdlet Invoke-ServiceFabricPartitionQuorumLoss do PowerShell:
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 eliminar 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 está indisponível, pode definir este comutador como AllReplicas.