Registro de evolução de arquitetura de projeto de snap-up de máscara de alta simultaneidade e compartilhamento de experiência de otimização

Registro de evolução de arquitetura de projeto de snap-up de máscara de alta simultaneidade e compartilhamento de experiência de otimização

Pedra Makihara

Autor: Yang Mu original (apelido original, criação de animais), especialistas em tecnologia de nuvem Ali, anos de sistema operacional e experiência em depuração de aplicativos, profundo conhecimento teórico, experiência prática. Atualmente com foco no ajuste de desempenho do Linux, clusters de contêiner e rede de sistema.
Este artigo foi autorizado pelo autor original para ser publicado na conta pública "Programa Ape Stone", com ligeiras modificações com base no texto original.

fundo

---

No início da epidemia, o governo de um determinado local decidiu emitir um lote de máscaras gratuitas para os cidadãos da cidade, e os cidadãos desta cidade podem fazer marcação de recolha gratuitamente. O horário de atendimento é das 9h às 12h am. Portanto, esta cena é uma cena de compra urgente de tempo limitado e enfrentará um tempo muito grande. Para o problema de grande tráfego e grande concorrência, durante a implementação do projeto, alguns registros e reflexões foram feitos sobre a evolução do a arquitetura envolvida.

Diagrama de Arquitetura e Análise-V1

---

Ilustração e análise da arquitetura original (arquitetura original por volta das 22h de

2 de fevereiro ) Arquitetura original por volta das 22h de 2 de fevereiro

1. O cliente usa o protocolo HTTPS para acessar diretamente o ECS;
2. Use Nginx no ECS para monitorar a porta HTTPS 443;
3. Nginx reverte Tomcat, Nginx processa arquivos estáticos e Tomcat processa solicitações dinâmicas;
4. O programa vai primeiro ao Redis para verificar a cache, em caso de falha, vai à base de dados para consultar os dados, ao mesmo tempo que a sincronização dos dados entre o Redis e o Mysql é controlada pelo programa.

Este projeto de arquitetura:

• Vantagens: fácil de gerenciar, fácil de implantar;
• Desvantagens: baixo desempenho, falta de escalabilidade e um único ponto de risco; o
  resultado: o aplicativo foi desligado imediatamente assim que ficou online e a página de agendamento vazou por motivos desconhecidos, fazendo com que o serviço ser desligado antes da hora marcada.
  Diagrama de arquitetura e análise-V2

---

Em seguida, intervimos e ajustamos a arquitetura. Pedimos-nos por volta das 24h para iniciar o serviço às 9h. O horário é muito curto, a tarefa é muito pesada e o programa não pode ser movido. Como fazer a arquitetura simultânea do centenas de milhares?
A arquitetura por volta das 9h do dia 3 de fevereiro, e a arquitetura foi restaurada no dia 4) A arquitetura

por volta das 9h do dia 3 de fevereiro

1. Conecte ao SLB, expanda a capacidade de carga horizontalmente por meio de espelhamento;
2. Acesso à arquitetura de banco de dados de separação de leitura e gravação, separação automática de leitura e gravação através do banco de dados Alibaba Cloud e sincronização automática de dados;
3. Ajuste o protocolo Nginx;
4. O cluster standby da mesma arquitetura é habilitado (dois registros A são feitos para resolução de nome de domínio);
5. Analisando o log de acesso, constatou-se que o motivo da falha estava no ponto de obtenção do SMS e login e inicialização do Cookie.

Este projeto de arquitetura:

• Vantagens: Maior disponibilidade e capacidade de carga expandida;
• Desvantagens: estimativa de tráfego insuficiente, páginas estáticas também estão no ECS, então a largura de banda de saída do SLB uma vez atingiu o valor máximo de 5.XG e a simultaneidade chegou a 22w +.
  Resultado: o usuário não conseguiu abrir a página por um tempo devido ao tráfego excessivo. Ao mesmo tempo, devido à restrição do provedor de serviços de nomes de domínio XX, o cliente não pôde adicionar resoluções por si mesmo e o atendimento ao cliente de o provedor de serviços de nome de domínio não pôde ser contatado naquela noite, o que fez com que o plano de CDN fosse interrompido.

  Diagrama de Arquitetura e Análise-V3

