Dezembro 2015

Volume 30 – Número 13

Microsoft Azure – Service Fabric do Azure e a arquitetura de microsserviços

Por Cesar de la Torre, Kunal Deep Deep | Dezembro de 2015

Microsserviços é uma palavra na moda neste momento. Apesar de estarem acontecendo muitas apresentações e conferências sobre o assunto, muitos desenvolvedores continuam confusos. Uma pergunta comum que escutávamos era: “Isto não é só mais uma Arquitetura Orientada a Serviços (SOA) ou uma abordagem de Projeto Orientado a Domínio (DDD)?

Certamente, muitas das técnicas usadas na abordagem de microsserviços derivam das experiências dos desenvolvedores em SOA e DDD. Podemos pensar em microsserviços como uma “SOA bem feita”, com princípios e padrões como serviços autônomos, padrão de contexto delimitado e orientado a eventos, todos eles com suas raízes em SOA e DDD.

Neste artigo, vamos falar tanto da teoria quanto da implementação de microsserviços. Começaremos com uma introdução breve sobre microsserviços e, em seguida, passaremos para o lado prático e explicaremos como você pode construir e implementar microsserviços com o Service Fabric do Azure. Por fim, mostraremos porque esta plataforma é uma excelente opção para construir microsserviços.

Como o nome sugere, arquitetura de microsserviços é uma abordagem usada para construir um aplicativo para servidores como um conjunto de pequenos serviços, cada um deles em execução dentro de seu próprio processo e comunicando uns com os outros através de protocolos como HTTP e WebSockets. Cada microsserviço implementa capacidades de domínio e de negócios dentro de um determinado contexto delimitado por serviço, e deve ser desenvolvido de forma autônoma e implementado de forma independente por mecanismos automatizados. Por fim, cada serviço deverá possuir seu respectivo modelo de dados de domínio e lógica de domínio, e pode aplicar tecnologias de armazenamento de dados diferentes (SQL, No-SQL) e linguagens diferentes de programação por microsserviço.

Exemplos de microsserviços incluem subsistema de protocolo, perfis de usuário, cartões de compras, processamento de inventário, subsistema de compras, processamento de pagamentos, assim como filas e caches.

Porquê microsserviços? Em uma palavra, agilidade. A longo prazo, os microsserviços permitem uma maior capacidade de manutenção em sistemas grandes, complexos e altamente escaláveis projetando aplicações baseadas em muitos serviços implantáveis de forma independente que permitem um planejamento de versão granular.

Como uma vantagem adicional, os microsserviços podem ser expandidos de forma independente. Em vez de ter blocos de aplicativos monolíticos gigantes que devem ser expandidos de uma só vez, é possível expandir microsserviços específicos. Desta forma, apenas a área funcional que necessita de mais poder de processamento ou largura de banda de rede para suportar a demanda pode ser dimensionada, em vez de expandir outras áreas do aplicativo que na verdade não precisam disto.

Arquitetar aplicativos de microsserviços refinados permite uma integração contínua e práticas de desenvolvimento contínuos, assim como acelera o fornecimento de novas funções para o aplicativo. A decomposição refinada de aplicativos também permite que você execute e teste microsserviços isoladamente, assim como desenvolver microsserviços de forma independente enquanto mantém contratos rigorosos entre eles. Contanto que você não quebre contratos ou interfaces, você pode mudar qualquer implementação de microsserviços nos bastidores e adicionar uma nova funcionalidade rompendo os outros microsserviços que dependem dela.

Como mostra a Figura 1, a abordagem de microsserviços se baseia toda em eficiência para mudanças ágeis e iteração rápida, pois você é capaz de mudar porções específicas e pequenas de aplicativos grandes, complexos e escaláveis.

Abordagem de microsserviços comparada com a abordagem de aplicativos de servidores tradicionais
Figura 1 Abordagem de microsserviços comparada com a abordagem de aplicativos de servidores tradicionais

Soberania de dados por microsserviço

Uma regra importante nesta abordagem é que cada microsserviço deve possuir seus dados e lógica de domínio em um ciclo de vida autônomo, com implantação independente por microsserviço. Isso realmente não é diferente da maneira como um aplicativo completo possui seus dados e lógica.

Esta abordagem significa que um modelo conceitual do domínio será diferente entre subsistemas ou microsserviços. Imagine aplicativos para empresas, em que os aplicativos de gerenciamento de relacionamento com o cliente (CRM), os subsistemas de compras transacionais e os subsistemas de apoio ao cliente exigem atributos e dados únicos de entidade do consumidor e aplicam um contexto delimitado diferente.

Este princípio é semelhante no DDD, no qual cada contexto delimitado constitui um padrão comparável a um subsistema/serviço e possui seu próprio modelo de domínio (dados e lógica). Cada contexto delimitado DDD estaria correlacionado a um microsserviço diferente.

Por outro lado, a abordagem tradicional (ou monolítica) usada em muitos aplicativos é ter um banco de dados único e centralizado (frequentemente um banco de dados SQL normalizado) para todo o aplicativo e todos os seus subsistemas internos, como mostrado na Figura 2. Inicialmente, esta abordagem aparenta ser mais simples e parece permitir o reúso de entidade em subsistemas diferentes para tornar tudo consistente. Mas a realidade é que você acaba com uma quantidade enorme de tabelas que servem para muitos subsistemas diferentes e incluem atributos e colunas que simplesmente não são necessárias na maioria dos casos. É como tentar usar o mesmo mapa físico para uma caminhada em uma trilha pequena, uma viagem de carro de um dia e para aprender geografia.

