Explicação detalhada da "alta disponibilidade" da arquitetura da Internet

1. O que é alta disponibilidade?

Alta disponibilidade HA (High Availability) é um dos fatores que devem ser considerados no projeto da arquitetura de sistemas distribuídos, geralmente se refere à redução do tempo em que o sistema não consegue fornecer serviços por meio do projeto.

Supondo que o sistema sempre possa fornecer serviços, dizemos que a disponibilidade do sistema é de 100%.

Se o sistema não for capaz de fornecer serviços a cada 100 unidades de tempo em execução, dizemos que a disponibilidade do sistema é de 99%.

A meta de alta disponibilidade de muitas empresas é de quatro noves, o que equivale a 99,99%, o que significa que o tempo de inatividade anual do sistema é de 8,76 horas.

A página inicial de pesquisa do Baidu é reconhecida na indústria como um sistema com excelentes garantias de alta disponibilidade. As pessoas até  julgam a "conectividade de rede" pela possibilidade de acessar www.baidu.com

2. Como garantir alta disponibilidade do sistema

Todos nós sabemos que os pontos únicos são inimigos da alta disponibilidade do sistema. Os pontos únicos costumam ser o maior risco e inimigo da alta disponibilidade do sistema. Devemos tentar evitar pontos únicos no processo de design do sistema. Metodologicamente, o princípio da garantia de alta disponibilidade é "clustering", ou "redundância": existe apenas um ponto, e o serviço será afetado se cair; se houver um backup redundante, haverá outros backups que podem assumir se ele cair.

Para garantir a alta disponibilidade do sistema, o princípio fundamental do projeto de arquitetura é: redundância.

Não basta ter redundância, cada vez que ocorre uma falha é necessária uma intervenção manual para restaurá-la, o que inevitavelmente aumentará a inutilização do sistema. Portanto, a alta disponibilidade do sistema é muitas vezes alcançada por meio de “ failover automático ”.

A seguir, veremos como garantir a alta disponibilidade do sistema por meio de redundância + failover automático em uma arquitetura típica de Internet .

3. Arquitetura comum em camadas da Internet

 

As arquiteturas comuns distribuídas pela Internet são como acima, divididas em:

(1) Camada do cliente : O chamador típico é um navegador ou aplicativo móvel APP

(2) Camada de proxy reverso : entrada do sistema, proxy reverso

(3) Camada de aplicativo do site : implemente a lógica principal do aplicativo e retorne html ou json

(4) Camada de serviço : Se a servitização for realizada, haverá esta camada

(5) Camada de cache de dados : o cache acelera o acesso ao armazenamento

(6) Camada de banco de dados : armazenamento de dados solidificados em banco de dados

A alta disponibilidade de todo o sistema é alcançada de forma abrangente através de redundância + failover automático em cada camada.

4. Prática de arquitetura de alta disponibilidade em camadas

4.1 Alta disponibilidade de [Camada de cliente-> Camada de proxy reverso]


A alta disponibilidade da [Camada de Cliente] para a [Camada de Proxy Reverso] é alcançada através da redundância da camada de proxy reverso. Tomemos o nginx como exemplo: existem dois nginx, um fornece serviços on-line e o outro é redundante para garantir alta disponibilidade.Uma prática comum é manter a detecção de sobrevivência viva, e o mesmo IP virtual fornece serviços.

Failover automático : quando o nginx desliga, o keepalived pode detectá-lo, executar o failover automaticamente e migrar automaticamente o tráfego para o shadow-nginx. Como o mesmo IP virtual é usado, esse processo de comutação é transparente para o chamador.

4.2 Alta disponibilidade de [camada de proxy reverso -> camada de site]

A alta disponibilidade da [camada de proxy reverso] para a [camada de site] é alcançada por meio de redundância na camada de site. Supondo que a camada de proxy reverso seja nginx, vários back-ends da web podem ser configurados em nginx.conf e o nginx pode detectar a viabilidade de vários back-ends.

Failover automático : quando o servidor web trava, o nginx pode detectá-lo, realizar failover automaticamente e migrar automaticamente o tráfego para outros servidores web. Todo o processo é concluído automaticamente pelo nginx e é transparente para o chamador.

4.3 Alta disponibilidade de [camada de site -> camada de serviço]

A alta disponibilidade  da [camada local] até a [camada de serviço] é alcançada por meio de redundância na camada de serviço. O "pool de conexões de serviço" estabelecerá múltiplas conexões com serviços downstream e cada solicitação selecionará "aleatoriamente" uma conexão para acessar o serviço downstream.

