Editar

Compartilhar via

Arquitetura de microsserviços no Azure Service Fabric

Gerenciamento de API do Azure
Cofre de Chave do Azure
Azure Monitor
Azure Pipelines
Azure 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 desta arquitetura está disponível no GitHub.

Arquitetura

Diagrama que mostra a arquitetura de referência 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.

Workflow

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

  • Cluster do Service Fabric. Um cluster é um conjunto de máquinas virtuais (VMs) conectadas em rede nas quais você implanta e gerencia seus microsserviços.

  • 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. Esses recursos de computação também fornecem 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 que tem 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, 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ços 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 isso por meio das Coletas Confiáveis no 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 Azure Pipelines faz parte dos Azure DevOps Services e executa builds, testes e implantações automatizados. Você também pode usar soluções de integração contínua e entrega contínua (CI/CD) de terceiros, como 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, além de logs do contêiner e do nó.

  • Azure Key Vault. Use o Key Vault para armazenar os segredos do aplicativo que os microsserviços usam, 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 orientadores que ajudam a melhorar a qualidade de uma carga de trabalho.

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. Esse arquivo define os tipos de serviços que o aplicativo contém, juntamente com ponteiros para os pacotes de serviços independentes.

O pacote de aplicativos também geralmente contém parâmetros que servem como substituições para determinadas configurações que os serviços usam. 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. 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. Essas informações incluem o nome do serviço, a contagem de instâncias, a política de segurança ou 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?.

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. Essa reversão impede que outro serviço seja atualizado.

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. Por exemplo, coloque tipos de serviço no mesmo tipo de aplicativo caso sua equipe seja responsável por um conjunto de serviços que tenham um dos seguintes atributos:

  • Eles são executados pela mesma duração e precisam ser atualizados ao mesmo tempo.
  • Eles têm o mesmo ciclo de vida.
  • Eles compartilham recursos como dependências ou configuração.

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 se quiser armazenar dados no armazenamento externo. Considere escolher um serviço com estado se uma destas instruções se aplicar:

  • Você deseja manter o estado ou os dados como parte do serviço. Por exemplo, você precisa que esses dados residam na memória próxima ao código.
  • Você não pode permitir uma dependência de um repositório externo.

Se você tiver um código existente que deseja executar no Service Fabric, poderá usá-lo como um executável convidado: 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 de que você precisa 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.

Você é responsável por manter o ambiente no qual um executável convidado é 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 Endpoint 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 uma barra (/). Outra maneira é adicionar a rota no nome do serviço.

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

Para saber mais, veja:

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 tarefas detalhadas, como autenticação, terminação de SSL e a limitação de taxa.

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

  • 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.

    O Gerenciamento de API 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 só está disponível 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.

  • 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 no site do Traefik. Para obter mais informações sobre como usar o Traefik com o Service Fabric, confira a postagem no blog Roteamento inteligente no Service Fabric com Traefik.

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. Você pode usar esses serviços 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 as seguintes recomendações:

  • 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. O Service Fabric dá suporte a todas essas ferramentas e servidores.

    Para a maioria das cargas de trabalho, recomendamos que você use HTTP em vez da comunicação remota de serviço interna ao Service Fabric.

  • 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 e faz com que os pontos de extremidade de serviço sejam alterados dinamicamente.

    Para evitar conexões a pontos finais obsoletos, você pode utilizar o serviço de nomenclatura no Service Fabric para recuperar informações atualizadas do ponto final. No entanto, o Service Fabric também fornece um serviço de proxy reverso interno que abstrai o serviço de nomenclatura. Recomendamos esta opção para descoberta de serviço como linha de base para a maioria dos cenários, porque é mais fácil de usar e resulta em um 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.
  • A classe ServicePartitionClient<TCommunicationClient>, que armazena em cache os pontos de extremidade de serviço. Ela pode permitir um melhor desempenho, porque as chamadas vão diretamente entre os serviços sem intermediários ou protocolos personalizados.