Comparação de soberania de dados: Microsserviços contra Monolítico
Figura 2 Comparação de soberania de dados: Microsserviços contra Monolítico

Microsserviços com ou sem estado

Como mencionado anteriormente, cada microsserviço deve possuir seu próprio modelo de domínio. No caso de microsserviços sem estado, os bancos de dados serão externos, aplicando opções relacionais como SQL Server ou NoSQL como o MongoDB ou o Azure Document DB. Indo mais além, os serviços podem ser eles próprios com estado, o que significa que os dados residem dentro do mesmo microsserviço. Esses dados podem existir não só dentro do mesmo servidor, como dentro do mesmo processo do microsserviço, na memória, persistente no disco rígido e replicado em outros nós.

A abordagem sem estado é perfeitamente válida e mais fácil de implementar do que a abordagem de microsserviços com estado, pois ela é semelhante aos padrões tradicionais já conhecidos. No entanto, os microsserviços sem estado impõem uma latência entre o processo e as fontes de dados, enquanto também apresenta mais peças em movimento ao melhorar o desempenho através de cache e filas adicionais. Resultado: você pode acabar com arquiteturas muito complexas com camadas demais.

Por outro lado, os microsserviços com estado podem se destacar em cenários avançados, pois não existe latência entre a lógica e os dados de domínio. O processamento de dados pesado, os back-ends de jogos, os bancos de dados como serviço e outros cenário de baixa latência se beneficiam de serviços com estado, que usam o estado local para obter um acesso mais rápido.

Desvantagem: Os serviços com estado impõem um nível de complexidade para expandir. A funcionalidade que poderia normalmente ser implementada dentro dos limites de um banco de dados externo deve ser orientada para situações como replicação de dados em réplicas de microsserviços com estado, particionamento de dados e assim por diante. Mas isso é precisamente uma das áreas em que o Service Fabric pode ajudar mais – simplificando o desenvolvimento e o ciclo de vida de microsserviços com estado.

Benefícios do Azure Service Fabric

Todas as vantagens da abordagem de microsserviços vêm com uma desvantagem. A computação distribuída e as implantações complexas de microsserviços podem ser difíceis de gerenciar sozinho. O Service Fabric oferece os detalhes técnicos necessários para criar, implantar, executar e gerenciar microsserviços de forma eficaz e eficiente.

O que é o Service Fabric? É uma plataforma de sistemas distribuídos usada para construir aplicativos hiperescaláveis, confiáveis e fáceis de gerenciar para a nuvem. O Service Fabric lida com desafios significativos no desenvolvimento e gerenciamento de aplicativos de nuvem. Usando o Service Fabric, os desenvolvedores e administradores podem evitar ter de resolver problemas de infraestrutura complexos e, em vez disso, podem focar na implementação de cargas de trabalho exigentes e de missão crítica, cientes de que elas são escaláveis, confiáveis e gerenciáveis. O Service Fabric representa a nova geração da Microsoft de plataformas middleware para criar e gerenciar esses serviços de escala na nuvem de Nível 1 para empresas.

O Service Fabric é um ambiente de implantação universal, que permite implantar qualquer executável baseado em qualquer linguagem (Microsoft .NET Framework, Node.js, Java, C++) ou até mesmo tempos de execução de banco de dados como o MongoDB.

Portanto, é importante deixar claro que o Service Fabric do Azure não está limitado a aplicativos orientados a microsserviços. Você também pode usá-lo para hospedar e implantar aplicativos tradicionais (aplicativos ou serviços da Web) e obter muitas vantagens relacionadas com escalabilidade, balanceamento de carga e implantação rápida. Ainda assim, o Service Fabric do Azure é uma nova plataforma construída do zero e especialmente projetada para sistemas baseados em microsserviços e hiperescala, como mostrado na Figura 3.

Service Fabric do Microsoft Azure
Figura 3 Service Fabric do Microsoft Azure

Aqui estão algumas vantagens do Service Fabric:

  • É executável no Azure, no local ou em qualquer nuvem Uma característica importante do Service Fabric é que ele pode ser executado no Azure, mas também no local, em seus servidores bare-metal ou em uma máquina virtual (VM) e até mesmo em outras nuvens hospedadas por terceiros. Ele não fica preso a uma nuvem específica. Você pode até executar um cluster do Service Fabric no Amazon Web Services (AWS).
  • Suporta Windows ou Linux. Atualmente (fim de 2015) o Service Fabric suporta o Windows, mas ele também suportará Linux e contêineres (imagens do Windows e do Docker).
  • Totalmente aprovado. O Service Fabric tem sido usado há vários anos pela Microsoft para potencializar muitos de seus produtos de nuvem.

O Service Fabric nasceu da necessidade de construir serviços de grande escala dentro da Microsoft. Obter produtos como o SQL Server e construí-los como serviços disponíveis na nuvem (Banco de dados SQL do Azure) e que sejam ágeis, confiáveis, escaláveis e econômico exigia uma tecnologia distribuída que pudesse satisfazer todas as necessidades de forma eficiente. Enquanto a tecnologia central que resolvia esses cenários complexos estava sendo construídas, ficou claro que o SQL Server não era o único produto que estava dando este salto. Produtos como o Skype para empresas tiveram de resolver problemas semelhantes ao longo do processo de se tornarem um aplicativo baseado em microsserviços. O Service Fabric é uma plataforma de aplicativos que evoluiu para além desses desafios e vem sendo usado em muitos serviços de grande escala na Microsoft com arquiteturas variadas e exigências para executar em escala. O InTune, o Banco de Dados de Documentos e o back-end para a Cortana e o Skype para empresas são serviços executados no Service Fabric.

