Descrição geral da terminologia do Service Fabric

  • Artigo

O Azure Service Fabric é uma plataforma de sistemas distribuídos que facilita o empacotamento, a implementação e a gestão de microsserviços dimensionáveis e fiáveis. O Service Fabric é um orquestrador de contentores e processos que lhe permite alojar os clusters em qualquer lugar: no Azure, num datacenter no local ou em qualquer fornecedor de cloud. Pode utilizar qualquer arquitetura para escrever os seus serviços e escolher onde executar a aplicação a partir de várias opções de ambiente. Este artigo detalha a terminologia utilizada pelo Service Fabric para compreender os termos utilizados na documentação.

Os vídeos de formação relacionados mencionados abaixo detalham a aplicação, o empacotamento, a implementação, as abstrações e a terminologia utilizadas pelo Service Fabric:

Conceitos de infraestrutura

Cluster: um conjunto ligado à rede de máquinas virtuais ou físicas em que os seus microsserviços são implementados e geridos. Os clusters podem ser dimensionados para milhares de máquinas.

Nó: uma máquina ou VM que faz parte de um cluster é denominada nó. A cada nó é atribuído um nome de nó (cadeia). Os nós têm características, como propriedades de colocação. Cada máquina ou VM tem um serviço Windows de arranque automático, FabricHost.exe, que começa a ser executado após o arranque e, em seguida, inicia dois executáveis: Fabric.exe e FabricGateway.exe. Estes dois executáveis compõem o nó. Para cenários de teste, pode alojar vários nós num único computador ou VM ao executar várias instâncias de Fabric.exe e FabricGateway.exe.

Conceitos de aplicações e serviços

Aplicação Nativa do Service Fabric: as Aplicações Nativas do Service Fabric são descritas pelo Modelo de Aplicação Nativa (manifestos de serviço e aplicações baseadas em XML).

Conceitos da Aplicação Nativa do Service Fabric

Aplicação: uma aplicação é uma coleção de serviços constituintes que executam uma determinada função ou funções. O ciclo de vida de cada instância de aplicação pode ser gerido de forma independente.

Serviço: um serviço executa uma função completa e autónoma e pode iniciar e executar independentemente de outros serviços. Um serviço é composto por código, configuração e dados. Para cada serviço, o código consiste nos binários executáveis, a configuração consiste em definições de serviço que podem ser carregadas no tempo de execução e os dados consistem em dados estáticos arbitrários a serem consumidos pelo serviço.

Tipo de aplicação: o nome/versão atribuído a uma coleção de tipos de serviço. É definido num ApplicationManifest.xml ficheiro e incorporado num diretório de pacotes de aplicações. Em seguida, o diretório é copiado para o arquivo de imagens do cluster do Service Fabric. Em seguida, pode criar uma aplicação com nome a partir deste tipo de aplicação no cluster.

Leia o artigo Modelo de aplicação para obter mais informações.

Pacote de aplicação: um diretório de disco que contém o ficheiro do tipo de ApplicationManifest.xml aplicação. Referencia os pacotes de serviço para cada tipo de serviço que compõe o tipo de aplicação. Os ficheiros no diretório do pacote de aplicação são copiados para o arquivo de imagens do cluster do Service Fabric. Por exemplo, um pacote de aplicação para um tipo de aplicação de e-mail pode conter referências a um pacote de serviço de fila, um pacote de serviço de front-end e um pacote de serviço de base de dados.

Aplicação com nome: depois de copiar um pacote de aplicação para o arquivo de imagens, cria uma instância da aplicação no cluster. Cria uma instância quando especifica o tipo de aplicação do pacote de aplicação com o respetivo nome ou versão. A cada instância de tipo de aplicação é atribuído um nome de identificador de recurso uniforme (URI) semelhante a: "fabric:/MyNamedApp". Num cluster, pode criar várias aplicações nomeadas a partir de um único tipo de aplicação. Também pode criar aplicações nomeadas a partir de diferentes tipos de aplicações. Cada aplicação nomeada é gerida e tem um controlo de versões independentemente.

Tipo de serviço: o nome/versão atribuído aos pacotes de código, pacotes de dados e pacotes de configuração de um serviço. O tipo de serviço é definido no ServiceManifest.xml ficheiro e incorporado num diretório de pacote de serviço. Em seguida, o diretório do pacote de serviço é referenciado pelo ficheiro de um pacote de ApplicationManifest.xml aplicação. No cluster, depois de criar uma aplicação com nome, pode criar um serviço com nome a partir de um dos tipos de serviço do tipo de aplicação. O ficheiro do tipo de ServiceManifest.xml serviço descreve o serviço.

