Arquitetura de microsserviços no Azure Service Fabric

Gerenciamento de API
Key Vault
Monitor
Pipelines
Service Fabric

Essa arquitetura de referência mostra uma arquitetura de microsserviços implantada no Azure Service Fabric. Ele mostra uma configuração básica do cluster que pode ser o ponto de partida para a maioria das implantações.

Logotipo do GitHub Uma implementação de referência para essa arquitetura está disponível no GitHub.

Arquitetura

Diagrama mostrando a arquitetura de referência do Service Fabric.

Baixe um Arquivo Visio dessa arquitetura.

Observação

Este artigo se concentra no modelo de programação do Reliable Services para o Service Fabric. Usar o Service Fabric para implantar e gerenciar contêineres está além do escopo deste artigo.

Fluxo de trabalho

A arquitetura consiste nos componentes a seguir. Para outros termos, confira Visão geral da terminologia do Service Fabric.

Cluster do Service Fabric. Um conjunto de VMs (máquinas virtuais) conectadas em rede, no qual os microsserviços são implantados e gerenciados.

Conjuntos de dimensionamento de máquinas virtuais. Os conjuntos de dimensionamento de máquinas virtuais permitem criar e gerenciar um grupo de VMs idênticas, com balanceamento de carga e dimensionamento automático. Ele também fornece os domínios de falha e atualização.

Nós. Os nós são VMs que pertencem ao cluster do Service Fabric.

Tipos de nó. Um tipo de nó representa um conjunto de dimensionamento de máquinas virtuais que implanta uma coleção de nós. Um cluster do Service Fabric tem pelo menos um tipo de nó. Em um cluster com vários tipos de nó, é necessário declarar o Tipo de nó primário. O tipo de nó primário no cluster executa os serviços do sistema do Service Fabric. Esses serviços fornecem os recursos de plataforma do Service Fabric. O tipo de nó primário também atua como nós de semente para o cluster, que são os nós que mantêm a disponibilidade do cluster subjacente. Configure tipos de nó adicionais para executar seus serviços.

Serviços. Um serviço executa uma função autônoma que pode iniciar e executar independentemente de outros serviços. Instâncias de serviços são implantadas em nós no cluster. Há duas variedades de serviço no Service Fabric:

  • Serviço sem estado. Um serviço sem estado não mantém o estado dentro do serviço. Se a persistência de estado for necessária, o estado será gravado e recuperado de um repositório externo, como o Azure Cosmos DB.
  • Serviço com estado. O estado do serviço é mantido dentro do próprio serviço. A maioria dos serviços com estado implementa por meio das Coletas Confiáveis do Service Fabric.

Service Fabric Explorer. O Service Fabric Explorer é uma ferramenta de código-fonte aberto para inspecionar e gerenciar clusters do Service Fabric.

Azure Pipelines. O Pipelines faz parte do Azure DevOps Services e executa compilações, testes e implantações automatizadas. Você também pode usar soluções de CI/CD de terceiros, como o Jenkins.

Azure Monitor. O Azure Monitor coleta e armazena métricas e logs, incluindo a métrica de plataforma para os serviços do Azure na telemetria do aplicativo e da solução. Use esses dados para monitorar o aplicativo, configurar alertas e painéis e executar a análise da causa raiz de falhas. O Azure Monitor integra-se ao Service Fabric para coletar métricas de controladores, nós e contêineres, bem como logs do contêiner e do nó.

Azure Key Vault. Use o Key Vault para armazenar os segredos do aplicativo usados pelos microsserviços, como cadeias de conexão.

Gerenciamento de API do Azure. Nessa arquitetura, o Gerenciamento de API atua como um gateway de API que aceita solicitações de clientes e as roteia para seus serviços.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Considerações sobre o design

Essa arquitetura de referência é focada em arquiteturas de microsserviços. Um microsserviço é uma pequena unidade de código com controle de versão independente. Ele é detectável por meio de mecanismos de descoberta de serviço e pode se comunicar com outros serviços por meio de APIs. Cada serviço é independente e deve implementar uma única funcionalidade comercial. Para obter mais informações sobre como decompor seu domínio de aplicativo em microsserviços, confira Usar a análise de domínio para modelar microsserviços.

O Service Fabric fornece uma infraestrutura para criar, implantar e atualizar microsserviços com eficiência. Ele também fornece opções para dimensionamento automático, gerenciamento de estado, monitoramento de integridade e reinicialização de serviços em caso de falha.

O Service Fabric segue um modelo de aplicativo em que um aplicativo é uma coleção de microsserviços. O aplicativo é descrito em um arquivo de manifesto do aplicativo que define os diferentes tipos de serviço contidos nesse aplicativo e aponta para os pacotes de serviço independentes. O pacote de aplicativos também geralmente contém parâmetros que servem como substituições para determinadas configurações usadas pelos serviços. Cada pacote de serviço tem um arquivo de manifesto que descreve os arquivos físicos e pastas necessários para executar esse serviço, incluindo binários, arquivos de configuração e dados somente leitura para esse serviço. Serviços e aplicativos têm um controle de versão e podem ser atualizados independentemente.