A experiência que suporta os sistemas de missão crítica permitiu à Microsoft projetar uma plataforma que compreende intrinsecamente os recursos de infraestrutura disponíveis e as necessidades de aplicativos escaláveis. Ela promove o comportamento de autorrecuperação e de atualização automática essencial para oferecer serviços altamente disponíveis e duradouros em hiperescala. A Microsoft torna esta tecnologia valente disponível para todos.

Modelos de programação do Service Fabric do Azure

O Service Fabric oferece duas estruturas de alto nível para serviços em construção: os APIs de Reliable Services e os APIs de Reliable Actors. Enquanto ambos são construídos no mesmo núcleo do Service Fabric, eles realizam diferentes compromissos entre simplicidade e flexibilidade em termos de concorrência, particionamento e comunicação, como mostrado na Figura 4. Isso é útil para entender como os dois modelos funcionam, para que você possa escolher a estrutura mais indicada para seu serviço. Em muitos cenários de aplicativos, você pode ter uma abordagem crítica e usar atores para determinados microsserviços, além de aplicar serviços confiáveis para agregar dados gerados por uma série de atores. Portanto, um serviço confiável poderia orquestrar serviços de ator em muitos cenários comuns.

Figura 4 Comparando modelos de programação do Service Fabric

APIs de atores confiáveis APIs de Reliable Services
Seu cenário envolve muitas unidades/objetos pequenos independentes de estado e lógica (objetos online da Internet das coisas ou cenários back-end de jogos são excelentes exemplos) Você precisa manter lógica e consultas através de vários tipos de entidades e componentes
Você trabalha com uma enorme quantidade de objetos de segmento único enquanto ainda consegue escalar e manter a consistência Você usa coleções confiáveis (como o Dicionário e a Fila confiáveis do .NET)
Você quer que a estrutura gerencie a concorrência e o estado de granularidade Você quer controlar a granularidade e a concorrência de seu estado
Você quer que o Service Fabric gerencie a implementação da comunicação para você Você quer decidir sobre, gerenciar e implementar os protocolos de comunicação (API da Web, WebSockets, Windows Communication Foundation e assim por diante)
Você quer que o Service Fabric gerencie o esquema de particionamento dos serviços de ator com estado para fique mais claro para você Você quer controlar o esquema de particionamento de seu serviço com estado

Construção de microsserviços sem estado com o Service Fabric do Azure

Um microsserviço no Servic Fabric do Azure pode ser praticamente qualquer processo no servidor que você desejar criar, seja ele .NET Framework, Node.js, Java ou C++. Atualmente, estão disponíveis apenas as bibliotecas .NET e C++ do API do Service Fabric. Portanto, você precisa implementar microsserviços no .NET Framework ou no C++ para implementações de nível baixo.

Como mencionado, um microsserviço sem estado é aquele no qual existe um processo (como um serviço front-end ou um serviço de lógica de negócios), mas no qual não existe literalmente nenhum estado persistente dentro do serviço, ou o estado que está presente está perdido quando o processo termina e não requer sincronização, replicação, persistência ou alta disponibilidade. Ele poderia ter um estado externo relacionado, mas persistente no armazenamento externo como o SQL Database do Azure, o Armazenamento do Azure, o Banco de Dados de Documentos do Azure ou qualquer outro mecanismo de armazenamento de terceiros (relacional ou NoSQL). Portanto, qualquer serviço existente como o serviço API Web do ASP.NET em execução nos Serviços de Nuvem, na Função de Trabalho ou no Aplicativo Web do Azure migrariam facilmente para os serviços sem estado do Service Fabric.

Para configurar seu ambiente de desenvolvimento, você precisa ter o Service Fabric SDK, que permite que você execute um cluster de desenvolvimento local que não é um emulador, mas que executa os mesmos bits que no Azure. Além disso, a integração de ferramentas do Visual Studio 2015 torna o desenvolvimento e a depuração mais fácil.

Antes de implantar e depurar serviços em sua máquina local, você precisa criar o cluster de nós. Você faz isso executando o script do Windows PowerShell chamado DevClusterSetup.ps1, como explicado na seção “Instalar e iniciar um cluster local” da página de documentação “Preparar seu ambiente de desenvolvimento” localizada em bit.ly/1Mfi0LB. Você pode consultar esta página para obter uma apresentação completa do processo de configuração.

Classe base de serviço sem estado Qualquer serviço do Service Fabric sem estado tem de ser derivado da classe Microsoft.ServiceFabric.Services.StatelessService. Esta classe fornece métodos API e contextos relacionados com o cluster do Service Fabric e o ambiente de execução, conectando-se ao ciclo de vida do serviço.

Seja seu serviço com ou sem estado, os Reliable Services fornecem um ciclo de vida simples que permite que você conecte seu código e comece rapidamente. Na verdade, existem apenas um ou dois métodos que precisam ser implementados para você ter seu serviço Service Fabric pronto para funcionar – normalmente o RunAsync e o CreateServiceReplicaListeners – que eu explicarei quando estiver realizando uma busca detalhada nos protocolos de comunicação.

Observe o RunAsync como mostrado na Figura 5. Aqui é que seu serviço pode “fazer o trabalho” no plano de fundo. O token de cancelamento fornecido é um sinal para quando esse trabalho deve parar.

Figura 5 Estrutura de base do serviço sem estado no Service Fabric do Azure