Escalabilidade

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

  • Dimensionar 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 dimensionar horizontalmente em situações em que isso é adequado. Por exemplo, uma intervenção manual pode ser 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. Crie 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 só sejam implantados 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 e as operações de manutenção do conjunto de dimensionamento de máquinas virtuais. Para cargas de trabalho de produção, escolha uma camada Silver ou de durabilidade mais alta. Para obter mais informações sobre cada camada, confira Características de durabilidade do cluster.
  • Se você estiver usando a camada de durabilidade Bronze, determinadas operações exigirão etapas manuais. Tipos de nó com a camada de durabilidade Bronze requerem etapas adicionais durante o dimensionamento. 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. Você pode configurar cada tipo de nó 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 precisar de mais de 100 nós em um tipo de nó, você 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. Essa configuração garante que a redução seja atrasada até que o Service Fabric termine de realocar os serviços. Ele também garante que os conjuntos de dimensionamento de máquinas virtuais informem ao Service Fabric que as VMs foram removidas, não apenas temporariamente inativas.

Para obter mais informações sobre o dimensionamento no nível do nó ou 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.

Para um serviço sem estado (dimensionamento automático):

  • Use o gatilho de carga de partição médio. Esse gatilho determina quando o serviço é dimensionado horizontalmente ou expandido, com base no valor de limite de carga que é 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. Essa abordagem permite que você dimensione 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 do Azure, talvez queira que uma instância dedicada leia de cada partição do hub de eventos. Dessa forma, você pode evitar o acesso simultâneo à partição.

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 ou réplicas em execução em um computador:

  • Se você estiver criando serviços particionados, certifique-se de que cada nó obtenha réplicas adequadas para distribuição uniforme da carga de trabalho sem causar contenções de recursos. Se você adicionar mais nós, 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, o Service Fabric colocará duas réplicas primárias em cada nó por padrão. 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 que costuma ser 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 saber mais, veja:

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 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 serviço, recomendamos monitorar seu serviço e relatar a carga dinamicamente. Essa abordagem 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 (e interferir) com os serviços do sistema por recursos. Se espera-se que um tipo de nó hospede serviços com estado, certifique-se de que haja pelo menos cinco instâncias de nó e de selecionar a camada de durabilidade Silver ou Gold.

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

Aqui estão as considerações comuns:

  • Não misture serviços que são controlados por recursos e serviços que não são controlados por recursos no mesmo tipo de nó. Os serviços não controlados podem consumir muitos recursos e afetam 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. (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.

Para evitar um SPOF (único ponto de falha), certifique-se de que a contagem de réplicas ou instâncias de destino de cada serviço seja maior que um. O maior número que você pode usar como instância de serviço ou contagem de réplicas é igual ao número de nós que restringem o serviço.

Certifique-se de que cada serviço com estado tenha pelo menos duas réplicas secundárias ativas. Recomendamos cinco réplicas 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. Você pode adicionar NSGs (grupos de segurança de rede) à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 der 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, ao usar 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. Consulte Cenários de segurança do cluster do Service Fabric.

Para ajudar a 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 estiver usando um Gateway de API, você 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.

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. Isso introduzirá vulnerabilidades de segurança e potencialmente exporá informações adicionais fora do cluster desnecessariamente. Se você quiser acessar um serviço publicamente, use um gateway de API. A seção Gateway de API mais adiante neste artigo menciona algumas opções.

A Área de Trabalho Remota é útil para diagnóstico e solução de problemas, mas certifique-se de fechá-la. Deixá-la aberta causa uma falha de segurança.

Segredos e certificados

Armazene segredos, como cadeias de conexão para armazenamentos de dados em um key vault. O key vault deve estar na mesma região que o conjunto de dimensionamento de máquinas virtuais. Para usar o key vault:

  1. Autentique 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.

  2. Armazene seus segredos no key vault.

    Adicione segredos em um formato que possa ser convertido em um par chave/valor. Por exemplo, use CosmosDB--AuthKey. Quando a configuração é criada, o hífen duplo (--) é convertido em dois-pontos (:).

  3. 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 de 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 a autenticação do Microsoft Entra ID. Consulte Serviços do Azure que dão suporte à autenticação do Microsoft Entra.

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, consulte 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 preliminar).

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:

  • Repetir: para lidar com erros que você espera que sejam transitórios, como recursos que estão temporariamente indisponíveis.
  • Disjuntor: para resolver falhas que podem levar mais tempo para corrigir.
  • Bulkhead: para isolar recursos para cada 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. Algumas ferramentas de monitoramento de terceiros também são 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 que podem ajudar você 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. O Application Insights pode adicionar propriedades de correlação a eventos do ILogger, o que é útil para visualizar o rastreamento distribuído.

