Partilhar via


Descrição geral do Reliable Services

O Azure Service Fabric simplifica a escrita e a gestão de serviços sem estado e com estado. Este tópico abrange:

  • O modelo de programação reliable Services para serviços sem estado e com estado.
  • As escolhas que tem de fazer ao escrever um Reliable Service.
  • Alguns cenários e exemplos de quando utilizar o Reliable Services e como são escritos.

O Reliable Services é um dos modelos de programação disponíveis no Service Fabric. Outro é o modelo de programação Reliable Actor , que fornece uma arquitetura de aplicação Actor Virtual sobre o modelo Reliable Services. Para obter mais informações sobre o Reliable Actors, veja Introduction to Service Fabric Reliable Actors (Introdução ao Reliable Actors do Service Fabric).

O Service Fabric gere a duração dos serviços, desde o aprovisionamento e implementação até à atualização e eliminação, através da gestão de aplicações do Service Fabric.

O que são Os Serviços Fiáveis

O Reliable Services fornece-lhe um modelo de programação simples, poderoso e de nível superior para o ajudar a expressar o que é importante para a sua aplicação. Com o modelo de programação reliable Services, obtém:

  • Acesso às APIs do Service Fabric. Ao contrário dos serviços do Service Fabric modelados como Executáveis Convidados, o Reliable Services pode utilizar as APIs do Service Fabric diretamente. Isto permite que os serviços:
    • Consultar o sistema
    • Estado de funcionamento do relatório sobre entidades no cluster
    • Receber notificações sobre a configuração e as alterações de código
    • Localizar e comunicar com outros serviços,
    • Utilizar as Coleções Fiáveis
    • Aceda a muitas outras capacidades, tudo a partir de um modelo de programação de primeira classe em várias linguagens de programação.
  • Um modelo simples para executar o seu próprio código que se parece com outros modelos de programação familiares. O seu código tem um ponto de entrada bem definido e um ciclo de vida facilmente gerido.
  • Um modelo de comunicação pluggable. Utilize o transporte à sua escolha, como HTTP com API Web, WebSockets, protocolos TCP personalizados ou qualquer outra coisa. Os Serviços Fiáveis fornecem excelentes opções fora da caixa que pode utilizar ou pode fornecer as suas próprias opções.
  • Para serviços com estado, o modelo de programação reliable Services permite-lhe armazenar de forma consistente e fiável o seu estado dentro do seu serviço através de Reliable Collections. As Coleções Fiáveis são um conjunto simples de classes de coleções altamente disponíveis e fiáveis que serão familiares a qualquer pessoa que tenha utilizado coleções C#. Tradicionalmente, os serviços precisavam de sistemas externos para a gestão de estado Fiável. Com o Reliable Collections, pode armazenar o seu estado junto à computação com a mesma elevada disponibilidade e fiabilidade que esperava de lojas externas de elevada disponibilidade. Este modelo também melhora a latência porque está a co-localizar a computação e o estado de que precisa para funcionar.

O que torna o Reliable Services diferente

Os Serviços Fiáveis são diferentes dos serviços que já escreveu anteriormente, porque o Service Fabric fornece:

  • Fiabilidade – o seu serviço permanece ativo mesmo em ambientes pouco fiáveis onde os computadores falham ou atingem problemas de rede, ou nos casos em que os próprios serviços se deparam com erros e falham ou falham. Para serviços com estado, o seu estado é preservado mesmo na presença de redes ou outras falhas.
  • Disponibilidade – o seu serviço é acessível e reativo. O Service Fabric mantém o número pretendido de cópias em execução.
  • Escalabilidade – os serviços são desacoplados a partir de hardware específico e podem aumentar ou diminuir conforme necessário através da adição ou remoção de hardware ou outros recursos. Os serviços são facilmente particionados (especialmente no caso com estado) para garantir que o serviço pode dimensionar e lidar com falhas parciais. Os serviços podem ser criados e eliminados dinamicamente através de código, permitindo que mais instâncias sejam criadas conforme necessário, por exemplo, em resposta a pedidos de clientes. Por fim, o Service Fabric incentiva os serviços a serem leves. O Service Fabric permite que milhares de serviços sejam aprovisionados num único processo, em vez de exigir ou dedicar instâncias ou processos de SO inteiros a uma única instância de um serviço.
  • Consistência – todas as informações armazenadas num Serviço Fiável podem ser consistentes. Isto é verdade mesmo em várias Coleções Fiáveis num serviço. As alterações entre coleções num serviço podem ser efetuadas de forma transacional.