Opcionalmente, o manifesto do aplicativo pode descrever os serviços que são provisionados automaticamente quando uma instância do aplicativo é criada. São chamados de serviços padrão. Nesse caso, o manifesto do aplicativo também descreve como esses serviços devem ser criados, incluindo o nome do serviço, a contagem de instâncias, a política de segurança/isolamento e as restrições de posicionamento.

Observação

Evite usar serviços padrão se quiser controlar o tempo de vida de seus serviços. Os serviços padrão são criados quando o aplicativo é criado e são executados enquanto o aplicativo está em execução.

Para obter mais informações sobre como entender o Service Fabric, confira Deseja saber mais sobre o Service Fabric?

Escolha um modelo de empacotamento de aplicativo para serviço

Um princípio dos microsserviços é que cada serviço pode ser implantado de forma independente. No Service Fabric, se você agrupar todos os seus serviços em um único pacote de aplicativo e um serviço não for atualizado, toda a atualização do aplicativo será revertida, o que impede que outros serviços sejam atualizados.

Por esse motivo, em uma arquitetura de microsserviços, recomendamos o uso de vários pacotes de aplicativos. Coloque um ou mais tipos de serviço relacionados de perto em um único tipo de aplicativo. Se sua equipe for responsável por um conjunto de serviços executados pela mesma duração e precisarem ser atualizados ao mesmo tempo, tenha o mesmo ciclo de vida ou compartilhe recursos como dependências ou configuração, coloque esses tipos de serviços no mesmo tipo de aplicativo.

Modelos de programação do Service Fabric

Quando você adiciona um microsserviço a um aplicativo do Service Fabric, decida se ele tem estado ou dados que precisam ser altamente disponíveis e confiáveis. Nesse caso, ele pode armazenar dados externamente ou os dados estão contidos como parte do serviço? Escolha um serviço sem estado se você não precisar armazenar dados ou quiser armazenar dados no armazenamento externo. Se você quiser manter o estado ou os dados como parte do serviço (por exemplo, você precisa que os dados residam na memória próxima ao código) ou não puder tolerar uma dependência em um repositório externo, considere escolher um serviço com estado.

Se você tiver um código existente que deseja executar no Service Fabric, poderá usá-lo como um executável convidado, que é um executável arbitrário executado como um serviço. Como alternativa, você pode empacotar o executável em um contêiner que tenha todas as dependências necessárias para a implantação. O Service Fabric modela contêineres e executáveis convidados como serviços sem estado. Para obter diretrizes sobre como escolher um modelo, confira Visão geral do modelo de programação do Service Fabric.

Com executáveis convidados, você é responsável por manter o ambiente no qual ele é executado. Por exemplo, suponha que um executável convidado exija Python. Se o executável não for autocontido, você precisará verificar se a versão necessária do Python está pré-instalada no ambiente. O Service Fabric não gerencia o ambiente. O Azure oferece vários mecanismos para configurar o ambiente, incluindo imagens e extensões de máquina virtual personalizadas.

Para acessar um executável convidado por meio de um proxy reverso, verifique se você adicionou o atributo UriScheme ao elemento Ponto de Extremidade no manifesto de serviço do executável convidado.

    <Endpoints>
      <Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" UriScheme="http" PathSuffix="api" Type="Input"/>
    </Endpoints>

Se o serviço tiver rotas adicionais, especifique as rotas no valor PathSuffix. O valor não deve ser prefixado ou sufixado com “/”. Outra maneira é adicionar a rota no nome do serviço.

    <Endpoints>
      <Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" PathSuffix="api" Type="Input"/>
    </Endpoints>

Para obter mais informações, consulte:

Gateway de API

Um gateway de API (entrada) se posiciona entre os clientes externos e os microsserviços. Ele atua como um proxy reverso, encaminhando as solicitações de clientes para os microsserviços. Ele também pode executar várias tarefas detalhadas, como autenticação, terminação de SSL e a limitação de taxa.