---

Arquitetura em 5 de fevereiro

1. Acesso ao CDN para descarregar largura de banda ultragrande;
2. Cancelar proxy Nginx;
3. Desenvolveu um plano de troca de recuperação de desastres para que o novo programa não pudesse ficar online a tempo (eu não esperava que fosse usado);
4. Use um grupo de servidores virtuais para alternar entre programas novos e antigos, mas a desvantagem é que um backend SLB de monitoramento de sete camadas pode travar apenas 200 máquinas, e mais nenhum SLB pode segurá-lo, fazendo com que o programa antigo trave novamente quando é apenas assumido;
5. No dia 5 usei essa arquitetura para entrar online. O estoque esgotou em 7 minutos, e a experiência foi extremamente tranquila. O novo programa desenvolvido por alunos saudáveis ​​é muito legal.

Este projeto de arquitetura:

• Vantagens: o CDN sobrecarrega o tráfego de recursos estáticos, o que reduz a largura de banda de saída do SLB, e o efeito do teste de estresse também é muito ideal;
• Desvantagens: requer um nome de domínio independente adicional na página, o que envolve vários domínios. Quando o teste foi aberto no dia 4, descobriu-se que o armazenamento e SMS reservados retornaram distorcidos e foi urgentemente retornado ao programa antigo , ou seja, a arquitetura de segunda geração.

  Diagrama de arquitetura ideal e análise-V4

---

Arquitetura ideal

1. CDN de acesso ao nome de domínio principal;
2. O CDN configura os protocolos Http e Https back-to-source para acessar o monitoramento diferente do SLB para alternar entre os programas novos e antigos.A implementação específica é a correspondência do protocolo back-to-source. Monitores diferentes correspondem a programas diferentes.

Este projeto de arquitetura:

• Vantagens: a aceleração estática reduz a largura de banda SLB, retorno dinâmico à fonte, sem problemas entre domínios, comutação conveniente;
• Desvantagens: ainda precisa ser definido manualmente e é inconveniente implantar ecs por espelhamento. Se houver tempo suficiente, é muito bom poder usar diretamente a arquitetura do contêiner. Uma escala pode ser expandida para dezenas ou centenas de pods e nós também podem ser expandidos automaticamente.

  Resumindo

---

O tempo está apertado e a tarefa é pesada, e encontrei muitos buracos:

1. cota de compra de vcpu;
2. Cota de montagem de back-end SLB;
3. Se o saldo do cliente for insuficiente, os atrasos serão interrompidos;
4. A resolução do provedor de serviços de nome de domínio precisa entrar em contato com o atendimento ao cliente para adicionar;
5. Problemas de domínio cruzado não foram considerados quando a arquitetura CDN foi considerada pela primeira vez;
6. Durante o desenvolvimento do novo programa, a biblioteca principal não foi conectada ao teste, o que causou a falha online (biblioteca principal truncada);
7. Na primeira vez (nº 3) foi suspenso, apenas o tráfego de SLB foi afetado, e os links com mais falhas não foram analisados ​​em detalhes;
8. O teste de pressão está faltando antes de entrar online, dependendo puramente da função de teste manual;
9. O teste de pressão conta com Jmeter (o PTS foi introduzido na noite do dia 4 à manhã do dia 5 para medição da pressão);
10. De repente, lembrei que o programa original do cliente foi colocado no Windows, e o desempenho do programa ruim do Windows + era muito ruim;
11. Este "pequeno projeto" na verdade custou uns pequenos cem mil antes e depois, se fizermos isso para nós desde o início, deve ser capaz de reduzir o custo pela metade.
    As estatísticas do resultado final (análise de amostragem, os dados reais são maiores do que isso): As últimas três gerações das
    
    estatísticas de resultado (análise de amostragem)
    foram online, 150 máquinas foram usadas para fins de seguro, mas com base nas observações durante o evento e nos resultados do teste de pressão Estima-se que 50 máquinas devam ser capazes de resistir. De travar por 5 horas e ser repreendido por usuários finais, ao elogio de líderes que se esgotaram em 7 minutos, mesmo após 3 batalhas noturnas, ainda posso sentir vagamente O corpo e a mente são sublimados.

    Várias notas de otimização

