Artigo de: Projeto de sistema concorrente de bilhões de níveis do Alibaba (versão 2021)
Link: https://pan.baidu.com/s/1lbqQhDWjdZe1CBU-6U4jhA Código de extração: 8888
índice
Idéias para design de sistema de alta disponibilidade
Após o início do curso, alguns alunos relataram que houve mais explicações de conhecimentos teóricos no curso e esperam ver exemplos. Tenho prestado atenção a essas vozes e agradeço suas sugestões, no início de 04 gostaria de responder.
Ao projetar o curso, quero principalmente usar as cinco primeiras aulas do capítulo básico para apresentá-lo a alguns conceitos básicos sobre o projeto de sistema de alta concorrência. Espero ajudá-lo a estabelecer uma estrutura geral, de modo que seja conveniente para o capítulos de evolução subsequentes e capítulos de combate reais. Expanda e estenda os pontos de conhecimento envolvidos um por um. Por exemplo, esta lição mencionou desclassificação, então irei apresentar os tipos de esquemas de desclassificação e cenários aplicáveis em detalhes no capítulo de operação e manutenção na forma de casos. A razão para este projeto é esperar que os cursos sejam interligados por meio de um pequeno espaço na seção anterior. Leve o ponto para a superfície e expanda gradualmente. Claro, vozes diferentes são minha motivação para otimizar continuamente o conteúdo do curso. Vou levar cada sugestão a sério, otimizar continuamente o curso e trabalhar duro e progredir com você.
A seguir, vamos entrar formalmente no curso. Nesta lição, continuarei a levá-lo a entender o segundo objetivo do design de sistema de alta simultaneidade - alta disponibilidade. Você precisa ter uma compreensão intuitiva das idéias e métodos para melhorar a usabilidade do sistema nesta lição, de modo que, quando explicar este conteúdo ao ponto no seguimento, você possa reagir imediatamente e também pode consultar quando seu sistema encontra problemas de usabilidade.Estes métodos são otimizados.
Alta disponibilidade (HA)
Alta disponibilidade (HA) é um termo que você ouve frequentemente ao projetar um sistema . Refere-se à capacidade do sistema de operar sem falhas .
A solução HA que vemos em muitos documentos de componentes de código aberto é uma solução para melhorar a disponibilidade do componente e evitar que o sistema fique inativo e fique inutilizável. Por exemplo, você sabe que o NameNode no Hadoop 1.0 é um ponto único. Quando ocorre uma falha, todo o cluster ficará indisponível; e a solução NameNode HA proposta no Hadoop 2 é iniciar dois NameNodes ao mesmo tempo, um no Active e o outro no estado de espera, os dois compartilham o armazenamento. Uma vez que o NameNode ativo falha, o NameNode em espera pode ser alternado para o estado ativo para continuar a fornecer serviços, o que aumenta a capacidade do Hadoop de executar continuamente sem falha, o que também melhora sua disponibilidade.
De modo geral, para um sistema com alta simultaneidade e grande tráfego, a falha do sistema prejudicará mais a experiência do usuário do que o baixo desempenho do sistema. Imagine um sistema com mais de um milhão de usuários ativos diariamente, e uma falha de um minuto pode afetar milhares de usuários. E conforme a atividade diária do sistema aumenta, o número de usuários afetados pelo tempo de falha de um minuto também aumenta, e o sistema tem requisitos mais altos de disponibilidade.
Então, hoje, vou levá-lo a entender como podemos garantir a alta disponibilidade do sistema em alta simultaneidade, a fim de fornecer algumas idéias para o design do seu sistema.
Medição de usabilidade
Usabilidade é um conceito abstrato, você precisa saber medi-lo, os conceitos relacionados são: MTBF e MTTR .
MTBF (Tempo Médio Entre Falhas): É o tempo médio entre falhas, representando o tempo entre duas falhas , que é o tempo médio para o sistema operar normalmente. Quanto mais tempo, maior será a estabilidade do sistema .
MTTR (Mean Time To Repair): Significa o tempo médio de recuperação da falha, e também pode ser entendido como o tempo médio até a falha. Quanto menor o valor, menor é o impacto da falha no usuário .
A disponibilidade está intimamente relacionada aos valores de MTBF e MTTR. Podemos usar a seguinte fórmula para expressar a relação entre eles: Disponibilidade = MTBF / (MTBF + MTTR) O resultado calculado por esta fórmula é uma razão, e essa razão representa a disponibilidade do sistema. De modo geral, usaremos alguns noves para descrever a disponibilidade do sistema.
Na verdade, a partir desta foto, você pode descobrir que a disponibilidade de um nove e dois noves é muito fácil de alcançar.Contanto que não haja uma empilhadeira da Escola Técnica Lanxiang, isso pode ser alcançado basicamente por meio de operação e manutenção humanas.
Após três noves, o tempo de falha anual do sistema caiu drasticamente de 3 dias para 8 horas. Depois de quatro noves, o tempo de falha anual foi reduzido para menos de uma hora. Com esse nível de disponibilidade, você pode precisar estabelecer um sistema completo de operação e manutenção, procedimentos de solução de problemas e procedimentos de mudança de negócios. Você também pode precisar ter mais consideração no design do sistema. Por exemplo, durante o desenvolvimento, você deve considerar se ele pode se recuperar automaticamente sem intervenção manual se ocorrer uma falha. É claro que, em termos de construção de ferramentas, você também precisa fazer mais melhorias para solucionar rapidamente a causa da falha e restaurar o sistema rapidamente.
Depois de atingir cinco noves, a falha não pode ser recuperada por mão de obra. Imagine que, desde a ocorrência de uma falha até o momento em que você recebe um alarme, até o momento em que liga o computador e faz login no servidor para solucionar o problema, isso pode ter durado dez minutos. Portanto, esse nível de disponibilidade examina a tolerância a desastres do sistema e os recursos de recuperação automática.Somente permitindo que as máquinas tratem as falhas, os indicadores de disponibilidade serão elevados a um nível mais alto .
De modo geral, a disponibilidade de nosso sistema de negócios principal precisa chegar a quatro noves, e a disponibilidade de sistemas não principais é tolerada no máximo três noves. No trabalho real, você pode ter ouvido declarações semelhantes, mas sistemas de diferentes níveis e diferentes cenários de negócios têm diferentes requisitos de disponibilidade.
No momento, você tem um certo grau de compreensão dos indicadores de avaliação de disponibilidade. A seguir, vamos dar uma olhada nos fatores que precisam ser considerados no projeto de um sistema de alta disponibilidade.
Idéias para design de sistema de alta disponibilidade
A disponibilidade de um sistema maduro deve ser garantida a partir de dois aspectos: projeto do sistema e operação e manutenção do sistema , os quais funcionam juntos e são indispensáveis. Então, como começar a partir desses dois aspectos para resolver o problema de alta disponibilidade do sistema?
1. Projeto do Sistema
"Projetar para falhas" é nosso primeiro princípio ao projetar sistemas de alta disponibilidade. Em um sistema de alta simultaneidade que realiza um milhão de QPS, o número de máquinas no cluster é centenas ou milhares, e a falha de uma única máquina é normal, e as falhas podem ocorrer quase todos os dias. Planeje com antecedência para ganhar mil milhas. Quando estamos projetando o sistema, devemos levar a ocorrência de falhas como uma consideração importante e considerar com antecedência como encontrar as falhas automaticamente e como resolvê-las depois que as falhas ocorrerem . Obviamente, além de pensar no futuro, também precisamos dominar alguns métodos de otimização específicos, como failover (failover), controle de tempo limite e downgrade e limitação de corrente .
De modo geral, pode haver duas situações para um nó que executa failover:
- É um failover entre nós completamente pares.
- É entre nós desiguais, ou seja, existem nós primários e nós em espera no sistema.
O failover entre nós de mesmo nível é relativamente simples. Nesse tipo de sistema, todos os nós são responsáveis pelo tráfego de leitura e gravação e nenhum estado é armazenado nos nós, e cada nó pode ser uma imagem espelhada de outro nó. Nesse caso, se o acesso a um determinado nó falhar, basta visitar outro nó aleatoriamente . Por exemplo, o Nginx pode ser configurado para tentar novamente solicitar outro nó Tomcat quando uma solicitação Tomcat maior que 500 aparecer, da seguinte maneira:
O mecanismo de failover para nós não pares é muito mais complicado. Por exemplo, temos um nó primário e vários nós de standby. Esses nós de standby podem ser hot standby (nós de standby que também fornecem serviços online) ou cold standby (usado apenas como backup), então precisamos incluir no código Controlar como para detectar se as máquinas principal e em espera estão com defeito e como alternar entre as máquinas principal e em espera. O mecanismo de detecção de falhas mais amplamente usado é o "batimento cardíaco" . Você pode enviar pacotes de pulsação periodicamente para o nó mestre no cliente ou pode enviar pacotes de pulsação periodicamente do nó de backup. Quando o pacote de pulsação não é recebido por um período de tempo, pode-se considerar que o nó mestre falhou e a operação de eleição do mestre pode ser acionada. O resultado da eleição do mestre precisa ser acordado em vários nós de backup, então um determinado algoritmo de consenso distribuído será usado, como Paxos e Raft .
Além do failover, o controle de tempos limite de chamada entre sistemas também é uma consideração importante no projeto de sistemas altamente disponíveis .
Sistemas complexos de alta simultaneidade geralmente consistem em muitos módulos de sistema e também dependem de muitos componentes e serviços, como componentes de cache, serviços de fila e assim por diante. A chamada mais temida entre eles é o atraso, e não a falha , porque a falha geralmente é instantânea e pode ser resolvida com uma nova tentativa. Assim que ocorrer um atraso relativamente grande na chamada de um determinado módulo ou serviço, o chamador será bloqueado nesta chamada e os recursos que ocupou não poderão ser liberados . Quando houver um grande número de solicitações de bloqueio, o chamador desligará porque seus recursos acabam. No estágio inicial de desenvolvimento do sistema, o controle de tempo limite geralmente é ignorado ou não há como determinar o período de tempo limite correto.
Já experimentei um projeto antes, no qual os módulos são chamados por meio da estrutura RPC e o período de tempo limite é de 30 segundos por padrão. Normalmente, o sistema é executado de forma muito estável, mas uma vez que encontra uma quantidade relativamente grande de tráfego e um certo número de solicitações lentas aparecem no servidor RPC, a thread do cliente RPC será bloqueada nessas solicitações lentas por 30 segundos, fazendo com que o cliente RPC use Desligar enquanto o tópico for chamado. Posteriormente, depois de descobrirmos esse problema durante a revisão de falha, ajustamos o período de tempo limite de RPC, banco de dados, cache e serviços de chamada de terceiros, para que um tempo limite possa ser acionado quando ocorre uma solicitação lenta, sem causar uma avalanche geral do sistema . Já que o controle de tempo limite deve ser feito, como determinamos o período de tempo limite? Este é um problema mais difícil.
Se o período de tempo limite for curto, isso causará muitos erros de tempo limite e afetará a experiência do usuário; se o período de tempo limite for longo, não funcionará. Eu sugiro que você colete os registros de chamadas entre os sistemas para calcular o tempo de resposta de 99% e, em seguida, especifique o período de tempo limite com base nesse tempo. Se não houver registro de chamadas, você só poderá especificar o período de tempo limite com base na experiência. No entanto, independentemente do método usado, o período de tempo limite não é estático e precisa ser modificado continuamente no processo de manutenção do sistema subsequente.
O controle de tempo limite não serve para manter a solicitação para sempre, mas para reprovar a solicitação após um determinado período de tempo e liberar os recursos para a próxima solicitação . Isso é prejudicial para os usuários, mas é necessário porque sacrifica um pequeno número de solicitações enquanto garante a disponibilidade de todo o sistema.
E temos duas outras soluções com perdas para garantir a alta disponibilidade do sistema, elas são degradação e limitação de corrente.
O downgrade é uma prática de sacrificar serviços não essenciais para garantir a estabilidade dos serviços principais . Por exemplo, quando postamos um Weibo, primeiro passamos pela inspeção do serviço anti-spam para detectar se o conteúdo é um anúncio e, em seguida, concluímos a lógica, como gravar no banco de dados após transmiti-lo. A detecção de anti-spam é uma operação relativamente pesada, porque envolve muita correspondência de política. Embora seja demorada no tráfego diário, ela ainda pode responder normalmente. Mas quando a simultaneidade é alta, pode se tornar um gargalo e não é o processo principal de publicação do Weibo, portanto, podemos desligar temporariamente a detecção do serviço anti-spam, o que pode garantir que o processo principal seja mais estável.
A limitação de corrente é outra forma de pensar, ela protege o sistema ao limitar a taxa de solicitações simultâneas. Por exemplo, para aplicativos da web, eu limito uma única máquina para processar apenas 1.000 solicitações por segundo, e a parte excedente retornará diretamente um erro para o cliente. Embora essa abordagem prejudique a experiência do usuário, é um ato impotente sob extrema simultaneidade e é um comportamento de curta duração, portanto, é aceitável. Na verdade, seja rebaixamento ou limitação de corrente, ainda há muito o que discutir em detalhes.Eu analisarei em profundidade à medida que o sistema continua a evoluir em cursos posteriores, e não vou falar sobre isso no básico.
2. Operação e manutenção do sistema
Na fase de projeto do sistema, a fim de garantir a disponibilidade do sistema, os métodos acima podem ser adotados. O que pode ser feito no nível de operação e manutenção do sistema? Na verdade, podemos considerar como melhorar o sistema a partir dos dois aspectos de liberação cinza e broca de falha .
Você deve saber que, durante o bom funcionamento do negócio, o sistema raramente falha e 90% das falhas ocorrem durante a fase de mudança online. Por exemplo, se você tiver um novo recurso, o número de solicitações lentas do banco de dados dobrará devido a um problema de design, fazendo com que as solicitações do sistema sejam lentas e funcionem mal. Se não houver mudança, como o banco de dados pode gerar tantas requisições lentas sem motivo? Portanto, para melhorar a disponibilidade do sistema, é importante estar atento ao gerenciamento de mudanças. Além de fornecer o plano de reversão necessário para reverter e recuperar rapidamente no caso de um problema, outro método importante é a liberação cinza.
A liberação cinza refere-se ao fato de que as alterações do sistema não são enviadas online todas de uma vez, mas gradualmente avançam de acordo com uma certa proporção. Em geral, a publicação em tons de cinza é realizada na dimensão da máquina. Por exemplo, primeiro fazemos alterações em 10% das máquinas e observamos os indicadores de desempenho do sistema e logs de erros no Painel. Se os indicadores do sistema estiverem relativamente estáveis após a execução por um período de tempo e não houver um grande número de logs de erros, a quantidade total de alteração será promovida.
A versão cinza oferece uma excelente oportunidade para os alunos de desenvolvimento e operação e manutenção, permitindo-lhes observar o impacto das mudanças no tráfego online, um nível importante para garantir a alta disponibilidade do sistema.
A liberação cinza é um método de operação e manutenção que garante a alta disponibilidade do sistema nas condições normais de operação do sistema. Então, como sabemos o desempenho do sistema quando ocorre uma falha? Aqui contamos com outro método: broca de falha.
Os exercícios de falha referem-se a alguns métodos destrutivos do sistema para observar como o sistema geral se comporta quando ocorre uma falha local, a fim de descobrir possíveis problemas de disponibilidade no sistema.
Um sistema complexo de alta simultaneidade depende de muitos componentes, como discos, bancos de dados, placas de rede, etc. Esses componentes podem falhar a qualquer hora e em qualquer lugar e, uma vez que falhem, o serviço geral ficará indisponível como um efeito borboleta? O quê? Nós não sei, então os exercícios de falha são particularmente importantes.
Na minha opinião, os exercícios de falha são iguais ao pensamento mais popular da "Engenharia do Caos". Como o criador da engenharia do caos, a ferramenta "Macaco do Caos" lançada pela Netfix em 2010 é uma excelente ferramenta para os exercícios de falha . Ele simula falhas fechando aleatoriamente os nós online no sistema online, para que os engenheiros possam compreender o impacto de tais falhas.
Claro, tudo isso é baseado na premissa de que seu sistema pode suportar algumas situações anormais. Se o seu sistema ainda não alcançou isso, sugiro que você construa outro sistema off-line que seja exatamente igual à estrutura de implantação on-line e execute simulações de falha nesse sistema para evitar afetar o sistema de produção.
Resumo do curso
Nesta lição, levei você a entender como medir a disponibilidade do sistema e como garantir alta disponibilidade ao projetar um sistema altamente simultâneo. Dito isso, você pode ver que, da perspectiva de desenvolvimento e operação, as maneiras de melhorar a usabilidade são diferentes:
O desenvolvimento se concentra em como lidar com falhas e as palavras-chave são redundância e compensações . Redundância refere-se ao fato de que existem nós sobressalentes e clusters para substituir serviços com falha, como o failover mencionado no artigo, e a arquitetura multi-ativa, etc .: A escolha refere-se à perda da polícia e à segurança do serviço principal.
Do ponto de vista de operação e manutenção, é mais conservador, focando em como evitar falhas, como dar mais atenção ao gerenciamento de mudanças e como realizar simulações de falhas.
A combinação dos dois pode formar um sistema completo de alta disponibilidade.
Você também precisa observar que melhorar a usabilidade do sistema às vezes se baseia em sacrificar a experiência do usuário ou o desempenho do sistema.Também requer muita mão de obra para construir o sistema correspondente e melhorar o mecanismo. Portanto, devemos compreender um grau e não devemos fazer otimização excessiva. Como mencionei no artigo, a disponibilidade de quatro noves no sistema central já pode atender à demanda, não há necessidade de buscar cegamente a disponibilidade de cinco noves ou mesmo seis noves.
Além disso, os sistemas ou componentes gerais buscam o desempenho final, então, existem aqueles que não buscam o desempenho, mas apenas buscam a usabilidade final? A resposta é sim. Por exemplo, para um sistema com distribuição de configuração, ele só precisa fornecer uma configuração quando outros sistemas são iniciados, para que possa ser retornado em segundos, e está OK em dez segundos, o que nada mais é do que aumentar a velocidade de inicialização de outros sistemas. No entanto, seus requisitos de disponibilidade são extremamente altos, chegando até a seis noves, o motivo é que a configuração pode ser obtida lentamente, mas não pode ser obtida.
Dou este exemplo para que você saiba que às vezes há compensações entre usabilidade e desempenho, mas a escolha depende de sistemas diferentes e não pode ser generalizada.