O Gerenciamento de API do Azure é recomendado para a maioria dos cenários, mas Traefik é uma alternativa de código aberto popular. Ambas as opções de tecnologia são integradas ao Service Fabric.

  • O Gerenciamento de API expõe um endereço IP público e roteia o tráfego para seus serviços. Ele é executado em uma sub-rede dedicada na mesma rede virtual que o cluster do Service Fabric. Ele pode acessar serviços em um tipo de nó que é exposto por meio de um balanceador de carga com um endereço IP privado. Esta opção está disponível apenas nas camadas Premium e Developer do Gerenciamento de API. Para cargas de trabalho de produção, use a camada Premium. As informações de preços são descritas em Preços do Gerenciamento de API. Para obter mais informações, confira a visão geral do Service Fabric com Gerenciamento de API do Azure.
  • O Traefik dá suporte a recursos como roteamento, rastreamento, logs e métricas. O Traefik é executado como um serviço sem estado no cluster do Service Fabric. O controle de versão do serviço pode ter suporte por meio do roteamento. Para obter informações sobre como configurar o Traefik para entrada de serviço e como o proxy reverso dentro do cluster, confira Provedor do Azure Service Fabric. Para obter mais informações sobre como usar o Traefik com o Service Fabric, confira Roteamento inteligente no Service Fabric com Traefik (postagem no blog).

O Traefik, diferente do Gerenciamento de API do Azure, não tem funcionalidade para resolver a partição de um serviço com estado (com mais de uma partição) para a qual uma solicitação é roteada. Para obter mais informações, confira Adicionar um correspondente para serviços de particionamento.

Outras opções de gerenciamento de API incluem Gateway de Aplicativo do Azure e Azure Front Door. Esses serviços podem ser usados em conjunto com Gerenciamento de API para executar tarefas como roteamento, encerramento de SSL e firewall.

Comunicação entre serviços

Para facilitar a comunicação serviço a serviço, considere o uso de HTTP como o protocolo de comunicação. Como linha de base para a maioria dos cenários, recomendamos usar o serviço de proxy reverso para descoberta de serviço.

  • Protocolo de comunicação. Em uma arquitetura de microsserviços, os serviços precisam se comunicar uns com os outros com acoplamento mínimo no runtime. Para habilitar a comunicação independente de linguagem, o HTTP é um padrão do setor com uma ampla variedade de ferramentas e servidores HTTP disponíveis em idiomas diferentes, todos com suporte do Service Fabric. Portanto, o uso de HTTP em vez da comunicação remota de serviço interno do Service Fabric é recomendado para a maioria das cargas de trabalho.
  • Descoberta de serviço. Para se comunicar com outros serviços em um cluster, um serviço cliente precisa resolver o local atual do serviço de destino. No Service Fabric, os serviços podem se mover entre nós, fazendo com que os pontos de extremidade de serviço sejam alterados dinamicamente. Para evitar conexões com pontos de extremidade obsoletos, o Serviço de Nomenclatura do Service Fabric poderá ser usado para recuperar informações atualizadas do ponto de extremidade. No entanto, o Service Fabric também fornece um serviço de proxy reverso interno que abstrai o serviço de nomenclatura. Essa opção é mais fácil de usar e resulta em código mais simples.

Outras opções de comunicação entre serviços incluem:

  • Traefik para roteamento avançado.
  • DNS para cenários de compatibilidade em que um serviço espera usar DNS.
  • Classe ServicePartitionClient<TCommunicationClient>. A classe armazena em cache pontos de extremidade de serviço e pode habilitar um melhor desempenho, pois as chamadas passam diretamente entre serviços sem intermediários ou protocolos personalizados.

Escalabilidade

O Service Fabric dá suporte à escala dessas entidades de cluster:

  • Dimensione o número de nós para cada tipo de nó.
  • Serviços de dimensionamento.

Esta seção está focada no dimensionamento automático. Você pode optar por reduzir horizontalmente em situações adequadas. Por exemplo, uma situação em que a intervenção manual é necessária para definir o número de instâncias.

Configuração inicial do cluster para escalabilidade

Ao criar um cluster do Service Fabric, provisione os tipos de nó com base em suas necessidades de segurança e escalabilidade. Cada tipo de nó é mapeado para um conjunto de dimensionamento de máquinas virtuais e pode ser escalado de forma independente.

  • Crie um tipo de nó para cada grupo de serviços que têm diferentes requisitos de escalabilidade ou recursos. Comece provisionando um tipo de nó (que se torna o Tipo de nó primário) para os serviços do sistema Service Fabric. Crie tipos de nó separados para executar seus serviços públicos ou de front-end e outros tipos de nó conforme necessário para seu back-end e serviços privados ou isolados. Especifique restrições de posicionamento para que os serviços sejam implantados apenas nos tipos de nó pretendidos.
  • Especifique a camada de durabilidade para cada tipo de nó. A camada de durabilidade representa a capacidade de o Service Fabric influenciar as atualizações do conjunto de dimensionamento de máquinas virtuais e as operações de manutenção. Para cargas de trabalho de produção, escolha a camada Silver ou de durabilidade mais alta. Para obter mais informações, confira Características de durabilidade do cluster.
  • Se estiver usando a camada de durabilidade Bronze, determinadas operações exigirão etapas manuais. Para tipos de nó com a camada de durabilidade Bronze, etapas adicionais são necessárias durante a escala. Para obter mais informações sobre operações de dimensionamento, confira este guia.

