Na seção anterior, falamos sobre os dois conceitos mais baixos do Service Fabric, um é o Tipo de Nó e o Nó no nível de hardware. A outra é a Aplicação.
Tipo de Nó é uma coleção de Nós, que são abstrações conceituais de máquinas que se implantam. Para Service Fabric, um nó pode ser uma máquina física, uma máquina virtual ou até mesmo o contêiner mais popular atualmente.
Rodando no Tipo de Nó é Application. É uma compreensão abstrata no nível do software de sistema. Existem múltiplos Microserviços em uma aplicação. Mesmo todos os serviços subjacentes do Service Fabric, como o Serviço FailoverManager e o Naming Service, são Micro Serviços.
Todos os recursos distribuídos do Service Fabric correspondem a implantações de Micro Serviços. Podemos ajustar dinamicamente quantas instâncias um Micro Service precisa rodar, em quantos nós distribuir a pressão de carga ou realizar backups de recuperação de desastres. Cada instância escuta uma porta diferente, e a camada de balanceamento de carga distribui as requisições para diferentes instâncias.
Cenário real
O Serviço Estadual é um dos Micro Serviços.
Antes de começarmos a introduzir o Serviço Estatal, vamos considerar os seguintes cenários comuns de negócios.
Você está pensando em implementar um recurso de carrinho de compras no seu site. Após o login, os usuários colocam alguns itens no carrinho de compras.
Na próxima vez que o usuário fizer login, a página da recepção ligará para o serviço de carrinho de compras e precisará reler os dados salvos desse serviço e exibi-los.
Se sim, como você conseguiria isso?
Se o número de usuários não for particularmente grande, adicionaremos uma tabela de carrinho de compras ao banco de dados e a associaremos à tabela de usuários. A tabela de cart terá um campo de ID de usuário e registrará uma grande quantidade de dados de cartuchos de usuário.
Aí isso trará alguns problemas subsequentes.
Se o número de usuários continuar aumentando, o desempenho das tabelas do banco de dados continuará a se degradar.
Os dados das tabelas de banco de dados precisam ser copiados regularmente em caso de perda de dados
Se houver algum problema com desempenho no banco de dados, a tabela precisa ser desmentida ou até mesmo particionada
O próprio sistema de carrinho de compras precisa lidar com quaisquer ajustes no banco de dados, e até mesmo ele precisa ser balanceado com carga
A raiz desse problema é que o sistema em si não foi projetado para ser escalável desde o início. Além disso, bancos de dados são um possível gargalo e ameaça ao desempenho.
Serviço Militar
Vamos considerar uma arquitetura completamente nova.
Desde o início, o sistema de carrinho de compras possui 36 subserviços que lidam com todas as solicitações (36 porque as iniciais do ID de usuário são de 0 a 9 a-z, totalizando 36).
A solicitação do usuário é processada de acordo com o hash inicial do ID de usuário para um subserviço específico.
O subserviço armazena os dados do carrinho de compras internamente por meio de um banco de dados leve e os mantém em seu próprio dispositivo de armazenamento.
Cada sub-serviço também possui 3 backups, que estão constantemente sincronizando os dados armazenados, e esses backups estão sempre rodando em nós diferentes.
Ao mesmo tempo, apenas um backup é responsável por processar requisições como estado de ativação, e quando há um problema na ativação do backup, os outros dois backups ativam um de acordo com o algoritmo de agendamento.
O subsistema de recuperação de desastres cria um novo backup para garantir que o subserviço sempre tenha 3 backups saudáveis.
O Serviço Estadual é uma dessas soluções.
Voltando ao cenário acima, o sistema de carrinho de compras é um serviço com estado.
Os 36 subsistemas são as 36 instâncias desse Serviço Estatal, que chamamos de Partições.
O backup sob cada subsistema é Réplica, e há 3 Réplicas em uma partição.
O backup ativo atualmente é Active Replica, e os dois backups inativos em standby são Secondary Replica.
Cada réplica da mesma Partição deve rodar em um nó diferente.
O código Stateful Service utiliza <T>interfaces como IReliableCollection, IReliableDictionary< T1 e T2 > para salvar dados e sincronizar internamente.
Além disso, o Serviço Com Estado pode implementar os seguintes recursos:
Todos os números acima podem ser resetados, e você pode ter centenas de partições no sistema de cartuchos para carregar mais estresse. Você pode até ter 5 ou mais réplicas por partição para garantir mais robustez.
Sistemas externos não se importam com quantas partições o Serviço Estadual tem, elas são chamadas pela chave de partição. A chave de partição e a partição correspondente são resolvidas pelo Micro Service subjacente do Service Fabric. Por exemplo, no seu negócio, você pode ter alguns milhões de usuários, mas configurar apenas 5 partições. Ao chamar o Serviço Estadual do carrinho de compras, o sistema externo só precisa informar o ID do usuário (chave de partição) e os dados salvos. Essa solicitação é automaticamente mapeada para uma das cinco partições com base no ID do usuário e no algoritmo de hash.
Operações de dados em Serviços Estatais suportam transações. Assim, você pode reverter o fracasso
Espero que a introdução acima possa ajudar você a entender melhor o Serviço Estável.
Vamos abordar exemplos de código para o Serviço Estadual nas seções seguintes. |
Publicado em 15/03/2018 10:03:44
|
|
|
|
