Saiba mais sobre as diferenças entre os Serviços de Nuvem e o Service Fabric antes de migrar aplicativos.
O Microsoft Azure Service Fabric é a plataforma de aplicativos em nuvem de última geração para aplicativos distribuídos altamente escaláveis e confiáveis. Ele introduz muitos recursos novos para empacotamento, implantação, atualização e gerenciamento de aplicativos de nuvem distribuídos.
Este é um guia introdutório para migrar aplicativos dos Serviços de Nuvem para o Service Fabric. Ele se concentra principalmente nas diferenças de arquitetura e design entre os Serviços de Nuvem e o Service Fabric.
Aplicações e infraestrutura
Uma diferença fundamental entre os Serviços de Nuvem e o Service Fabric é a relação entre VMs, cargas de trabalho e aplicativos. Uma carga de trabalho aqui é definida como o código que você escreve para executar uma tarefa específica ou fornecer um serviço.
- Os Serviços em Nuvem tratam da implantação de aplicativos como VMs. O código que você escreve está fortemente acoplado a uma instância de VM, como uma Função Web ou de Trabalho. Implantar uma carga de trabalho nos Serviços de Nuvem é implantar uma ou mais instâncias de VM que executam a carga de trabalho. Não há separação de aplicativos e VMs e, portanto, não há uma definição formal de um aplicativo. Um aplicativo pode ser considerado como um conjunto de instâncias da Web ou da Função de Trabalho dentro de uma implantação de Serviços de Nuvem ou como uma implantação inteira de Serviços de Nuvem. Neste exemplo, um aplicativo é mostrado como um conjunto de instâncias de função.
- O Service Fabric trata da implantação de aplicativos em VMs ou máquinas existentes que executam o Service Fabric no Windows ou Linux. Os serviços que você escreve são completamente dissociados da infraestrutura subjacente, que é abstraída pela plataforma de aplicativos do Service Fabric, para que um aplicativo possa ser implantado em vários ambientes. Uma carga de trabalho no Service Fabric é chamada de "serviço" e um ou mais serviços são agrupados em um aplicativo definido formalmente que é executado na plataforma de aplicativo do Service Fabric. Vários aplicativos podem ser implantados em um único cluster do Service Fabric.
O Service Fabric em si é uma camada de plataforma de aplicativo que é executada no Windows ou Linux, enquanto os Serviços de Nuvem são um sistema para implantar VMs gerenciadas pelo Azure com cargas de trabalho anexadas. O modelo de aplicativo do Service Fabric tem várias vantagens:
- Tempos de implementação rápidos. A criação de instâncias de VM pode ser demorada. No Service Fabric, as VMs são implantadas apenas uma vez para formar um cluster que hospeda a plataforma de aplicativo do Service Fabric. A partir desse ponto, os pacotes de aplicativos podem ser implantados no cluster muito rapidamente.
- Hospedagem de alta densidade. Nos Serviços de Nuvem, uma VM de Função de Trabalho hospeda uma carga de trabalho. No Service Fabric, os aplicativos são separados das VMs que os executam, o que significa que você pode implantar um grande número de aplicativos em um pequeno número de VMs, o que pode reduzir o custo geral para implantações maiores.
- A plataforma Service Fabric pode ser executada em qualquer lugar que tenha máquinas Windows Server ou Linux, seja Azure ou local. A plataforma fornece uma camada de abstração sobre a infraestrutura subjacente para que seu aplicativo possa ser executado em diferentes ambientes.
- Gerenciamento distribuído de aplicativos. O Service Fabric é uma plataforma que não apenas hospeda aplicativos distribuídos, mas também ajuda a gerenciar seu ciclo de vida independentemente da VM de hospedagem ou do ciclo de vida da máquina.
Arquitetura da aplicação
A arquitetura de um aplicativo de Serviços de Nuvem geralmente inclui várias dependências de serviço externo, como Service Bus, Azure Table and Blob Storage, SQL, Redis e outros para gerenciar o estado e os dados de um aplicativo e a comunicação entre funções Web e de trabalho em uma implantação de Serviços de Nuvem. Um exemplo de um aplicativo de Serviços de Nuvem completo pode ter esta aparência:
Os aplicativos do Service Fabric também podem optar por usar os mesmos serviços externos em um aplicativo completo. Usando este exemplo de arquitetura de Serviços de Nuvem, o caminho de migração mais simples dos Serviços de Nuvem para o Service Fabric é substituir apenas a implantação dos Serviços de Nuvem por um aplicativo do Service Fabric, mantendo a mesma arquitetura geral. As funções Web e de trabalho podem ser portadas para serviços sem estado do Service Fabric com alterações mínimas de código.
Nesta fase, o sistema deverá continuar a funcionar como anteriormente. Aproveitando os recursos com monitoração de estado do Service Fabric, os armazenamentos de estado externos podem ser internalizados como serviços com monitoração de estado, quando aplicável. Isso envolve mais do que uma simples migração de funções Web e de trabalho para serviços sem estado do Service Fabric, pois requer a escrita de serviços personalizados que forneçam funcionalidade equivalente ao seu aplicativo como os serviços externos faziam antes. Os benefícios de fazê-lo incluem:
- Removendo dependências externas
- Unificando os modelos de implantação, gerenciamento e atualização.
Um exemplo resultante da arquitetura de internalização desses serviços poderia ter esta aparência:
Comunicação e fluxo de trabalho
A maioria dos aplicativos do Serviço de Nuvem consiste em mais de uma camada. Da mesma forma, um aplicativo do Service Fabric consiste em mais de um serviço (normalmente muitos serviços). Dois modelos comuns de comunicação são a comunicação direta e através de um armazenamento externo durável.
Comunicação direta
Com a comunicação direta, as camadas podem se comunicar diretamente por meio de pontos de extremidade expostos por cada camada. Em ambientes sem monitoração de estado, como Serviços de Nuvem, isso significa selecionar uma instância de uma função VM, aleatoriamente ou round-robin para equilibrar a carga, e conectar-se diretamente ao seu ponto de extremidade.
A comunicação direta é um modelo de comunicação comum no Service Fabric. A principal diferença entre o Service Fabric e os Serviços de Nuvem é que nos Serviços de Nuvem você se conecta a uma VM, enquanto no Service Fabric você se conecta a um serviço. Esta é uma distinção importante por algumas razões:
- Os serviços no Service Fabric não estão vinculados às VMs que os hospedam; os serviços podem se mover no cluster e, na verdade, espera-se que se movam por vários motivos: balanceamento de recursos, failover, atualizações de aplicativos e infraestrutura e restrições de posicionamento ou carga. Isso significa que o endereço de uma instância de serviço pode ser alterado a qualquer momento.
- Uma VM no Service Fabric pode hospedar vários serviços, cada um com pontos de extremidade exclusivos.
O Service Fabric fornece um mecanismo de descoberta de serviços, chamado Serviço de Nomenclatura, que pode ser usado para resolver endereços de ponto de extremidade de serviços.
Queues
Um mecanismo de comunicação comum entre camadas em ambientes sem monitoração de estado, como os Serviços de Nuvem, é usar uma fila de armazenamento externo para armazenar tarefas de trabalho de forma durável de uma camada para outra. Um cenário comum é uma camada da Web que envia trabalhos para uma Fila do Azure ou Barramento de Serviço onde as instâncias da Função de Trabalho podem retirar da fila e processar os trabalhos.
O mesmo modelo de comunicação pode ser usado no Service Fabric. Isso pode ser útil ao migrar um aplicativo de Serviços de Nuvem existente para o Service Fabric.
Paridade
Os Serviços de Nuvem são semelhantes ao Service Fabric em grau de controle versus facilidade de uso, mas agora é um serviço herdado e o Service Fabric é recomendado para novos desenvolvimentos, a seguir está uma comparação de API:
| API do serviço de nuvem | Service Fabric API | Notas |
|---|---|---|
| RoleInstance.GetID | FabricRuntime.GetNodeContext.NodeId ou . Nome do nó | ID é uma propriedade do NodeName |
| RoleInstance.GetFaultDomain | FabricClient.QueryManager.GetNodeList | Filtre em NodeName e use a propriedade FD |
| RoleInstance.GetUpgradeDomain | FabricClient.QueryManager.GetNodeList | Filtre em NodeName e use a propriedade Upgrade |
| RoleInstance.GetInstanceEndpoints | FabricRuntime.GetActivationContext ou nomenclatura (ResolveService) | CodePackageActivationContext que é fornecido por FabricRuntime.GetActivationContext e dentro das réplicas por meio de ServiceInitializationParameters.CodePackageActivationContext fornecido durante o . Inicializar |
| RoleEnvironment.GetRoles | FabricClient.QueryManager.GetNodeList | Se você quiser fazer o mesmo tipo de filtragem por tipo, você pode obter a lista de tipos de nó do manifesto do cluster por meio de FabricClient.ClusterManager.GetClusterManifest e pegar os tipos de função/nó de lá. |
| RoleEnvironment.GetIsAvailable | Connect-WindowsFabricCluster ou crie um FabricRuntime apontado para um nó específico | * |
| RoleEnvironment.GetLocalResource | CodePackageActivationContext.Log/Temp/Work | * |
| RoleEnvironment.GetCurrentRoleInstance | CodePackageActivationContext.Log/Temp/Work | * |
| LocalResource.GetRootPath | CodePackageActivationContext.Log/Temp/Work | * |
| Role.GetInstances | FabricClient.QueryManager.GetNodeList ou ResolveService | * |
| RoleInstanceEndpoint.GetIPEndpoint | FabricRuntime.GetActivationContext ou nomenclatura (ResolveService) | * |
Passos Seguintes
O caminho de migração mais simples dos Serviços de Nuvem para o Service Fabric é substituir apenas a implantação dos Serviços de Nuvem por um aplicativo do Service Fabric, mantendo a arquitetura geral do seu aplicativo aproximadamente a mesma. O artigo a seguir fornece um guia para ajudar a converter uma função Web ou de trabalho em um serviço sem estado do Service Fabric.