Dimensionamento de nós

O Service Fabric dá suporte ao dimensionamento automático para reduzir horizontalmente e expansão. Cada tipo de nó pode ser configurado para dimensionamento automático de forma independente.

Cada tipo de nó pode ter no máximo 100 nós. Comece com um conjunto menor de nós e adicione mais nós dependendo da carga. Se você precisar de mais de 100 nós em um tipo de nó, precisará adicionar mais tipos de nó. Para obter detalhes, confira Considerações de planejamento de capacidade de cluster do Service Fabric. Um conjunto de dimensionamento de máquinas virtuais não é dimensionado instantaneamente. Portanto, considere esse fator ao configurar regras de dimensionamento automático.

Para dar suporte à redução horizontal automática, configure o tipo de nó para ter a camada de durabilidade Silver ou Gold. Isso garantirá que o dimensionamento seja adiado até que o Service Fabric termine de realocar serviços e que os conjuntos de dimensionamento de máquinas virtuais informem ao Service Fabric que as VMs foram removidas, não apenas temporariamente.

Para obter mais informações sobre o dimensionamento no nível do nó/cluster, confira Dimensionamento de clusters do Azure Service Fabric.

Serviços de dimensionamento

Serviços com estado e sem estado aplicam diferentes abordagens ao dimensionamento.

Dimensionamento automático para serviços sem estado
  • Use o gatilho de carga de partição médio. Esse gatilho determina quando o serviço é reduzido horizontalmente ou expandido, com base em um valor de limite de carga especificado na política de dimensionamento. Você também pode definir a frequência com que o gatilho é verificado. Confira Gatilho de carga média de partição com o dimensionamento baseado em instância. Isso permite que você escale verticalmente até o número de nós disponíveis.
  • Defina InstanceCount como -1 no manifesto do serviço, que informa ao Service Fabric para executar uma instância do serviço em cada nó. Essa abordagem permite que o serviço seja dimensionado dinamicamente conforme o cluster é dimensionado. Conforme o número de nós no cluster é alterado, o Service Fabric cria e exclui automaticamente instâncias de serviço para corresponder.

Observação

Em alguns casos, talvez você queira dimensionar manualmente seu serviço. Por exemplo, se você tiver um serviço que lê dos Hubs de Eventos, talvez queira que uma instância dedicada leia de cada partição do hub de eventos para evitar o acesso simultâneo à partição.

Dimensionamento para serviços com estado

Para um serviço com estado, o dimensionamento é controlado pelo número de partições, pelo tamanho de cada partição e pelo número de partições/réplicas em execução em um determinado computador.

  • Se você estiver criando serviços particionados, verifique se cada nó obterá réplicas adequadas para distribuição uniforme da carga de trabalho sem causar contenções de recursos. Se mais nós forem adicionados, o Service Fabric distribuirá as cargas de trabalho para os novos computadores por padrão. Por exemplo, se houver cinco nós e dez partições, por padrão, o Service Fabric colocará duas réplicas primárias em cada nó. Se você escalar horizontalmente os nós, poderá obter um desempenho maior, pois o trabalho é distribuído uniformemente entre mais recursos. Para obter informações sobre cenários que aproveitam essa estratégia, confira Dimensionamento no Service Fabric.
  • Não há suporte para adicionar ou remover partições. Outra opção comumente usada para dimensionar é criar ou excluir dinamicamente serviços ou instâncias inteiras do aplicativo. Um exemplo desse padrão é descrito em Dimensionar criando ou removendo novos serviços nomeados.

Para obter mais informações, consulte:

Usar métricas para balancear a carga

Dependendo de como você projeta a partição, pode ter nós com réplicas que recebem mais tráfego do que outras. Para evitar essa situação, particione o estado do serviço para que ele seja distribuído em todas as partições. Use o esquema de particionamento de intervalo com um bom algoritmo de hash. Confira Introdução ao particionamento.

O Service Fabric usa métricas para saber como colocar e equilibrar serviços em um cluster. Você pode especificar uma carga padrão para cada métrica associada a um serviço quando esse serviço é criado. O Service Fabric levará essa carga em consideração ao colocar o serviço ou sempre que o serviço precisar se mover (por exemplo, durante as atualizações) para tentar balancear os nós no cluster.

A carga padrão especificada inicialmente para um serviço não será alterada ao longo do tempo de vida do serviço. Para capturar métricas de alteração para um determinado serviço, recomendamos monitorar seu serviço e relatar a carga dinamicamente. Isso permite que o Service Fabric ajuste a alocação com base na carga relatada em um determinado momento. Use o método IServicePartition.ReportLoad para relatar métricas personalizadas. Para obter mais informações, confira Carga dinâmica.

Disponibilidade