using Microsoft.ServiceFabric.Services;
namespace MyApp.MyStatelessService
{ 
  public class MyStatelessService : StatelessService
  {
    //... Service implementation
    protected override async Task RunAsync(CancellationToken cancellationToken)
    {   
      int iterations = 0;
      while (!cancellationToken.IsCancellationRequested)
      {
        ServiceEventSource.Current.ServiceMessage(this, "Working-{0}",
          iterations++);
        // Place to write your own background logic.
        // Example: Logic doing any polling task.
        // Logic here would be similar to what you usually implement in
        // Azure Worker Roles, Azure WebJobs or a traditional Windows Service.
         await Task.Delay(TimeSpan.FromSeconds(1), cancellationToken);
      }
      } 
    }
}

Protocolos de comunicação nos Reliable Services do Service Fabric do Azure Os Reliable Services do Service Fabric do Azure fornecem um modelo de comunicação conectável. Você pode usar o transporte de sua escolha, como HTTP com API Web do ASP.NET, WebSockets, Windows Communication Foundation, protocolos TCP personalizados e assim por diante.

Você pode implementar seu próprio código para seu protocolo de comunicação escolhido em seu serviço ou usar qualquer pilha de comunicação fornecida com o Service Fabric, como o ServiceCommunicationListener/ServiceProxy, que é a pilha de comunicação padrão fornecida pela estrutura dos Reliable Services no Service Fabric. Existirão pacotes NuGet separados com pilhas de comunicação adicional que você pode conectar ao Service Fabric.

Usando o API Web do ASP.NET nos microsserviços do Service Fabric Como mencionado anteriormente, o Service Fabric permite que você decida como quer que seus serviços se comuniquem, mas uma das maneiras mais comuns de criar serviços de HTTP no .NET Framework é usando o API Web do ASP.NET.

O API Web no Service Fabric é o mesmo Web API do ASP.NET que você conhece e adora. Você usa controladores, HttpRoutes e pode compilar serviços REST da mesma maneira usando o MapHttpRoute ou os atributos nos métodos que você deseja mapear as rotas Http. A diferença quando você está usando o Service Fabric é como você hospeda um aplicativo API Web. A primeira coisa a ser considerada é que você não pode usar IIS no Service Fabric do Azure, pois ele usa apenas processos sem formatação replicados em todo o cluster, por isso, você tem de hospedar internamente o ouvinte HTTP em seu código. Para fazer isso aos serviços API Web, você tem duas opções:

  • Use o API Web ASP.NET 5 (nome do código “Project K”) para hospedar internamente o escutador HTTP dentro de seu processo de microsserviços do Service Fabric.
  • Use o OWIN / Katana e o API Web ASP.NET 4.x para hospedar internamente o escutador HTTP dentro de seu processo de microsserviços do Service Fabric.

Executar o ASP.NET 5 em cima do Service Fabric do Azure é a melhor opção para compilar microsserviços pois, como mencionado anteriormente, o Service Fabric permite que você implante qualquer quantidade de serviços em cada nó / VM, atribuindo uma densidade alta de microsserviços por cluster. Além disso, essa alta densidade ficará ainda maior quando o Service Fabric fornecer finalmente suporte para .NET Core 5 e CoreCLR no futuro (sob o ASP.NET 5). Esta será a “melhor opção” para conseguir uma densidade super alta de microsserviços, pois o .NET Core 5 é uma estrutura leve com um volume de memória pequeno comparado com o .NET 4.x Framework.

Usando os Aplicativos Web “Tipo MVC” e os microsserviços do Service Fabric O ASP.NET MVC é uma estrutura muito popular para sites tradicionais, mas não pode usar a “antiga” estrutura MVC (MVC 5 ou anterior) com o Service Fabric. Isto acontece devido ao fato de que, no Service Fabric, você precisa hospedar internamente o escutador HTTP em seu processo e porque o OWIN / Katana não é suportado no MVC do ASP.NET 4.x (ele é suportado apenas no Web API do ASP.NET 4.x). Portanto, as opções que você tem de implementar em um aplicativo Web “tipo MVC” nos serviços Service Fabric são as seguintes:

  • Use o MVC 6 no ASP.NET 5 para hospedar internamente o escutador HTTP dentro de seu processo de microsserviços do Service Fabric. Ele suporta o MVC pois, no ASP.NET 5, o Web API e o MVC estão consolidados e são, na verdade, a mesma estrutura com os mesmos controladores sem qualquer dependência em relação ao IIS. Esta será a opção preferida assim que o ASP.NET 5 for liberado para produção.
  • Use o Web API do ASP.NET 4.x com o OWIN / Katana para hospedar internamente o escutador HTTP dentro do processo de microsserviços do Service Fabric e para simular os controladores do MVC com os controladores do Web API e usar a saída HTML/JavaScript em vez do conteúdo normal do Web API (JSON / XML). A página de documentação em bit.ly/1UMdKIf demonstra como implementar esta técnica.

Implemente hospedagem interna com o Web API do ASP.NET 4.x e o OWIN / Katana

Para esta abordagem, seu aplicativo do Web API habitual não muda. Isso não é diferente dos aplicativos do Web API que você já escreveu no passado, e você deve ser capaz de mover de forma simples a maior parte do código de seu aplicativo. Hospedar o aplicativo pode ser um pouco diferente do que você está acostumado se você não estiver hospedando no IIS.

Método CreateServiceReplicaListeners no Service Class É aqui que o serviço define as pilhas de comunicação que pretende usar. A pilha de comunicação, como o Web API, é o que define os pontos de extremidade de escuta para o serviço, e a maneira como essas mensagens que aparecem vão interagir com o resto do código de serviço.