---

Otimização de parâmetros

• Sintonização de rede

net.ipv4.tcp_max_tw_buckets = 5000 --> 50000
net.ipv4.tcp_max_syn_backlog = 1024 --> 4096
net.core.somaxconn = 128 --> 4096
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_timestamps = 1(5和6同时开启可能会导致nat上网环境建联概率失败)
net.ipv4.tcp_tw_recycle = 1

• /etc/security/limits.conf

* soft nofile 65535
* hard nofile 65535

• Otimização de parâmetros Nginx

worker_connections  1024-->10240;
worker_processes  1-->16;（根据实际情况设置，可以设置成auto）
worker_rlimit_nofile 1024-->102400;
listen 80 backlog 511-->65533；

Em alguns cenários, você também pode considerar o nginx para abrir conexões longas para otimizar a sobrecarga causada por links curtos

Otimização da arquitetura

• Expanda o número de ECS de back-end SLB e a configuração do ECS será unificada;
• Remoção de porta inválida do upstream do backend de geração reversa do Nginx;
• Cloud Assistant processa serviços em lote, otimiza parâmetros e adiciona identificadores de instância; (para focar, se você usa ECS em lotes, você pode considerar o uso do Cloud Assistant)
• Monitoramento de nuvem e monitoramento de mercado, ECS, SLB, DCDN, Redis, etc .;
• Ajuste o SLB para o modo de monitoramento de 7 camadas. Fechar a sessão das primeiras 7 e das últimas 4 fará com que o status de login se torne inválido.

  Otimização do programa

  Adicionar log de GC, capturar problemas de análise de GC e definir memória de processo;

/usr/bin/java -server -Xmx8g -verbose:gc -XX:+PrintGCDetails -Xloggc:/var/log/xxxx.gc.log -Dserver.port=xxxx -jar /home/app/we.*****.com/serverboot-0.0.1-SNAPSHOT.jar

• Otimize a lógica de envio de SMS, primeiro consulte a Sessão não registrada do Redis ao fazer o login e, em seguida, permita o envio do código de verificação de SMS sem a Sessão não registrada (reduza a quantidade de mensagens curtas e otimize a experiência de login);
• otimização do pool de conexão jedis;

maxTotal 8-->20
acceptcount优化（对标somaxconn）

• Bug: O vazamento de conexão do Redis do jedis 2.9.1 com springboot 1.5 fez com que o processo do Tomcat 800 esperasse indefinidamente pela conexão do Redis após ser usado. Posteriormente, uma investigação mais aprofundada descobriu que esse problema foi corrigido em 2.10.2 e 2.10.2 é compatível com versões anteriores com 2.9.1.

  Otimização de banco de dados

• O endereço de rede pública Redis é alterado para um endereço de rede interna;
• A configuração de tempo limite da sessão do Redis é reduzida para liberar a conexão do Redis;
• Otimização lenta de SQL (CloudDBA de RDS é muito fácil de usar);
• Adicionar instância somente leitura, separação automática de leitura e gravação;
• Otimize o backlog;
• Adicione o número de instâncias de separação de leitura e gravação.

  Finalmente

---

Guia de operação e manutenção do ECS para diagnóstico do sistema Linux
Este artigo foi extraído do "Guia de operação e manutenção do ECS para diagnóstico do sistema Linux". O "Guia de operação e manutenção do ECS para diagnóstico do sistema Linux" é um trabalho meticuloso de Makihara. Não apenas o conteúdo é refinado, mas o autor do código também passou um tempo menos pensativo. Você também pode fazer login diretamente na Alibaba Cloud Developer Community para baixar o livro- "ECS Operation and Maintenance Guide-Linux System Diagnosis", ou responder diretamente à palavra-chave "ecs" nos bastidores da conta oficial para obter esta coleção.
Existem muitos artigos técnicos de alta qualidade na comunidade de desenvolvedores do Alibaba Cloud. Você pode ir para observar e aprender. Muitos livros estão disponíveis diretamente para download gratuito.

Se você acha que o conteúdo deste artigo é inspirador e gratificante, ajude-me a clicar em "Estou assistindo" ou encaminhe e compartilhe para que mais amigos vejam.