Coloque seus serviços em um tipo de nó diferente do tipo de nó primário. Os serviços do sistema do Service Fabric são sempre implantados no tipo de nó primário. Se seus serviços forem implantados no tipo de nó primário, eles poderão competir com os serviços do sistema por recursos e interferir nos serviços do sistema. Se espera-se que um tipo de nó hospede serviços com estado, verifique se há pelo menos cinco instâncias de nó e selecione a camada de Durabilidade Silver ou Gold.

Considere restringir os recursos de seus serviços. Confira Mecanismo de governança de recursos.

  • Não misture os serviços controlados por recursos e não controlados por recursos no mesmo tipo de nó. Os serviços não controlados podem consumir muitos recursos, afetando os serviços controlados por recursos. Especifique restrições de posicionamento para garantir que esses tipos de serviços não sejam executados no mesmo conjunto de nós. Confira Especificar a governança de recurso. (Este é um exemplo do Padrão bulkhead.)
  • Especifique os núcleos de CPU e a memória a serem reservados para uma instância de serviço. Para obter informações sobre o uso e as limitações das políticas de governança de recursos, confira Governança de recursos.

Verifique se a contagem de réplicas ou instâncias de destino de cada serviço é maior que um para evitar um SPOF (único ponto de falha). O maior número que você pode usar como instância de serviço ou contagem de réplicas é igual aos nós numéricos aos quais o serviço é restrito.

Verifique se cada serviço com estado tem pelo menos duas réplicas secundárias ativas. Cinco réplicas são recomendadas para cargas de trabalho de produção.

Para obter mais informações, confira Disponibilidade dos serviços do Service Fabric.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar de segurança.

Aqui estão alguns pontos fundamentais para proteger seu aplicativo no Service Fabric:

Rede virtual

Considere definir limites de sub-rede para cada conjunto de dimensionamento de máquinas virtuais para controlar o fluxo de comunicação. Cada tipo de nó tem seu próprio conjunto de dimensionamento de máquinas virtuais em uma sub-rede dentro da rede virtual do cluster do Service Fabric. NSGs (grupos de segurança de rede) podem ser adicionados às sub-redes para permitir ou rejeitar o tráfego de rede. Por exemplo, com tipos de nó de front-end e back-end, você pode adicionar um NSG à sub-rede de back-end para aceitar o tráfego de entrada apenas a sub-rede de front-end.

Ao chamar os Serviços do Azure externos do cluster, use Pontos de extremidade de serviço de rede virtual se o serviço do Azure dá suporte a ele. O uso de um ponto de extremidade de serviço protege o serviço apenas para o Rede Virtual do cluster. Por exemplo, se você estiver usando o Azure Cosmos DB para armazenar dados, configure a conta do Azure Cosmos DB com um ponto de extremidade de serviço para permitir o acesso somente de uma sub-rede específica. Confira Acessar recursos do Azure Cosmos DB a partir de redes virtuais.

Pontos de extremidade e comunicação entre serviços

Não crie um cluster do Service Fabric não protegido. Se o cluster expuser pontos de extremidade de gerenciamento na Internet pública, usuários anônimos poderão se conectar a ele. Clusters desprotegidos não são compatíveis com cargas de trabalho de produção. Confira: Cenários de segurança do cluster do Service Fabric.

Para proteger suas comunicações entre serviços:

  • Considere habilitar pontos de extremidade HTTPS em seus serviços Web ASP.NET Core ou Java.
  • Estabeleça uma conexão segura entre o proxy reverso e os serviços. Para obter detalhes, confira Conectar-se a um serviço seguro.

Se você estiver usando um Gateway de API, poderádescarregar a autenticação para o gateway. Certifique-se de que os serviços individuais não possam ser acessados diretamente (sem o Gateway da API), a menos que uma segurança extra seja adicionada para autenticar mensagens, independentemente de serem ou não provenientes do gateway.

Não exponha o proxy reverso do Service Fabric publicamente. Isso faz com que todos os serviços que expõem pontos de extremidade HTTP sejam endereçáveis de fora do cluster, introduzindo vulnerabilidades de segurança e possivelmente expondo informações adicionais fora do cluster de forma desnecessária. Se você quiser acessar um serviço publicamente, use um gateway de API. Algumas opções são mencionadas na seção Gateway de API.

A área de trabalho remota é útil para diagnóstico e solução de problemas. Mas certifique-se de não deixá-la aberta. Caso contrário, causará uma falha de segurança.

Segredos e certificados

Armazene segredos, como cadeias de conexão para armazenamentos de dados no Azure Key Vault. O Key Vault deve estar na mesma região que o conjunto de dimensionamento de máquinas virtuais. Você precisará:

  • Autenticar o acesso do serviço ao Key Vault.

    Habilitar a identidade gerenciada no conjunto de dimensionamento de máquinas virtuais que hospeda o serviço.

  • Armazenar seus segredos no Key Vault.

    Adicionar segredos em um formato que possa ser convertido em um par chave-valor. Por exemplo, CosmosDB--AuthKey. Quando a configuração é criada, -- é convertida em :.

  • Acesse esses segredos em seu serviço.

    Adicione o URI do Key Vault em seu appSettings.json. Em seu serviço, adicione o provedor de configuração que lê do Key Vault, compila a configuração e acessa o segredo da configuração criada.