Failover automático : quando o serviço é interrompido, o pool de conexões de serviço pode detectá-lo, executar o failover automaticamente e migrar automaticamente o tráfego para outros serviços. Todo o processo é concluído automaticamente pelo pool de conexões e é transparente para o chamador. (Então O pool de conexões de serviço no cliente RPC é um componente básico muito importante).

4.4 Alta disponibilidade de [Camada de Serviço>Camada de Cache]

A alta disponibilidade da [camada de serviço] para a [camada de cache] é alcançada através da redundância de dados armazenados em cache.

Existem várias maneiras de implementar redundância de dados na camada de cache: a primeira é usar o encapsulamento do cliente e o serviço para leitura ou gravação dupla no cache.

A camada de cache também pode resolver o problema de alta disponibilidade da camada de cache por meio de um cluster de cache que suporta sincronização mestre-escravo .

Tomemos o Redis como exemplo. O Redis suporta naturalmente a sincronização mestre-escravo. O Redis oficialmente também possui um mecanismo sentinela para fazer a detecção de sobrevivência do Redis.

Depois de falar sobre a alta disponibilidade do cache, quero dizer mais uma coisa aqui. A empresa não tem necessariamente requisitos de "alta disponibilidade" para o cache. Mais cenários de uso do cache são para "acelerar o acesso aos dados": colocar parte dos dados no cache. Aqui, se o cache travar ou não atingir, você pode ir para o banco de dados back-end para recuperar os dados.

Para este tipo de cenário de negócio que permite “cache miss”, as recomendações para a arquitetura de cache são:

Encapsule o cache kv em um cluster de serviço e configure um proxy upstream (o proxy pode usar redundância de cluster para garantir alta disponibilidade). O backend do proxy é dividido horizontalmente em várias instâncias de acordo com a chave acessada pelo cache. Acesso a cada instância não é concluída. Alta disponibilidade.
 


A instância do cache desliga e é protegida : quando uma instância dividida horizontalmente desliga, a camada proxy retorna diretamente uma falta de cache.Neste momento, o desligamento do cache também é transparente para o chamador. As principais instâncias de fragmentação horizontal são reduzidas e o novo hash não é recomendado, pois isso pode facilmente causar inconsistências nos dados armazenados em cache.

4.5 Alta disponibilidade de [camada de serviço>camada de banco de dados]

Na maioria das tecnologias da Internet, a camada de banco de dados usa uma arquitetura de "sincronização mestre-escravo, separação de leitura e gravação", de modo que a alta disponibilidade da camada de banco de dados é dividida em duas categorias: "alta disponibilidade de leitura de banco de dados" e "alta disponibilidade de gravação de banco de dados" .

Alta disponibilidade de [Camada de Serviço> Camada de Banco de Dados "Leitura"]

A alta disponibilidade da [camada de serviço] para [leitura do banco de dados] é alcançada através da redundância do banco de dados de leitura.

Como o banco de dados de leitura é redundante, em geral, existem pelo menos 2 bancos de dados escravos. O "conjunto de conexões de banco de dados" estabelecerá múltiplas conexões com o banco de dados de leitura, e cada solicitação será roteada para esses bancos de dados de leitura.


Failover automático : quando a biblioteca de leitura trava, o db-connection-pool pode detectá-la, executar o failover automaticamente e migrar automaticamente o tráfego para outras bibliotecas de leitura. Todo o processo é concluído automaticamente pelo pool de conexões e o chamador é transparente (então o pool de conexões de banco de dados no DAO é um componente básico muito importante).

[Camada de serviço> Camada de banco de dados "gravação"] alta disponibilidade


A alta disponibilidade da [camada de serviço] até [escrita do banco de dados] é alcançada através da redundância do banco de dados de gravação.

Tomando o mysql como exemplo, você pode configurar duas sincronizações mysql dual-master, uma para fornecer serviços on-line e outra para fornecer redundância para garantir alta disponibilidade.Uma prática comum é manter a detecção de sobrevivência ativa, e o mesmo IP virtual fornece serviços .

Failover automático : quando a biblioteca de gravação trava, o keepalived pode detectá-la, executar o failover automaticamente e migrar automaticamente o tráfego para shadow-db-master. Como o mesmo IP virtual é usado, esse processo de comutação é muito prejudicial para o chamador. Seja transparente. .

Acho que você gosta

Origin blog.csdn.net/m0_68949064/article/details/128946795
Recomendado
Clasificación