Voltando à classe de serviço mencionada anteriormente na Figura 4, eu agora só preciso adicionar um novo método chamado CreateServiceReplica­Listeners, que especifica pelo menos uma pilha de comunicação que eu pretendo usar. Neste caso, é o OwinCommunicationListener usado pelo Web API, como mostrado na Figura 6.

Figura 6 Adicionando o método CreateServiceReplicaListeners à classe de serviço sem estado

using Microsoft.ServiceFabric.Services;
namespace MyApp.MyStatelessService
{ 
  public class MyStatelessService : StatelessService
  {
    //... Service implementation.
    protected override async Task RunAsync(CancellationToken cancellationToken)
    {            
      // Place to write your own background logic here.
      // ...         
    }
    protected override IEnumerable<ServiceReplicaListener>
      CreateServiceReplicaListeners()
      {
        return new List<ServiceReplicaListener>()
        {
          new ServiceReplicaListener(parameters =>
            new OwinCommunicationListener(
            "api", new Startup()))
        };
      } 
    }
}

É importante realçar que você precisa ter vários escutadores de comunicação para o seu serviço.

A classe OwinCommunicationListener é um código clichê que você reusa em todos os seus microsserviços. De forma semelhante, você poderia conectar outros protocolos (WCF, WebSockets e assim por diante).

Se você estiver criando um microsserviço Web API, você ainda terá controladores com código típico iguais aos que você já deve estar acostumado ao implementar serviços Web API, como o seguinte código:

// Typical Web API Service class implementation
public class CustomerController : ApiController
{ 
  //// Example - GET /customers/MSFT
  [HttpGet]
  [Route("customers/{customerKey}", Name = "GetCustomer")]
  public async Task<IHttpActionResult> GetCustomer(string customerKey)
  {
    // ... Stateless method implementation.       
  }
}

Como este artigo é uma visão geral de ponta a ponta do Service Fabric e microsserviços do Azure, não vamos passar por mais etapas para implementar o OWIN em seu microsserviço do Service Fabric. Há um exemplo simples disponível no GitHub que você pode baixar e analisar (bit.ly/1OW5Bmj): Exemplo do HelloWorld do Web API e do Service Fabric (ASP.NET 4.x).

Implemente hospedagem interna com o Web API do ASP.NET 5

Executar o ASP.NET 5 em cima do Service Fabric do Azure é a melhor opção para compilar microsserviços pois o Service Fabric deixa você implantar qualquer quantidade de serviços em cada nó / VM, permitindo uma densidade alta de microsserviços por cluster. O ASP.NET 5 também oferece recursos interessantes como os seguintes:

  • Hospedagem flexível: Agora você pode hospedar seu aplicativo ASP.NET 5 no IIS ou em seu próprio processo. Hospedar em seu próprio processo é fundamental no Service Fabric do Azure.
  • Web API, MVC e páginas da Web: Estas estão todas unidas, simplificando o número de conceitos.
  • Suporte lado a lado completo: Os aplicativos do ASP.NET 5 agora podem ser instalados em uma máquina sem afetar qualquer outro aplicativo no computador que possa estar usando uma versão do .NET Framework diferente. Este é um recurso incrível para gerenciamento de TI.
  • Suporte entre plataformas: O ASP.NET 5 é executado e tem suporte no Windows, Mac e Linux.
  • Pronto para nuvem: Recursos como o diagnóstico, o estado da sessão, cache e configuração são projetados para trabalhar no local e na nuvem (como o Azure) sem alterações.

Olhando para o futuro, essa alta densidade ficará ainda maior quando o Service Fabric fornecer finalmente suporte para .NET Core 5 e CoreCLR.

Enquanto o suporte para .NET Core e CoreCLR permanece nos trabalhos para o Service Fabric, o benefício que o lançamento deste suporte online trará é claro. Executar o ASP.NET 5 em cima do .NET Core 5 oferece um tempo de execução leve para o .NET Framework e o CoreCLR com um volume de memória pequeno comparado com o tradicional .NET 4.x. Essa combinação permitirá uma densidade incrível de microsserviços, como mostrado no painel “Microservice B” na Figura 7.

Comparando a execução do ASP.NET 5 no CLR vs. CoreCLR dentro do contexto do Service Fabric
Figura 7 Comparando a execução do ASP.NET 5 no CLR vs. CoreCLR dentro do contexto do Service Fabric

Enquanto o suporte do .NET Core 5 e do CoreCLR é uma opção para o futuro, as empresas já se podem preparar hoje desenvolvendo serviços ASP.NET 5 em cima do Service Fabric do .NET 4.x. Dessa forma é mais fácil migrar para o CoreCLR no futuro.

Operar e implantar microsserviços de hiperescala

As operações e o gerenciamento de implantação fornecidos pelo Service Fabric são outra razão pela qual é ótimo compilar e executar microsserviços de hiperescala em produção. Você pode focar no desenvolvimento de microsserviços e deixar que o Service Fabric forneça todos os detalhes técnicos complexos nos bastidores.

A alta densidade dos microsserviços é uma ótima vantagem se você se preocupa em baixar custos de infraestrutura. Um cluster do Service Fabric é composto por uma pool de muitos VMs / servidores (e contêineres no futuro) chamados nós no cluster. Em cada nó, o Service Fabric implanta automaticamente vários serviços, por isso, dependendo da potência de cada servidor / VM, você pode obter uma densidade super alta de microsserviços em todo o seu cluster.