Aqui está um exemplo em que o serviço fluxo de trabalho armazena um segredo no Key Vault no formato CosmosDB--Database.

namespace Fabrikam.Workflow.Service
{
    public class ServiceStartup
    {
        public static void ConfigureServices(StatelessServiceContext context, IServiceCollection services)
        {
            var preConfig = new ConfigurationBuilder()
                …
                .AddJsonFile(context, "appsettings.json");

            var config = preConfig.Build();

            if (config["AzureKeyVault:KeyVaultUri"] is var keyVaultUri && !string.IsNullOrWhiteSpace(keyVaultUri))
            {
                preConfig.AddAzureKeyVault(keyVaultUri);
                config = preConfig.Build();
            }
    }
}

Para acessar o segredo, especifique o nome do segredo na configuração interna.

       if(builtConfig["CosmosDB:Database"] is var database && !string.IsNullOrEmpty(database))
       {
            // Use the secret.
       }

Não use certificados de cliente para acessar o Service Fabric Explorer. Em vez disso, use o Azure AD (Azure Active Directory). Além disso, confira Serviços do Azure que dão suporte à autenticação do Azure AD.

Não use certificados autoassinados para produção.

Proteção de dados inativos

Se você tiver anexado discos de dados aos conjuntos de dimensionamento de máquinas virtuais do cluster do Service Fabric e seus serviços salvarem dados nesses discos, deverá criptografar os discos. Para obter mais informações, confira Criptografar os discos de sistema operacional e de dados anexados em um conjunto de dimensionamento de máquinas virtuais com o Azure PowerShell (versão prévia).

Para obter mais informações sobre a proteção do Service Fabric, confira:

Resiliência

Para se recuperar de falhas e manter um estado totalmente funcional, o aplicativo deverá implementar determinados padrões de resiliência. Aqui estão alguns padrões comuns:

  • Padrão de repetição: para lidar com erros que devem ser transitórios, como recursos que estão temporariamente indisponíveis.
  • Disjuntor: para resolver falhas que podem precisar de mais tempo para corrigir.
  • Padrão bulkhead: para isolar recursos por serviço.

Essa implementação de referência usa o Polly, uma opção de código aberto, para implementar todos esses padrões.

Monitoramento

Antes de explorar as opções de monitoramento, recomendamos que você leia este artigo sobre como diagnosticar cenários comuns com o Service Fabric. Você pode pensar em monitorar dados nestes conjuntos:

Estas são as duas principais opções para analisar os dados:

  • Application Insights
  • Log Analytics

Você pode usar o Azure Monitor para configurar dashboards para monitoramento e enviar alertas aos operadores. Há também algumas ferramentas de monitoramento de terceiros integradas ao Service Fabric, como o Dynatrace. Para obter detalhes, confira Parceiros de Monitoramento do Azure Service Fabric.

Logs e métricas de aplicativo

A telemetria do aplicativo fornece dados sobre seu serviço que podem ajudá-lo a monitorar a integridade do serviço e identificar problemas. Para adicionar rastreamentos e eventos em seu serviço:

O Application Insights fornece muita telemetria interna: solicitações, rastreamentos, eventos, exceções, métricas, dependências. Se o serviço expor pontos de extremidade HTTP, habilite o Application Insights chamando o método de extensão UseApplicationInsights para Microsoft.AspNetCore.Hosting.IWebHostBuilder. Para obter informações sobre como instrumentar seu serviço para o Application Insights, confira estes artigos:

Para exibir os rastreamentos e logs de eventos, use o Application Insights como um dos coletores para registro em log estruturado. Configure o Application Insights com sua chave de instrumentação chamando o método de extensão AddApplicationInsights. Neste exemplo, a chave de instrumentação é armazenada como um segredo no Key Vault.

    .ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddApplicationInsights(hostingContext.Configuration ["ApplicationInsights:InstrumentationKey"]);
        })

Se o serviço não expor pontos de extremidade HTTP, você precisará escrever uma extensão personalizada que envie rastreamentos para o Application Insights. Para obter um exemplo, confira o Serviço de fluxo de trabalho na implementação de referência.

Os serviços do ASP.NET Core usam a interface ILogger para registro em log de aplicativos. Para disponibilizar esses logs de aplicativos no Azure Monitor, envie os eventos ILogger para o Application Insights. Para obter mais informações, confira ILogger em um aplicativo ASP.NET Core. O Application Insights pode adicionar propriedades de correlação a eventos ILogger, úteis para visualizar o rastreamento distribuído.