Consulte esta página para obter um vídeo de formação para saber mais sobre o modelo de programação de serviços fiáveis do Service Fabric e como, com este modelo de programação .NET, a sua aplicação pode integrar-se mais de perto com o runtime do Service Fabric:

Ciclo de vida do serviço

Quer o seu serviço tenha estado ou sem estado, o Reliable Services fornece um ciclo de vida simples que lhe permite ligar rapidamente o código e começar. A execução de um novo serviço requer a implementação de dois métodos:

  • CreateServiceReplicaListeners/CreateServiceInstanceListeners – este método é onde o serviço define as pilhas de comunicação que pretende utilizar. A pilha de comunicação, como a API Web, é o que define o ponto final de escuta ou os pontos finais do serviço (como os clientes chegam ao serviço). Também define como as mensagens que aparecem interagem com o resto do código de serviço.
  • RunAsync – este método é onde o seu serviço executa a sua lógica de negócio e onde inicia todas as tarefas em segundo plano que devem ser executadas durante a duração do serviço. O token de cancelamento fornecido é um sinal para quando esse trabalho deve parar. Por exemplo, se o serviço precisar de extrair mensagens de uma Fila Fiável e processá-las, é aqui que esse trabalho acontece.

Se estiver a aprender sobre serviços fiáveis pela primeira vez, continue a ler! Se estiver à procura de instruções detalhadas sobre o ciclo de vida dos serviços fiáveis, consulte Descrição geral do ciclo de vida do Reliable Services.

Serviços de exemplo

Vejamos melhor como o modelo reliable Services funciona com serviços com estado e sem estado.

Serviços Fiáveis Sem Estado

Um serviço sem estado é aquele em que não existe nenhum estado mantido no serviço através de chamadas. Qualquer estado presente é totalmente descartável e não requer sincronização, replicação, persistência ou elevada disponibilidade.

Por exemplo, considere uma calculadora que não tem memória e recebe todos os termos e operações a executar de uma só vez.

