Saiba mais sobre as diferenças entre o Serviços Cloud e o Service Fabric antes de migrar aplicações.
O Microsoft Azure Service Fabric é a plataforma de aplicações na cloud de próxima geração para aplicações distribuídas altamente dimensionáveis e altamente fiáveis. Apresenta muitas funcionalidades novas para empacotar, implementar, atualizar e gerir aplicações na cloud distribuídas.
Este é um guia introdutório para migrar aplicações de Serviços Cloud para o Service Fabric. Centra-se principalmente nas diferenças de arquitetura e design entre o Serviços Cloud e o Service Fabric.
Aplicações e infraestrutura
Uma diferença fundamental entre Serviços Cloud e o Service Fabric é a relação entre VMs, cargas de trabalho e aplicações. Uma carga de trabalho aqui é definida como o código que escreve para executar uma tarefa específica ou fornecer um serviço.
- Serviços Cloud é sobre a implementação de aplicações como VMs. O código que escreve está fortemente associado a uma instância de VM, como uma Função de Trabalho ou Web. Implementar uma carga de trabalho no Serviços Cloud é implementar uma ou mais instâncias de VM que executam a carga de trabalho. Não existe separação de aplicações e VMs, pelo que não existe uma definição formal de uma aplicação. Uma aplicação pode ser considerada como um conjunto de instâncias de Função de Trabalho ou Web numa implementação de Serviços Cloud ou como uma implementação de Serviços Cloud completa. Neste exemplo, uma aplicação é apresentada como um conjunto de instâncias de função.
- O Service Fabric tem a ver com a implementação de aplicações em VMs ou máquinas existentes com o Service Fabric no Windows ou Linux. Os serviços que escreve estão completamente desacoplados da infraestrutura subjacente, que é abstraída pela plataforma de aplicações do Service Fabric, para que uma aplicação possa ser implementada em vários ambientes. Uma carga de trabalho no Service Fabric é denominada "serviço" e um ou mais serviços são agrupados numa aplicação formalmente definida que é executada na plataforma de aplicações do Service Fabric. Várias aplicações podem ser implementadas num único cluster do Service Fabric.
O Service Fabric em si é uma camada de plataforma de aplicações que é executada no Windows ou Linux, enquanto Serviços Cloud é um sistema para implementar VMs geridas pelo Azure com cargas de trabalho anexadas. O modelo de aplicação 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ó são implementadas uma vez para formar um cluster que aloja a plataforma de aplicações do Service Fabric. A partir daí, os pacotes de aplicações podem ser implementados no cluster muito rapidamente.
- Alojamento de alta densidade. No Serviços Cloud, uma VM de Função de Trabalho aloja uma carga de trabalho. No Service Fabric, as aplicações são separadas das VMs que as executam, o que significa que pode implementar um grande número de aplicações num pequeno número de VMs, o que pode reduzir o custo global para implementações maiores.
- A plataforma do Service Fabric pode ser executada em qualquer lugar que tenha computadores Windows Server ou Linux, seja no Azure ou no local. A plataforma fornece uma camada de abstração sobre a infraestrutura subjacente para que a sua aplicação possa ser executada em ambientes diferentes.
- Gestão distribuída de aplicações. O Service Fabric é uma plataforma que não só aloja aplicações distribuídas, como também ajuda a gerir o respetivo ciclo de vida independentemente do ciclo de vida da VM de alojamento ou da máquina virtual.
Arquitetura da aplicação
Normalmente, a arquitetura de uma aplicação de Serviços Cloud inclui várias dependências de serviço externo, como o Service Bus, o Armazenamento de Tabelas e Blobs do Azure, o SQL, o Redis e outros para gerir o estado e os dados de uma aplicação e a comunicação entre Funções da Web e de Trabalho numa implementação de Serviços Cloud. Um exemplo de uma aplicação Serviços Cloud completa poderá ter o seguinte aspeto:
As aplicações do Service Fabric também podem optar por utilizar os mesmos serviços externos numa aplicação completa. Com este exemplo Serviços Cloud arquitetura, o caminho de migração mais simples do Serviços Cloud para o Service Fabric é substituir apenas a implementação Serviços Cloud por uma aplicação do Service Fabric, mantendo a arquitetura geral igual. As Funções Web e de Trabalho podem ser transferidas para serviços sem estado do Service Fabric com alterações mínimas de código.
Nesta fase, o sistema deve continuar a funcionar da mesma forma que antes. Tirando partido das funcionalidades com monitorização de estado do Service Fabric, os arquivos de estado externos podem ser internalizados como serviços com monitorização de estado, quando aplicável. Isto está mais envolvido do que uma simples migração de Funções Web e de Trabalho para serviços sem estado do Service Fabric, uma vez que requer a escrita de serviços personalizados que fornecem funcionalidades equivalentes à sua aplicação, como os serviços externos faziam anteriormente. As vantagens de o fazer incluem:
- Remover dependências externas
- Unificar os modelos de implementação, gestão e atualização.
Um exemplo de arquitetura resultante da internalização destes serviços poderia ter o seguinte aspeto:
Comunicação e fluxo de trabalho
A maioria das aplicações do Serviço Cloud consiste em mais do que uma camada. Da mesma forma, uma aplicação do Service Fabric consiste em mais do que um serviço (normalmente, muitos serviços). Dois modelos de comunicação comuns são a comunicação direta e através de um armazenamento durável externo.
Comunicação direta
Com a comunicação direta, as camadas podem comunicar diretamente através do ponto final exposto por cada camada. Em ambientes sem estado, como Serviços Cloud, isto significa selecionar uma instância de uma função de VM, aleatoriamente ou round robin para equilibrar a carga e ligar diretamente ao ponto final.
A comunicação direta é um modelo de comunicação comum no Service Fabric. A principal diferença entre o Service Fabric e o Serviços Cloud é que, no Serviços Cloud se liga a uma VM, ao passo que no Service Fabric se liga a um serviço. Esta é uma distinção importante por alguns motivos:
- Os serviços no Service Fabric não estão vinculados às VMs que os alojam; Os serviços podem mover-se no cluster e, na verdade, espera-se que se movam por vários motivos: Balanceamento de recursos, ativação pós-falha, atualizações de aplicações e infraestruturas e colocação ou restrições de carga. Isto significa que o endereço de uma instância de serviço pode ser alterado em qualquer altura.
- Uma VM no Service Fabric pode alojar vários serviços, cada um com pontos finais exclusivos.
O Service Fabric fornece um mecanismo de deteção de serviços, denominado Serviço de Nomenclatura, que pode ser utilizado para resolver endereços de pontos finais de serviços.
Filas
Um mecanismo de comunicação comum entre camadas em ambientes sem estado, como Serviços Cloud, consiste em utilizar uma fila de armazenamento externo para armazenar tarefas de trabalho de uma camada para outra. Um cenário comum é uma camada Web que envia tarefas para uma Fila do Azure ou Service Bus onde as instâncias de Função de Trabalho podem desativar e processar as tarefas.
O mesmo modelo de comunicação pode ser utilizado no Service Fabric. Isto pode ser útil ao migrar uma aplicação Serviços Cloud existente para o Service Fabric.
Parity
Serviços Cloud é semelhante ao Service Fabric em grau de controlo versus facilidade de utilização, mas agora é um serviço legado e o Service Fabric é recomendado para um novo desenvolvimento; segue-se uma comparação de API:
| API do Serviço Cloud | Service Fabric API | Notas |
|---|---|---|
| RoleInstance.GetID | FabricRuntime.GetNodeContext.NodeId ou . NodeName | ID é uma propriedade do NodeName |
| RoleInstance.GetFaultDomain | FabricClient.QueryManager.GetNodeList | Filtrar no NodeName e utilizar a Propriedade FD |
| RoleInstance.GetUpgradeDomain | FabricClient.QueryManager.GetNodeList | Filtre no NodeName e utilize a propriedade Upgrade |
| RoleInstance.GetInstanceEndpoints | FabricRuntime.GetActivationContext ou Nomenclatura (ResolveService) | CodePackageActivationContext que é fornecido por FabricRuntime.GetActivationContext e nas réplicas através de ServiceInitializationParameters.CodePackageActivationContext fornecido durante o . Inicializar |
| RoleEnvironment.GetRoles | FabricClient.QueryManager.GetNodeList | Se quiser fazer o mesmo tipo de filtragem por tipo, pode obter a lista de tipos de nós do manifesto do cluster através de FabricClient.ClusterManager.GetClusterManifest e obter 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) | * |
Passos Seguintes
O caminho de migração mais simples do Serviços Cloud para o Service Fabric é substituir apenas a implementação Serviços Cloud por uma aplicação do Service Fabric, mantendo a arquitetura geral da sua aplicação aproximadamente igual. O artigo seguinte fornece um guia para ajudar a converter uma Função de Trabalho ou Web num serviço sem estado do Service Fabric.