No Service Fabric do Azure você tem a capacidade de executar centenas de instâncias de serviço em cada computador ou VM. Isso oferece uma grande economia para seu custo total de propriedade (TCO). Para a mesma quantidade de serviços, você precisará de menos hardware. Portanto, alta densidade é um grande diferenciador ao comparar o Service Fabric do Azure com os Serviços de Nuvem do Azure, quando você está limitado a uma VM por Serviço. Se você estava implantando microsserviços como uma função Web ou uma função de trabalho, você provavelmente tinha recursos demais atribuídos a um único microsserviço, resultando em lentidão durante implantações e gerenciamento. Por exemplo, na Figura 8 você pode ver uma VM por instância de serviço no formulário da função Web ou da função de trabalho do Azure (a cor indica o tipo de serviço enquanto cada formato indica uma VM e uma instância de serviço diferente). Esta abordagem não ajuda se você pretende ter uma alta densidade de microsserviços, a menos que você use VMs pequenas. Mesmo assim, há um limite e você não será capaz de atingir o mesmo nível de alta densidade em nenhuma implantação comparada com o Service Fabric do Azure.

Comparação de densidade de serviços – Serviços de nuvem do Azure vs. Service Fabric
Figura 8 Comparação de densidade de serviços – Serviços de nuvem do Azure vs. Service Fabric

Em contrapartida, no Service Fabric você pode implantar qualquer quantidade de microsserviços por nó, para que a densidade de serviços seja muito mais eficiente e econômica. Você pode ter dezenas, centenas ou mesmo milhares de VMs / servidores por cluster, com dezenas ou centenas de instâncias de microsserviços e réplicas por nó / VM. Devido ao fato de que cada microsserviço é basicamente um processo, a implantação e a colocação em escala é muito mais rápida do que criar uma nova VM por serviço, como é o caso com os serviços de nuvem do Azure.

Criando um cluster na nuvem do Azure Antes de implantar microsserviços, você precisa criar o cluster de nós no Azure ou nos servidores locais. Ao criar o cluster na nuvem do Azure (como sua produção ou ambiente de preparo), você pode trabalhar diretamente a partir do Portal do Azure ou usar o Gerenciador de Recursos do Azure (ARM). Na Figura 9, é mostrado um cluster do Service Fabric que criamos em nossa assinatura do Azure usando o Portal do Azure. Nos bastidores, o processo de criação do cluster é baseado no Azure ARM e nos grupos e recursos do Azure. Neste caso, criamos um cluster com cinco nós / VMs que também estão posicionados dentro de um grupo de recursos do Azure.

Cluster do Service Fabric no Portal do Azure
Figura 9 Cluster do Service Fabric no Portal do Azure

Implantando aplicativos e serviços no cluster Assim que o cluster de nós / VMs estiver pronto e funcionando, você pode implantar serviços. Ao implantar clusters na produção, você normalmente usa um script do Windows PowerShell para implantar seus aplicativos e serviços no cluster no Azure, no entanto, para ambientes de teste e de preparo você também pode implantar diretamente a partir do visual Studio.

Ao implantar para um cluster local em seu PC de desenvolvimento usando o Visual Studio 2015, você normalmente implantaria a partir do IDE clicando com o botão direito do mouse no projeto do aplicativos do Service Fabric e selecionando Implantar. Você também pode usar o Windows PowerShell para implantar no cluster de desenvolvimento em seu laptop, pois os mesmos bits do Service Fabrica são executados em clusters de desenvolvimento tal como nos clusters baseados em nuvem do Azure.

As operações cotidianas e a gerenciabilidade das implantações são necessárias para manter os serviços funcionando sem problemas a longo prazo, e os recursos do gerenciamento de ciclo de vida do aplicativo foram compiladas no Service Fabric pensando nesta abordagem baseada em microsserviços. As operações e os recursos de gerenciamento disponíveis no Service Fabric incluem implantações rápidas, atualizações de aplicativos com zero tempo de inatividade, monitoramento da integridade dos serviços, assim como aumento e redução vertical de cluster. As atualizações de zero tempo de inatividade são possíveis pois a tecnologia de atualização do Service Fabric fornece uma combinação integrada de atualizações sem interrupção e verificações de integridade automáticas que detectam e revertem as alterações na atualização se elas desestabilizarem o aplicativo. O gerenciamento dos clusters e dos aplicativos do Service Fabric é possível através dos comandos do Windows PowerShell, que oferecem toda a potência do CLI e dos scripts, enquanto também suporta ferramentas visuais incluindo o Visual Studio para facilitar o uso.

As atualizações sem interrupção são realizadas em estágios. Em cada estágio, a atualização é aplicada ao subconjunto de nós no cluster, chamado domínio de atualização. Como resultado, o aplicativo permanece disponível ao longo da atualização. Você pode ter um controle de versão forte e suporte lado a lado para que você possa implantar as versões v1 e v2 do mesmo microsserviço. Em seguida, o Service Fabric será redirecionado para um ou para o outro, dependendo dos pedidos do cliente. Para mais detalhes, verifique a documentação em bit.ly/1kSupz8.

Ao depurar serviços dentro do cluster de desenvolvimento local dentro de seu PC, o Visual Studio facilita isto mesmo quando os processos dos serviços já estão sendo executados antes de você iniciar a depuração. O IDE se anexa automaticamente a todos os processos de microsserviços relacionados ao seu projeto, o que torna mais fácil começar e usar pontos de interrupção regulares em seu código de microsserviços do Service Fabric. Basta definir os pontos de interrupção em seu código e pressionar F5. Você não precisa descobrir a qual processo você precisa anexar o Visual Studio.