Leia o artigo Modelo de aplicação para obter mais informações.

Existem dois tipos de serviços:

  • Sem estado: utilize um serviço sem estado quando o estado persistente do serviço é armazenado num serviço de armazenamento externo, como o Armazenamento do Azure, a Base de Dados SQL do Azure ou o Azure Cosmos DB. Utilize um serviço sem estado quando o serviço não tiver armazenamento persistente. Por exemplo, para um serviço de calculadora em que os valores são transmitidos para o serviço, é efetuada uma computação que utiliza estes valores e, em seguida, é devolvido um resultado.
  • Com monitorização de estado: utilize um serviço com monitorização de estado quando quiser que o Service Fabric faça a gestão do estado do seu serviço através dos respetivos modelos de programação Reliable Collections ou Reliable Actors. Quando cria um serviço com nome, especifique quantas partições pretende distribuir o seu estado para escalabilidade. Especifique também quantas vezes pretende replicar o seu estado entre nós, para fiabilidade. Cada serviço nomeado tem uma única réplica primária e várias réplicas secundárias. Modifica o estado do serviço com nome quando escreve na réplica primária. Em seguida, o Service Fabric replica este estado para todas as réplicas secundárias para manter o seu estado sincronizado. O Service Fabric deteta automaticamente quando uma réplica primária falha e promove uma réplica secundária existente para uma réplica primária. Em seguida, o Service Fabric cria uma nova réplica secundária.

Réplicas ou instâncias referem-se ao código (e ao estado dos serviços com monitorização de estado) de um serviço implementado e em execução. Veja Réplicas e instâncias.

Reconfiguração refere-se ao processo de qualquer alteração no conjunto de réplicas de um serviço. Veja Reconfiguração.

Pacote de serviço: um diretório de disco que contém o ficheiro do tipo de ServiceManifest.xml serviço. Este ficheiro referencia o código, os dados estáticos e os pacotes de configuração do tipo de serviço. Os ficheiros no diretório do pacote de serviço são referenciados pelo ficheiro do tipo de ApplicationManifest.xml aplicação. Por exemplo, um pacote de serviço pode referir-se ao código, aos dados estáticos e aos pacotes de configuração que constituem um serviço de base de dados.

Serviço com nome: depois de criar uma aplicação com nome, pode criar uma instância de um dos respetivos tipos de serviço no cluster. Especifique o tipo de serviço com o respetivo nome/versão. É atribuído a cada instância de tipo de serviço um nome de URI no âmbito do URI da aplicação com o nome. Por exemplo, se criar um serviço com o nome "MyDatabase" numa aplicação com o nome "MyNamedApp", o URI terá o seguinte aspeto: "fabric:/MyNamedApp/MyDatabase". Numa aplicação nomeada, pode criar vários serviços nomeados. Cada serviço nomeado pode ter o seu próprio esquema de partição e contagens de instâncias ou réplicas.

Pacote de código: um diretório de disco que contém os ficheiros executáveis do tipo de serviço, normalmente ficheiros EXE/DLL. Os ficheiros no diretório do pacote de código são referenciados pelo ficheiro do tipo de ServiceManifest.xml serviço. Quando cria um serviço com nome, o pacote de código é copiado para o nó ou nós selecionados para executar o serviço com nome. Em seguida, o código começa a ser executado. Existem dois tipos de executáveis de pacotes de código:

  • Executáveis convidados: executáveis que são executados tal como estão no sistema operativo anfitrião (Windows ou Linux). Estes executáveis não ligam ou referenciam quaisquer ficheiros de runtime do Service Fabric e, por conseguinte, não utilizam nenhum modelo de programação do Service Fabric. Estes executáveis não conseguem utilizar algumas funcionalidades do Service Fabric, como o serviço de nomenclatura para deteção de pontos finais. Os executáveis convidados não podem comunicar métricas de carregamento específicas de cada instância de serviço.
  • Executáveis do anfitrião de serviços: executáveis que utilizam modelos de programação do Service Fabric ao ligar a ficheiros de runtime do Service Fabric, ativando as funcionalidades do Service Fabric. Por exemplo, uma instância de serviço nomeada pode registar pontos finais com o Serviço de Nomenclatura do Service Fabric e também pode comunicar métricas de carga.