Para saber mais, veja:

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. Os dados de integridade e eventos podem vir de:

  • EventStore. Este serviço de sistema com estado 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 e monitoramento. O EventStore 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 Diagnóstico do Azure para Windows (WAD).

  • HealthStore. Este serviço com estado fornece um instantâneo da integridade atual do cluster. Ele 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.

  • Relatórios de integridade personalizados. Considere a implementação de serviços de watchdog internos que podem relatar periodicamente dados de integridade personalizados, como estados defeituosos de serviços em execução. Você pode ler os relatórios de integridade no 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. 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. Esses eventos podem incluir logs de eventos do Windows, contadores de desempenho, eventos operacionais e do sistema ETW/manifesto 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 nos tipos 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 o agente do Log Analytics não usa o armazenamento do Azure, a latência é baixa. Além disso, os contadores de desempenho no IaaSDiagnostics não podem ser alimentados facilmente no Log Analytics.

Diagrama que mostra o 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 mostrar 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 Hubs de Eventos usando coletores e canais. Para obter mais informações, consulte Agregação e coleta de eventos usando o WAD.

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 e para serviços externos. O Mapa do Serviço integra-se a outras soluções, como atualizações ou segurança.
  • Os watchdogs personalizados podem relatar condições de erro em serviços externos. Por exemplo, o serviço pode fornecer 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

Em uma 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 (como ID da operação, ID da solicitação) em um rastreamento distribuído.

Usando o Mapa do Aplicativo no Application Insights, você pode criar a exibição de operações lógicas distribuídas e visualizar todo o grafo de serviço do aplicativo. Você também pode usar o diagnóstico de transação no Application Insights para correlacionar a telemetria do lado do servidor. Para obter mais informações, confira Diagnóstico de transação entre componentes unificados.

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 saber mais, veja:

Alertas e painéis

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 painéis de diagnóstico.

Use alertas do Azure Monitor para notificar os administradores de sistemas 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 webhook, por exemplo 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 no pilar de otimização de custo do 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 que você escolhe 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 incrementais para os próprios Conjuntos de Dimensionamento de Máquinas Virtuais.

Gerenciamento de API do Azure

O Gerenciamento de API do Azure é um gateway para rotear as solicitações de clientes para seus serviços no cluster.

Há várias 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.

Application Insights

Você pode usar os Application Insights 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 Application Insights consiste em um modelo de pagamento conforme o uso que é baseado no volume de dados ingerido e em opções para retenção de dados mais longa. Para obter mais informações, confira Gerenciar o uso e o custo do Application Insights.

Azure Monitor

No Log Analytics do Azure Monitor, você é cobrado pela ingestão e pela retenção de dados. Para saber mais, confira Preço do Azure Monitor.

Cofre de Chave do Azure

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

Azure DevOps Services

Essa arquitetura de referência usa o Azure Pipelines para desenvolvimento. O Azure Pipelines permite 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 encargos. Para obter mais informações, consulte Preços do Azure DevOps Services.

Para considerações do DevOps em uma arquitetura de microsserviços, confira CI/CD para microsserviços.

Para aprender a implantar um aplicativo de contêiner com CI/CD para um cluster do Service Fabric, consulte este tutorial.

Implantar este cenário

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

Próximas etapas