Explorador do Service Fabric O Explorador do Service Fabric, descrito na Figura 10, é uma ferramenta baseada na Web fornecida pelo cluster para visualizar o estado dos aplicativos implantados, inspecionar os conteúdos dos nós individuais e realizar várias ações administrativas. A ferramenta do Explorador é servida a partir do mesmo serviço de Gateway HTTP que suporta os APIs REST do Service Fabric e pode ser encontrada em http://<your-cluster-endpoint>:19007/Explorer. No caso de um cluster local, a URL seria http://localhost:19007/Explorer.

O Explorador do Service Fabric
Figura 10 O Explorador do Service Fabric

Para mais detalhes sobre o Explorador do Service Fabric, leia a página de documentação, “Visualizando o cluster usando o Explorador do Service Fabric” (bit.ly/1MUNyad).

A plataforma do Service Fabric oferece uma série de recursos que permitem focar em desenvolvimento de aplicativos em vez de implementar sistemas de integridade e atualizáveis complexos. Isso inclui:

Expandindo serviços sem estado O mecanismo de orquestração do Service Fabric pode dimensionar automaticamente seu aplicativo Web em mais máquinas sempre que mais nós são adicionados a um cluster. Ao criar instâncias de um serviço sem estado, você pode especificar o número de instâncias que você deseja criar. O Service Fabric colocará esse número de instâncias sobre nós no cluster apropriadamente, tendo o cuidado de não criar mais de uma instância sobre cada nó. Você também pode instruir o Service Fabric para sempre criar uma instância em cada nó especificando “-1” para a contagem da instância. Isso garante que sempre que você adicionar nós para expandir seu cluster, será criada uma instância de seu serviço sem estado em novos nós.

Balanceamento de recursos automático O Service Fabric oferece balanceamento de recurso de serviço (ou orquestração de serviço) que entende os recursos totais disponíveis no cluster (como a computação das VMs). Ele move os microsserviços automaticamente dependendo das políticas e restrições definidas para melhor otimizar a maneira como os serviços criados são colocados nas VMs (veja a Figura 11). O objetivo disto é a otimização de custos e o desempenho.

Distribuição de serviços mostrando o cluster pelos nós e balanceamento de recursos automáticos
Figura 11 Distribuição de serviços mostrando o cluster pelos nós e balanceamento de recursos automáticos

Failover e replicação internosComputadores em muitos centros de dados ou nuvens públicas estão sujeitos a falhas de hardware não planejadas. Para se proteger contra tais cenários, o Service Fabric oferece failover e replicação internos significando que, apesar dos problemas de hardware, a disponibilidade de serviços não é afetada. Isso é possível pois o Service Fabric é capaz de executar e gerenciar várias instâncias de cada serviço por vários computadores e domínios de falha.

Restrições de posicionamento Você pode instruir o cluster para fazer coisas como não colocar os microsserviços de front-end nos mesmos computadores / nós, como os microsserviços de nível médio, e evitar colocar certos tipos de microsserviços nos mesmos nós. Isto pode ser feito para minimizar conflitos conhecidos ou para garantir o acesso prioritário a recursos para determinados microsserviços.

Balanceamento de carga de solicitações Para ser confundido com balanceamento de recurso automático, as solicitações de balanceamento de carga não são tratadas pelo Service Fabric, mas pelos Balanceadores de Carga do Azure ou outra plataforma externa ao Service Fabric.

Integridade Permite que você monitore e diagnostique seus sistemas. Ela também é usada durante atualizações de aplicativos para fornecer verificações de segurança de modo que as atualizações possam ser revertidas se a atualização tiver um efeito desestabilizador. Para mais informações, consulte a página de documentação “Introdução ao Monitoramento de Integridade da Malha do Serviço” (bit.ly/1jSvmHB).

Microsserviços com estado no Service Fabric do Azure

Suporte para serviços com estado é um componente importante e entusiasmante do Service Fabric do Azure. Este assunto também é complexo e abrangente, além disso, explorar serviços com estado vai além do escopo deste artigo. Porém, explicaremos rapidamente o que isso é. Aguarde um artigo de continuação focando esta área do Service Fabric em uma próxima edição.

Um microsserviço com estado no Service Fabric coloca computação e dados, com o estado posicionado dentro do próprio microsserviço (ambos na memória e persistentes no disco local). A confiabilidade do estado é alcançada através da persistência e replicação local dos dados de outros nós / VMs. Basicamente, cada partição de dados possui vários serviços de réplica associados aos dados. Cada réplica pode ser implantada em um nó / VM diferente para oferecer alta disponibilidade caso a réplica primária falhe. Isto é semelhante com a maneira como o Banco de Dados SQL do Azure trabalha com réplicas de bancos de dados, pois ele é baseado no Service Fabric do Azure.

Em aplicativos complexos e escalonáveis, os serviços com estado simplificam a arquitetura e reduzem o número de componentes em comparação com uma arquitetura tradicional e de três níveis que precisa usar cache e filas externos. Ao usar os serviços com estado, os benefícios de um cache externo tradicional é agora intrínseco no serviço com estado. Além disso, as filas externas não são necessárias porque podemos implementar filas internas dentro dos microsserviços do Service Fabric.

Ao usar serviços com estado, são criados automaticamente secundários de backup que podem retomar as operações do mesmo ponto onde o primário esquerdo parou após uma falha de hardware. Muitas vezes, os serviços devem ser dimensionados para continuar a satisfazer as demandas de uma base de usuários em crescimento, exigindo a adição de hardware ao ambiente de execução. O Service Fabric usa recursos como particionamento para que os serviços possam ser compilados e distribuídos automaticamente pelo novo hardware sem exigir a intervenção do usuário.