Pacote de dados: um diretório de disco que contém os ficheiros de dados estáticos e só de leitura do tipo de serviço, normalmente ficheiros de fotografia, som e vídeo. Os ficheiros no diretório do pacote de dados são referenciados pelo ficheiro do tipo de ServiceManifest.xml serviço. Quando cria um serviço com nome, o pacote de dados é copiado para o nó ou nós selecionados para executar o serviço com nome. O código começa a ser executado e agora pode aceder aos ficheiros de dados.

Pacote de configuração: um diretório de disco que contém os ficheiros de configuração estáticos e só de leitura do tipo de serviço, normalmente ficheiros de texto. Os ficheiros no diretório do pacote de configuração são referenciados pelo ficheiro do tipo de ServiceManifest.xml serviço. Quando cria um serviço com nome, os ficheiros no pacote de configuração são copiados para um ou mais nós selecionados para executar o serviço com nome. Em seguida, o código começa a ser executado e agora pode aceder aos ficheiros de configuração.

Contentores: por predefinição, o Service Fabric implementa e ativa serviços como processos. O Service Fabric também pode implementar serviços em imagens de contentor. Os contentores são uma tecnologia de virtualização que abstrai o sistema operativo subjacente das aplicações. Uma aplicação e o respetivo runtime, dependências e bibliotecas de sistema são executados dentro de um contentor. O contentor tem acesso privado total à vista isolada do contentor das construções do sistema operativo. O Service Fabric suporta contentores do Windows Server e contentores do Docker no Linux. Para obter mais informações, leia Service Fabric e contentores.

Esquema de partição: quando cria um serviço com nome, especifica um esquema de partição. Os serviços com quantidades substanciais de estado dividem os dados entre partições, o que espalha o estado pelos nós do cluster. Ao dividir os dados entre partições, o estado do serviço com nome pode ser dimensionado. Numa partição, os serviços nomeados sem estado têm instâncias, enquanto os serviços nomeados com monitorização de estado têm réplicas. Normalmente, os serviços nomeados sem estado têm apenas uma partição, uma vez que não têm estado interno. As instâncias de partição fornecem disponibilidade. Se uma instância falhar, outras instâncias continuarão a funcionar normalmente e, em seguida, o Service Fabric cria uma nova instância. Os serviços nomeados com monitorização de estado mantêm o estado dentro das réplicas e cada partição tem o seu próprio conjunto de réplicas para que o estado seja mantido sincronizado. Se uma réplica falhar, o Service Fabric cria uma nova réplica a partir das réplicas existentes.

Leia o artigo Partition Service Fabric reliable services (Serviços fiáveis do Partition Service Fabric ) para obter mais informações.

Serviços de sistema

Existem serviços de sistema criados em todos os clusters que fornecem as capacidades de plataforma do Service Fabric.

Serviço de Nomenclatura: cada cluster do Service Fabric tem um Serviço de Nomenclatura, que resolve os nomes dos serviços para uma localização no cluster. Pode gerir os nomes e propriedades dos serviços, como um Sistema de Nomes de Domínio (DNS) da Internet para o cluster. Os clientes comunicam em segurança com qualquer nó no cluster através do Serviço de Nomenclatura para resolver um nome de serviço e a respetiva localização. As aplicações movem-se dentro do cluster. Por exemplo, isto pode dever-se a falhas, balanceamento de recursos ou redimensionamento do cluster. Pode desenvolver serviços e clientes que resolvem a localização de rede atual. Os clientes obtêm o endereço IP e a porta do computador onde está atualmente em execução.

Leia Comunicar com serviços para obter mais informações sobre as APIs de comunicação de cliente e serviço que funcionam com o Serviço de Nomenclatura.

Serviço arquivo de imagens: cada cluster do Service Fabric tem um serviço arquivo de imagens onde são mantidos os pacotes de aplicações com versões implementadas. Copie um pacote de aplicação para o Arquivo de Imagens e, em seguida, registe o tipo de aplicação contido nesse pacote de aplicação. Depois de o tipo de aplicação ser aprovisionado, crie uma aplicação com nome a partir da mesma. Pode anular o registo de um tipo de aplicação do serviço Arquivo de Imagens depois de todas as aplicações nomeadas terem sido eliminadas.