Neste caso, o RunAsync() (C#) ou runAsync() (Java) do serviço pode estar vazio, uma vez que não existe nenhum processamento de tarefas em segundo plano que o serviço precise de fazer. Quando o serviço de calculadora é criado, devolve um ICommunicationListener (C#) ou CommunicationListener (Java) (por exemplo , API Web) que abre um ponto final de escuta em alguma porta. Este ponto final de escuta liga-se aos diferentes métodos de cálculo (exemplo: "Adicionar(n1, n2)") que definem a API pública da calculadora.

Quando uma chamada é efetuada a partir de um cliente, o método adequado é invocado e o serviço de calculadora realiza as operações nos dados fornecidos e devolve o resultado. Não armazena nenhum estado.

Não armazenar nenhum estado interno simplifica esta calculadora de exemplo. Mas a maioria dos serviços não é verdadeiramente sem estado. Em vez disso, externalizam o estado para outro arquivo. (Por exemplo, qualquer aplicação Web que dependa de manter o estado da sessão num arquivo de cópia de segurança ou cache não está sem estado.)

Um exemplo comum de como os serviços sem estado são utilizados no Service Fabric é um front-end que expõe a API voltada para o público para uma aplicação Web. Em seguida, o serviço de front-end fala com serviços com estado para concluir um pedido de utilizador. Neste caso, as chamadas de clientes são direcionadas para uma porta conhecida, como 80, onde o serviço sem estado está a escutar. Este serviço sem estado recebe a chamada e determina se a chamada é de uma entidade fidedigna e para que serviço está destinado. Em seguida, o serviço sem estado reencaminha a chamada para a partição correta do serviço com estado e aguarda uma resposta. Quando o serviço sem estado recebe uma resposta, responde ao cliente original. Um exemplo deste serviço é o exemplo de Introdução do Service Fabric (C# / Java), entre outros exemplos do Service Fabric nesse repositório.

Serviços Fiáveis com Estado

Um serviço com estado é um serviço que tem de ter alguma parte do estado mantida consistente e presente para que o serviço funcione. Considere um serviço que calcula constantemente uma média sem interrupção de algum valor com base nas atualizações que recebe. Para tal, tem de ter o conjunto atual de pedidos recebidos que precisa de processar e a média atual. Qualquer serviço que obtenha, processe e armazene informações num arquivo externo (como um blob do Azure ou um arquivo de tabelas atualmente) tem estado. Mantém o seu estado no arquivo de estado externo.

A maioria dos serviços atualmente armazena o seu estado externamente, uma vez que o arquivo externo é o que fornece fiabilidade, disponibilidade, escalabilidade e consistência para esse estado. No Service Fabric, os serviços não são necessários para armazenar o respetivo estado externamente. O Service Fabric trata destes requisitos tanto para o código de serviço como para o estado do serviço.

Digamos que queremos escrever um serviço que processe imagens. Para tal, o serviço utiliza uma imagem e a série de conversões a realizar nessa imagem. Este serviço devolve um serviço de escuta de comunicação (suponhamos que é uma WebAPI) que expõe uma API como ConvertImage(Image i, IList<Conversion> conversions). Quando recebe um pedido, o serviço armazena-o num IReliableQueuee devolve algum ID ao cliente para que possa controlar o pedido.

Neste serviço, RunAsync() pode ser mais complexo. O serviço tem um ciclo dentro do mesmo RunAsync() que retira pedidos de IReliableQueue e executa as conversões pedidas. Os resultados são armazenados num IReliableDictionary para que, quando o cliente voltar, possam obter as respetivas imagens convertidas. Para garantir que mesmo que algo falhe, a imagem não é perdida, este Reliable Service sairá da fila, realizará as conversões e armazenará o resultado numa única transação. Neste caso, a mensagem é removida da fila e os resultados são armazenados no dicionário de resultados apenas quando as conversões estiverem concluídas. Em alternativa, o serviço pode retirar a imagem da fila e armazená-la imediatamente num arquivo remoto. Isto reduz a quantidade de estado que o serviço tem de gerir, mas aumenta a complexidade, uma vez que o serviço tem de manter os metadados necessários para gerir o arquivo remoto. Com qualquer uma das abordagens, se algo tiver falhado no meio, o pedido permanecerá na fila à espera de ser processado.

Embora este serviço pareça um serviço .NET típico, a diferença é que as estruturas de dados que estão a ser utilizadas (IReliableQueue e IReliableDictionary) são fornecidas pelo Service Fabric e são altamente fiáveis, disponíveis e consistentes.

Quando utilizar as APIs do Reliable Services

Considere as APIs do Reliable Services se:

  • Quer que o código do seu serviço (e, opcionalmente, o estado) seja altamente disponível e fiável.
  • Precisa de garantias transacionais em várias unidades de estado (por exemplo, encomendas e itens de linha de encomenda).
  • O estado da sua aplicação pode ser naturalmente modelado como Dicionários Fiáveis e Filas.
  • O código ou estado das aplicações tem de estar altamente disponível com leituras e escritas de baixa latência.
  • A sua aplicação tem de controlar a simultaneidade ou granularidade das operações transacionadas numa ou mais Coleções Fiáveis.
  • Quer gerir as comunicações ou controlar o esquema de criação de partições para o seu serviço.
  • O código precisa de um ambiente de runtime de thread livre.
  • A sua aplicação tem de criar ou destruir dinamicamente Dicionários Fiáveis, Filas ou Serviços inteiros no runtime.
  • Tem de controlar programaticamente as funcionalidades de cópia de segurança e restauro fornecidas pelo Service Fabric para o estado do seu serviço.
  • A sua aplicação tem de manter o histórico de alterações para as respetivas unidades de estado.
  • Quer desenvolver ou consumir fornecedores de estado personalizados desenvolvidos por terceiros.

Passos seguintes