Para obter mais informações, consulte:

Dados de eventos e integridade do Service Fabric

A telemetria do Service Fabric inclui métricas de integridade e eventos sobre a operação e o desempenho de um cluster do Service Fabric e suas entidades: seus nós, aplicativos, serviços, partições e réplicas.

  • EventStore. Um serviço de sistema com estado que coleta eventos relacionados ao cluster e suas entidades. O Service Fabric usa EventStore para gravar eventos do Service Fabric para fornecer informações sobre seu cluster e pode ser usado para atualizações de status, solução de problemas, monitoramento. Ele também pode correlacionar eventos de diferentes entidades em um determinado momento para identificar problemas no cluster. O serviço expõe esses eventos por meio de uma API REST. Para obter informações sobre como consultar as APIs EventStore, confira Consultar APIs EventStore para eventos de cluster. Você pode exibir os eventos do EventStore no Log Analytics configurando seu cluster com a extensão WAD.
  • HealthStore. Fornece um instantâneo da integridade atual do cluster. Um serviço com estado que agrega todos os dados de integridade relatados por entidades em uma hierarquia. Os dados são visualizados no Service Fabric Explorer. O HealthStore também monitora atualizações de aplicativos. Você pode usar consultas de integridade no PowerShell, um aplicativo .NET ou APIs REST. Confira Introdução ao monitoramento da integridade do Service Fabric.
  • Considere implementar serviços de watchdog personalizados internos. Esses serviços podem relatar periodicamente dados de integridade personalizados, como estados defeituosos de execução de serviços. Para obter mais informações, confira Relatórios de integridade personalizados. Você pode ler os relatórios de integridade usando o Service Fabric Explorer.

Métricas e logs de infraestrutura

As métricas de infraestrutura ajudam você a entender a alocação de recursos no cluster. Aqui estão as principais opções para coletar essas informações:

  • WAD (Diagnóstico do Azure do Windows). Colete logs e métricas no nível do nó no Windows. Você pode usar o WAD configurando a extensão de VM IaaSDiagnostics em qualquer conjunto de dimensionamento de máquinas virtuais mapeado para um tipo de nó para coletar eventos de diagnóstico, como logs de eventos do Windows, contadores de desempenho, sistema ETW/manifestos e eventos operacionais e logs personalizados.
  • Agente do Log Analytics. Configure a extensão de VM MicrosoftMonitoringAgent para enviar logs de eventos do Windows, contadores de desempenho e logs personalizados para o Log Analytics.

Há alguma sobreposição no tipo de métricas coletadas por meio dos mecanismos anteriores, como contadores de desempenho. Onde houver sobreposição, recomendamos usar o agente do Log Analytics. Como não há armazenamento do Azure para o agente do Log Analytics, há baixa latência. Além disso, os contadores de desempenho no IaaSDiagnostics não podem ser alimentados facilmente no Log Analytics.

Monitoramento de infraestrutura no Service Fabric

Para obter mais informações sobre extensões de VM, confira Recursos e extensões de máquina virtual do Azure.

Para exibir os dados, configure o Log Analytics para exibir os dados coletados por meio do WAD. Para obter informações sobre como configurar o Log Analytics para ler eventos de uma conta de armazenamento, confira Configurar o Log Analytics para um cluster.

Você também pode exibir logs de desempenho e dados de telemetria relacionados a um cluster do Service Fabric, cargas de trabalho, tráfego de rede, atualizações pendentes e muito mais. Confira Monitoramento de desempenho com Log Analytics.

A solução Mapa do Serviço no Log Analytics fornece informações sobre a topologia do cluster (ou seja, os processos em execução em cada nó). Envie os dados na conta de armazenamento para o Application Insights. Pode haver algum atraso na obtenção de dados no Application Insights. Se você quiser ver os dados em tempo real, considere configurar o Hub de Eventos usando coletores e canais. Para obter mais informações, confira Coleta e agregação de eventos utilizando o Diagnóstico do Windows Azure.

Métricas de serviço dependentes

  • O Mapa do Aplicativo do Application Insights fornece a topologia do aplicativo usando chamadas de dependência HTTP feitas entre serviços, com o SDK do Application Insights instalado.
  • A solução Mapa do Serviço no Log Analytics fornece informações sobre o tráfego de entrada e de saída de/para serviços externos. Além disso, o Mapa do Serviço integra-se a outras soluções, como atualizações ou segurança.
  • Os watchdogs personalizados podem ser usados para relatar condições de erro em serviços externos. Por exemplo, o serviço poderá relatar um relatório de integridade de erro se não puder acessar um serviço externo ou um armazenamento de dados (Azure Cosmos DB).

Rastreamento distribuído