Leia Compreender a definição ImageStoreConnectionString para obter mais informações sobre o serviço Arquivo de Imagens.

Leia o artigo Implementar uma aplicação para obter mais informações sobre como implementar aplicações no serviço Arquivo de Imagens.

Serviço Gestor de Ativação Pós-falha: cada cluster do Service Fabric tem um serviço do Gestor de Ativação Pós-falha responsável pelas seguintes ações:

  • Executa funções relacionadas com elevada disponibilidade e consistência de serviços.
  • Orquestra atualizações de aplicações e clusters.
  • Interage com outros componentes do sistema.

Serviço do Gestor de Reparação: este é um serviço de sistema opcional que permite que as ações de reparação sejam executadas num cluster de uma forma segura, automatizável e transparente. O gestor de reparações é utilizado em:

Modelos de implementação e aplicações

Para implementar os seus serviços, tem de descrever como devem ser executados. O Service Fabric suporta três modelos de implementação diferentes:

Modelo nativo

O modelo de aplicação nativa fornece às suas aplicações acesso total de baixo nível ao Service Fabric. As aplicações e os serviços são definidos como tipos registados em ficheiros de manifesto XML.

O modelo nativo suporta as arquiteturas Reliable Services e Reliable Actors, que fornecem acesso às APIs de runtime do Service Fabric e às APIs de gestão de clusters em C# e Java. O modelo nativo também suporta contentores arbitrários e executáveis.

Reliable Services: uma API para criar serviços sem estado e com monitorização de estado. Os serviços com monitorização de estado armazenam o respetivo estado em Reliable Collections, como um dicionário ou uma fila. Também pode ligar várias pilhas de comunicação, como a API Web e o Windows Communication Foundation (WCF).

Reliable Actors: uma API para criar objetos sem estado e com monitorização de estado através do modelo de programação Virtual Actor. Este modelo é útil quando tem muitas unidades independentes de computação ou estado. Este modelo utiliza um modelo de threading baseado na transformação, pelo que é melhor evitar o código que chama a outros atores ou serviços porque um ator individual não pode processar outros pedidos recebidos até que todos os pedidos de saída estejam concluídos.

Também pode executar as aplicações existentes no Service Fabric:

Contentores: o Service Fabric suporta a implementação de contentores do Docker em contentores do Linux e do Windows Server no Windows Server 2016, juntamente com suporte para o modo de isolamento do Hyper-V. No modelo de aplicação do Service Fabric, um contentor representa um anfitrião de aplicações no qual são colocadas várias réplicas de serviço. O Service Fabric pode executar quaisquer contentores e o cenário é semelhante ao cenário executável convidado, em que empacota uma aplicação existente dentro de um contentor. Além disso, também pode executar serviços do Service Fabric dentro de contentores .

Executáveis convidados: pode executar qualquer tipo de código, como Node.js, Python, Java ou C++ no Azure Service Fabric como um serviço. O Service Fabric refere-se a estes tipos de serviços como executáveis convidados, que são tratados como serviços sem estado. As vantagens de executar um executável convidado num cluster do Service Fabric incluem elevada disponibilidade, monitorização do estado de funcionamento, gestão do ciclo de vida das aplicações, alta densidade e deteção.

Leia o artigo Escolher um modelo de programação para o seu serviço para obter mais informações.

Docker Compose

O Docker Compose faz parte do projeto do Docker. O Service Fabric fornece suporte limitado para implementar aplicações com o modelo Docker Compose.

Ambientes

O Service Fabric é uma tecnologia de plataforma open source na qual se baseiam vários serviços e produtos diferentes. A Microsoft fornece as seguintes opções:

  • Azure Service Fabric: a oferta de cluster do Service Fabric alojado no Azure. Fornece integração entre o Service Fabric e a infraestrutura do Azure, juntamente com a gestão de atualização e configuração de clusters do Service Fabric.
  • Service Fabric autónomo: um conjunto de ferramentas de instalação e configuração para implementar clusters do Service Fabric em qualquer lugar (no local ou em qualquer fornecedor de cloud). Não gerido pelo Azure.
  • Cluster de desenvolvimento do Service Fabric: fornece uma experiência de desenvolvimento local no Windows, Linux ou Mac para desenvolvimento de aplicações do Service Fabric.

Passos seguintes

Para saber mais sobre o Service Fabric: