Saiba mais sobre as diferenças entre os Serviços de Nuvem e o Service Fabric antes de migrar os aplicativos.
O Service Fabric do Microsoft Azure é a plataforma de aplicativos de nuvem de última geração para aplicativos distribuídos altamente escalonáveis e altamente confiáveis. Ele apresenta muitos recursos novos para empacotamento, implantação, atualização e gerenciamento de aplicativos em 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 de design entre os Serviços de Nuvem e o Service Fabric.
Aplicativos e infraestrutura
Uma diferença fundamental entre os Serviços de Nuvem e o Service Fabric é a relação entre as VMs, as cargas de trabalho e os aplicativos. Aqui, uma carga de trabalho é definida como o código que você escreve para executar uma tarefa específica ou fornecer um serviço.
- Os Serviços de Nuvem dizem respeito à implantação de aplicativos como máquinas virtuais. O código que você escreve está acoplado a uma instância de VM, como uma função de trabalho ou Web. A implantação de uma carga de trabalho nos Serviços de Nuvem é a implantação de uma ou mais instâncias de VM que executam a carga de trabalho. Há uma distinção entre aplicativos e máquinas virtuais; portanto, não há nenhuma definição formal de um aplicativo. Um aplicativo pode ser considerado como um conjunto de instâncias de função de trabalho ou Web em uma implantação de Serviços de Nuvem ou toda uma implantação de Serviços de Nuvem. Neste exemplo, um aplicativo é mostrado como um conjunto de instâncias de função.
- O Service Fabric diz respeito à implantação de aplicativos em máquinas virtuais existentes ou computadores que executam o Service Fabric no Windows ou no Linux. Os serviços que você escreve são completamente separados da infraestrutura subjacente, que é abstraída pela plataforma de aplicativo 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 formalmente definido que é executado na plataforma de aplicativo 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 no Linux, enquanto os Serviços de Nuvem são um sistema para a implantação de VMs gerenciadas pelo Azure com cargas de trabalho anexadas. O modelo de aplicativo Service Fabric tem uma série de vantagens:
- Rapidez na implantação. A criação de instâncias da VM pode ser demorada. No Service Fabric, as VMs são implantadas somente uma vez para formar um cluster que hospeda a plataforma de aplicativo Service Fabric. Daí em diante, os pacotes de aplicativos podem ser implantados no cluster 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 as executam, o que significa que você pode implantar um grande quantidade de aplicativos em uma pequena quantidade de VMs, podendo reduzir o custo geral de implantações maiores.
- A plataforma Service Fabric pode ser executada em qualquer lugar que tenha computadores com Windows Server ou Linux, seja do Azure ou locais. A plataforma fornece uma camada de abstração sobre a infraestrutura subjacente para que seu aplicativo possa ser executado em diferentes ambientes.
- Gerenciamento de aplicativo distribuído. O Service Fabric é uma plataforma que não apenas hospeda aplicativos distribuídos, mas também ajuda a gerenciar o ciclo de vida, independentemente do ciclo de vida da VM de hospedagem ou do computador.
Arquitetura do aplicativo
A arquitetura de um aplicativo de Serviços de Nuvem geralmente inclui várias dependências de serviço externo, como o Barramento de Serviço, Armazenamento de Tabelas e de Blobs do Azure, SQL, Redis e outros para gerenciar o estado e os dados de um aplicativo e a comunicação entre funções de trabalho e Web 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 Service Fabric também podem optar por usar os mesmos serviços externos em um aplicativo completo. Usando essa arquitetura de exemplo 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 de Serviços de Nuvem por um aplicativo Service Fabric, mantendo a arquitetura geral dele. As funções de trabalho e Web podem ser portadas para serviços sem estado do Service Fabric com o mínimo de alterações de código.
Neste estágio, o sistema deve continuar a trabalhar como antes. Aproveitando os recursos de serviço com estado do Service Fabric, os armazenamentos de estado externos podem ser internalizados como serviços com estado, quando for o caso. Isso é mais complicado que uma migração simples de funções de trabalho e Web para serviços sem estado do Service Fabric, pois ele requer a criação de serviços personalizados que fornecem funcionalidade equivalente ao seu aplicativo, como os serviços externos faziam antes. Os benefícios de se fazer isso incluem:
- Removendo dependências externas
- Unificar a implantação, gerenciamento e modelos de atualização.
Uma arquitetura de exemplo resultante da 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 consistem em mais de uma camada. Da mesma forma, um aplicativo Service Fabric consiste em mais de um serviço (normalmente muitos serviços). Dois modelos comuns de comunicação têm comunicação direta e por meio de armazenamento durável externo.
Comunicação direta
Com a comunicação direta, as camadas podem se comunicar diretamente por meio do ponto de extremidade exposto por cada camada. Em ambientes sem estado, como os Serviços de Nuvem, isso significa selecionar uma instância de uma função VM, aleatoriamente ou round-robin, para balancear 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 você se conectar a uma máquina virtual, ao passo que no Service Fabric você se conecta a um serviço. Essa é uma distinção importante por duas razões:
- Os serviços no Service Fabric não são associados às VMs que os hospedam. Os serviços podem mover-se pelo cluster e, na verdade, é o que se espera por vários motivos: balanceamento de recursos, failover, atualizações de aplicativos e da infraestrutura e restrições de posicionamento ou carga. Isso significa que o endereço da instância do serviço pode mudar a qualquer hora.
- 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ço chamado Serviço de Nomenclatura, que pode ser usado para resolver endereços de ponto de extremidade de serviços.
Filas
Um mecanismo de comunicação comum entre camadas em ambientes sem estado, como os Serviços de Nuvem, é o uso de uma fila de armazenamento externo para armazenar permanentemente as tarefas de trabalho de uma camada para outra. Um cenário comum é uma camada da Web que envia os trabalhos para uma fila do Azure ou Barramento de Serviço, onde as instâncias de função de trabalho podem remover os trabalhos da fila e processá-los.
O mesmo modelo de comunicação pode ser usado no Service Fabric. Isso pode ser útil ao migrar um aplicativo dos Serviços de Nuvem existente para o Service Fabric.
Parity
Os Serviços de Nuvem são semelhantes ao Service Fabric no nível de controle vs. facilidade de uso, mas como agora se trata de um serviço herdado, o Service Fabric é recomendado para novo desenvolvimento. A seguir vemos uma comparação da API:
| API de Serviços de Nuvem | API do Service Fabric | Observações |
|---|---|---|
| RoleInstance.GetID | FabricRuntime.GetNodeContext.NodeId ou .NodeName | ID é uma propriedade do NodeName |
| RoleInstance.GetFaultDomain | FabricClient.QueryManager.GetNodeList | Filtrar por NodeName e usar a propriedade FD |
| RoleInstance.GetUpgradeDomain | FabricClient.QueryManager.GetNodeList | Filtrar por NodeName e usar a propriedade Atualização |
| RoleInstance.GetInstanceEndpoints | FabricRuntime.GetActivationContext ou Nomenclatura (ResolveService) | O CodePackageActivationContext, que é fornecido pelo FabricRuntime.GetActivationContext e nas réplicas por meio de ServiceInitializationParameters.CodePackageActivationContext fornecido durante .Initialize |
| RoleEnvironment.GetRoles | FabricClient.QueryManager.GetNodeList | Se desejar fazer o mesmo tipo de filtragem por tipo, você poderá obter a lista de tipos de nó do manifesto do cluster por meio do FabricClient.ClusterManager.GetClusterManifest e pegar os tipos de função/nó a partir daí. |
| RoleEnvironment.GetIsAvailable | Connect-WindowsFabricCluster ou criar 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) | * |
Próximas etapas
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 Service Fabric, mantendo a arquitetura geral dele. O artigo a seguir fornece um guia para ajudar a converter uma função de trabalho ou Web em um serviço sem estado do Service Fabric.