Na arquitetura de microsserviços, vários serviços geralmente participam para concluir uma tarefa. A telemetria de cada um desses serviços é correlacionada usando campos de contexto (ID da operação, ID da solicitação e assim por diante) em um rastreamento distribuído. Usando o Mapa do Aplicativo no Application Insights, você pode criar a exibição da operação lógica distribuída e visualizar todo o grafo de serviço do aplicativo. Você também pode usar o diagnóstico de transação no Application Insight para correlacionar a telemetria do lado do servidor. Para obter mais informações, confira Diagnóstico de transação entre componentes unificados.

O Mapa do Aplicativo do Application Insights fornece a topologia do aplicativo usando chamadas de dependência HTTP feitas entre serviços, com o SDK do Application Insights instalado. Também é importante correlacionar tarefas que são expedidas de forma assíncrona usando uma fila. Para obter detalhes sobre como enviar telemetria de correlação em uma mensagem de fila, confira Instrumentação de fila.

Para obter mais informações, consulte:

Alertas e dashboards

O Application Insights e o Log Analytics dão suporte a uma linguagem de consulta extensiva (linguagem de consulta Kusto) que permite recuperar e analisar dados de log. Use as consultas para criar conjuntos de dados e visualizá-los nos dashboards de diagnóstico.

Use alertas do Azure Monitor para notificar os sysadmins quando determinadas condições ocorrerem em recursos específicos. A notificação pode ser um email, uma função do Azure, uma chamada de um web hook e assim por diante. Para obter mais informações, confira Alertas no Azure Monitor.

Regras de alerta de pesquisa de log permitem que você defina e execute uma consulta Kusto em um workspace do Log Analytics em intervalos regulares. Um alerta será criado se o resultado da consulta corresponder a uma determinada condição.

Otimização de custo

Use a Calculadora de Preços do Azure para estimar os custos. Outras considerações são descritas na seção Custo em Microsoft Azure Well-Architected Framework.

Aqui estão alguns pontos a serem considerados para alguns dos serviços usados nesta arquitetura.

Azure Service Fabric

Você será cobrado por instâncias de computação, armazenamento, recursos de rede e endereços IP escolhidos ao criar um cluster do Service Fabric. Há cobranças de implantação para o Service Fabric.

conjuntos de escala de máquina virtual

Nessa arquitetura, os microsserviços são implantados em nós que são conjuntos de dimensionamento de máquinas virtuais. Você é cobrado pelas VMs do Azure implantadas como parte do cluster e recursos de infraestrutura subjacentes, como armazenamento e rede. Não há cobranças adicionais para o serviço de conjuntos de dimensionamento de máquinas virtuais.

APIM (Gerenciamento de API do Azure)

O APIM é usado como um gateway para rotear as solicitações de clientes para seus serviços no cluster.

Há diferentes opções de preço. A opção Consumo é cobrada em uma base de pagamento por uso e inclui um componente de gateway. Com base na carga de trabalho, escolha uma opção descrita em preços do Gerenciamento de API.

Azure Application Insights

Os insights do aplicativo são usados para coletar telemetria para todos os serviços e também para exibir os rastreamentos e logs de eventos de maneira estruturada. O preço do Azure Application Insights é um modelo Pagamento Conforme o Uso baseado no volume de dados ingerido e, opcionalmente, para a retenção de dados mais longa. Para obter mais informações, confira Gerenciar o uso e os custos do Application Insights.

Azure Monitor

No Log Analytics do Azure Monitor, você é cobrado pela ingestão e pela retenção de dados. Para obter mais informações, confira Preços do Azure Monitor para obter mais informações.

Cofre de Chave do Azure

O Azure Key Vault é usado para armazenar a chave de instrumentação do Application Insight como um segredo. O Azure Key Vault é oferecido em duas camadas de serviço. Se você não precisar de chaves protegidas por HSM, escolha Padrão. Para obter informações sobre os recursos em cada camada, confira Preços do Key Vault.

Azure DevOps Services

Esta arquitetura de referência usa apenas o Azure Pipelines. O Azure oferece o Azure Pipeline como um serviço individual. Você tem permissão para um trabalho hospedado pela Microsoft gratuito com 1.800 minutos por mês para CI/CD e um trabalho auto-hospedado com minutos ilimitados por mês, trabalhos extras têm cobranças. Para obter mais informações, confira Preço do Azure DevOps Services.

DevOps

Azure Pipelines

A implementação de referência é implantada usando o Azure Pipelines. Para considerações do DevOps em uma arquitetura de microsserviços, confira CI/CD para microsserviços

Você também pode aprender a implantar um aplicativo de contêiner com CI/CD para um cluster do Service Fabric neste tutorial.

Implantar este cenário

Para a implantação de referência para esta arquitetura, siga as etapas em Reposição do GitHub.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi escrito originalmente pelos colaboradores a seguir.

Autor principal:

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.