Os Reliable Services do Azure com estado fornecem um conjunto de capacidades, incluindo suporte de partição de dados, suporte de réplica e eleição de líder, nomenclatura de serviço de réplica e descoberta de endereço de serviços do serviço de gateway. Eles também fornecem gerenciamento de simultaneidade e granularidade de mudanças de estado usando transações, a capacidade de manter uma replicação de estado consistente e o uso de coleções de chave / valor distribuídas e confiáveis (dicionário confiável e fila confiável). A boa notícia é que o Service Fabric lida com a complexidade e os detalhes desses tópicos para você, para que você possa se concentrar em escrever aplicativos.

Serviços de Reliable Actors no Service Fabric do Azure

O Reliable Actors no Service Fabric do Azure é um modelos de programação de atores para o Service Fabric. Ele oferece um modelo de ator assíncrono e de thread único. Um ator representa uma unidade de estado e computação. De uma certa forma ele é parecido com o projeto de software aberto “Orleans” criado pela Microsoft Research. O ponto importante é que o API do Reliable Actors do Service Fabric é baseado na infraestrutura subjacente fornecida pelo Service Fabric.

Implementar instâncias de ator para dispositivos da Internet das Coisas (IoT) é um bom exemplo de uso de serviços de ator. Um tipo de ator veículo na forma de uma classe C# encapsularia a lógica de domínio do veículo da IoT, além de seus estados em tempo real como coordenadas de GPS e outros dados. Em seguida, teríamos potencialmente milhões de objetos ou instâncias de ator dessa classe mencionada, distribuída por vários nós no cluster.

Certamente, os atores não estão limitados a objetos de IoT em tempo real, pois eles poderiam ser usados para qualquer assunto, mas os “objetos de IoT em tempo real” são um ótimo cenário didático.

Os atores são distribuídos ao longo do cluster para atingir uma alta escalabilidade e disponibilidade, sendo tratados como objetos na memória em todas as VMs do cluster. Eles também são persistentes no disco local e replicados ao longo do cluster.

Os atores são objetos de thread único isolados que encapsulam o estado e o comportamento. Todos os atores têm uma instância de um tipo de ator, semelhante ao código .NET mostrado aqui:

// Actor definition (State+Behaviour) to run in the back end.
// Object instances of this Actor class will be running transparently
// in the service back end.
public class VehicleActor : Actor<Vehicle>, IVehicleActor
{
  public void UpdateGpsPosition(GpsCoordinates coord)
  { 
    // Update coordinates and trigger any data processing
    // through the State property on the base class Actor<TState>.
    this.State.Position= coord;
  }
}

Em seguida, o seguinte código mostra um exemplo de código de cliente para usar o ator através de um objeto proxy:

// Client .NET code
ActorId actorId = ActorId.NewId();
string applicationName = "fabric:/IoTVehiclesActorApp";
IVehicleActor vehicleActorProxy =
  ActorProxy.Create<IVehicleActor>(actorId, applicationName);
vehicleActorProxy.UpdateGpsPosition(new GpsCoordinates(40.748440, -73.984559));

Toda a infraestrutura de comunicação é tratada nos bastidores pela estrutura de Reliable Actors do Service Fabric.

Você poderia ter milhões de objetos VehicleActor sendo executados em seu cluster através de vários nós/ VMs diferentes, e o Service Fabric trataria dos detalhes técnicos necessários, incluindo partições e réplicas nas quais milhões de atores estão distribuídos e balanceados.

O API de cliente de atores fornece comunicação entre uma instância de ator e um cliente de ator. Para comunicar com um ator, um cliente cria um objeto proxy de ator que implementa a interface de ator. O cliente interage com o ator invocando métodos no objeto proxy.

Os cenários nos quais os atores se adaptam simplificam bastante a implementação de microsserviços, especialmente quando comparados a Reliable Services com estado nos quais você tem mais controle, mas precisa implementar muitos detalhes técnicos, endereçamento de partição, réplicas e similares. Se você não precisar de controle refinado, você pode evitar o trabalho extra usando Reliable Actors.

Conclusão

As arquiteturas de microsserviços exigem um compromisso com abordagens descentralizadas, arquitetura disciplinada e processos de design, novas tecnologias como o Service Fabric do Azure, assim como uma mudança na dinâmica de equipe, no sentido de criar equipes de desenvolvimento pequenas, e princípios ágeis aplicados por microsserviço.


Cesar de la Torreé gerente de programas sênior na Microsoft e vive em Redmond, Wash. Seus interesses incluem o Microsoft Azure e desenvolvimento do .NET com abordagens como arquiteturas de microsserviços e projetos orientados a domínio, assim como desenvolvimento de aplicativos móveis que surgem de serviços.

Kunal Deep Singhé gerente de programas sênior na equipe Service Fabric do Microsoft Azure. Antes do Azure, ele trabalhou em várias versões do Windows Phone, do Silverlight e como desenvolvedor de jogos para Xbox. Ele vive em Seattle, Wash.

Vaclav Tureceké gerente de programas sênior na Microsoft. Ele trabalha incansavelmente com um grupo talentoso de pessoas para tornar o Service Fabric do Azure a última e melhor geração de Plataforma como um Serviço.

Agradecemos ao seguinte especialista técnico da Microsoft pela coautoria e revisão deste artigo: Mark Fussell
Mark Russel é apaixonado por criar aplicativos em escala de nuvem e tem passado muitos anos na Microsoft criando produtos que variam de acesso a dados e comunicações a outras tecnologias do lado do servidor. Ele está entusiasmado para ver a Microsoft disponibilizar o Service Fabric a todos para compilar aplicativos com uma abordagem de microsserviços.