Upsync: solução de gerenciamento de tráfego dinâmico de código aberto Weibo baseada em contêiner Nginx

Upsync: solução de gerenciamento de tráfego dinâmico de código aberto Weibo baseada em contêiner Nginx

Nota do editor: Compartilhamento e disseminação de arquitetura de alta disponibilidade são artigos de significância típica no campo da arquitetura. Este artigo é compartilhado por Yao Sifang no grupo de arquitetura de alta disponibilidade. Indique que é da conta pública da estrutura de alta disponibilidade "ArchNotes".

Yao Sifang, especialista técnico sênior da Sina Weibo, líder técnico do grupo de arquitetura de plataforma Weibo. Ingressou na Sina Weibo em 2012 e participou de vários projetos importantes, incluindo atualização de arquitetura do Weibo Feed, transformação de serviços de plataforma e nuvem híbrida. Atualmente é o líder técnico do grupo de arquitetura de plataforma Weibo e é responsável pela pesquisa e desenvolvimento da infraestrutura pública da plataforma. Certa vez, ele compartilhou a tecnologia da "Arquitetura de Alto Desempenho Sina Weibo" na QCon, com foco na direção de arquitetura de alto desempenho e middleware de serviço.

Histórico de negócios e problemas usados ​​por Nginx

O Nginx tem sido amplamente utilizado na indústria devido ao seu altíssimo desempenho e estabilidade. O Nginx é amplamente utilizado nas sete camadas do Weibo. Combinado com o módulo de verificação de integridade e mecanismo de recarregamento dinâmico do Nginx, os serviços podem ser atualizados, iniciados e expandidos quase sem danos. Neste momento, a frequência de expansão é relativamente baixa e, na maioria dos casos, é uma expansão planejada.

Os cenários de negócios do Weibo têm características de pico muito significativas. Não há apenas picos noturnos rotineiros, mas também picos de tráfego extremos esperados, como o Dia de Ano Novo, o Festival de Gala da Primavera e o Red Packet Flying. Existem picos ainda mais ocasionais causados ​​por celebridades / eventos sociais como # 日见 # # 我们 #. A prática usual antes é buffer + downgrade. Quando o downgrade não é considerado (o que afetará a experiência do usuário), o buffer é muito pequeno para suportar o valor de pico e o custo não pode ser suportado. Portanto, desde 2014, temos tentado usar a conteinerização para realizar o ajuste dinâmico do buffer, de modo a realizar a expansão / redução do buffer de acordo com a taxa de fluxo para economizar custos.

Nesse cenário, haverá um grande número de operações contínuas de expansão / redução. Existem duas soluções comuns para mudanças de back-end baseadas em Nginx no setor. Um é baseado em DNS fornecido pela Tengine, e o outro é a descoberta de serviço de back-end com base no modelo de consul. A tabela a seguir compara resumidamente as características das duas soluções.

Baseado em DNS: Este módulo é desenvolvido pela equipe Tengine e pode resolver nomes de domínio dinamicamente sob a configuração upstream. Este método é simples de operar, basta modificar a lista de servidores montados sob dns.

Desvantagens:

• O DNS faz pesquisas e resolve regularmente (30s). Se o tempo configurado for muito curto, como 1s, isso pressionará o servidor DNS. Se o tempo configurado for muito longo, a pontualidade será afetada.
• Muitos servidores não podem ser vinculados a serviços baseados em DNS, o que causará truncamento (protocolo UDP) e pressão na largura de banda.

Com base no modelo cônsul e cônsul: Como uma combinação, cônsul é usado como banco de dados, modelo cônsul é implantado no servidor Nginx, modelo cônsul inicia periodicamente uma solicitação ao cônsul e quando o valor muda, ele atualiza os arquivos de configuração relacionados ao Nginx local e inicia comando reload. Mas, no caso de tráfego intenso, iniciar uma recarga afetará o desempenho. A recarga também acionará a criação de um novo processo de trabalho. Em um período de tempo, os processos de trabalho antigo e novo existirão ao mesmo tempo, e o processo de trabalho antigo irá frequentemente percorrer a lista de conexão para ver se a solicitação foi processada. Se terminar, saia do processo; outra recarga Isso também fará com que o longo link entre o Nginx e o cliente e o back-end seja fechado, e o novo processo de trabalho precisa criar um novo link.

Impacto no desempenho causado pelo recarregamento:

Durante a recarga, a capacidade de processamento de solicitações do Nginx diminuirá (Observação: o Nginx não perderá a solicitação de handshake bem-sucedido)

A recarga demorada irá flutuar, e a faixa de flutuação pode até chegar a 50% + (negócios diferentes demoram, a faixa de flutuação será diferente)

O impacto de cada recarga no QPS e demorado do Nginx geralmente dura de 8 a 10 segundos. Considerando que haverá mudanças frequentes em uma expansão, isso é um fardo insuportável para os negócios online. Portanto, evite recarregar o Nginx.

Projeto de esquema baseado em roteamento dinâmico

No projeto do Nginx, cada upstream mantém uma tabela de roteamento estático que armazena o ip, porta e outras meta informações do backend. Após a chegada de cada solicitação, a tabela de roteamento é recuperada de acordo com a localização e, em seguida, uma solicitação de encaminhamento de back-end é selecionada de acordo com um algoritmo de agendamento específico (como round robin). No entanto, esta tabela de roteamento é estática. Se for alterada, deve ser recarregada. Pela figura acima, pode-se verificar que o SLA é bastante afetado.

A ideia mais intuitiva é atualizar / criar dinamicamente uma tabela de roteamento após cada atualização e backend para evitar o reaload. Use o Nginx para estender um módulo [nginx-upsync-module] ( https://github.com/weibocom/nginx-upsync-module ) para atualizar e manter dinamicamente a tabela de roteamento. Geralmente, há duas maneiras de manter a tabela de roteamento: push e pull.

esquema de push

Nesta solução, o Nginx fornece a interface api http. Ao adicionar / excluir servidores por meio da api, uma solicitação é feita ao Nginx chamando a api, o que é simples e conveniente.

O diagrama da arquitetura é o seguinte:

A api http é simples e conveniente de operar e tem bom desempenho em tempo real; a desvantagem é que, quando há vários Nginx, a consistência de diferentes tabelas de roteamento Nginx é difícil de garantir. Se um registro falhar, isso causará uma configuração de serviço inconsistente e tolerância a falhas complexa. Além disso, para expandir o servidor Nginx, você precisa sincronizar a tabela de roteamento de outro Nginx.

puxar plano

Considerando o problema de consistência na dimensão da tabela de roteamento no esquema push, o cônsul de terceiros é apresentado para resolver este problema.

O diagrama da arquitetura é o seguinte:

Todas as informações de back-end (incluindo meta) na tabela de roteamento são armazenadas no cônsul, todo o Nginx extrai informações relevantes do cônsul e, se houver uma mudança, a tabela de roteamento é atualizada, o cônsul é usado para resolver o problema de consistência e o mecanismo de espera do cônsul é usado para resolver problemas em tempo real. Use o índice do cônsul (número da versão) para extração incremental para resolver o problema de ocupação de largura de banda.

No cônsul, um par k / v representa uma mensagem de backend. Adicionar um é considerado expansão e reduzir um é considerado como encolher. O ajuste de metainformações, como pesos, também pode atingir o objetivo de ajuste dinâmico de tráfego.

A implementação a seguir é introduzida com base no cônsul.

Realização de esquema com base em roteamento dinâmico

Com base no método upsync, foi desenvolvido o módulo nginx-upsync-module, que tem como função extrair a lista de servidores back-end do cônsul e atualizar as informações de roteamento do Nginx. Este módulo não depende de nenhum módulo de terceiros.

Método de atualização da tabela de roteamento

Como o banco de dados do Nginx, o cônsul utiliza o serviço KV do cônsul, e cada processo de trabalho do Nginx puxa de forma independente a configuração de cada upstream e atualiza sua própria rota.

O fluxograma é o seguinte:

Cada processo de trabalho vai regularmente para o cônsul para puxar a configuração upstream correspondente, e o intervalo de tempo pode ser configurado; o cônsul fornece um mecanismo time_wait, usando o número da versão do valor, se o cônsul achar que o valor do upstream correspondente não mudou, ele irá suspender a solicitação 5 minutos (padrão). Qualquer operação neste upstream dentro desses cinco minutos retornará imediatamente ao Nginx para atualizar a rota correspondente. O intervalo de pull pode ser configurado de acordo com as necessidades da cena e o desempenho em tempo real necessário pode ser basicamente alcançado. Após a mudança upstream, além de atualizar as informações de roteamento do cache do Nginx, a lista de servidores backend upstream também será despejada localmente para manter as informações do servidor local consistentes com o consul.

Além de registrar / cancelar o registro do servidor back-end no consul, as informações de roteamento upstream do Nginx serão atualizadas e a modificação dos atributos do servidor back-end também será sincronizada com o roteamento upstream do nginx. Atualmente, os atributos modificados suportados por este módulo são weight, max_fails, fail_timeout, down. Modificar o peso do servidor pode ajustar dinamicamente o tráfego de back-end. Se você deseja remover temporariamente o servidor, pode definir o atributo down do servidor para 1 (o atributo down atual O despejo para a lista de servidores locais não é suportado temporariamente), o tráfego irá parar de atingir o servidor. Se você quiser restaurar o tráfego, pode redefinir o para 0.

Além disso, cada processo de trabalho puxa e atualiza sua própria tabela de roteamento. As razões para esse método são: primeiro, o modelo de processo baseado em Nginx, independente dos dados uns dos outros, sem interferir um no outro; em segundo lugar, se for usada memória compartilhada, ela precisa ser pré-alocada com antecedência , A flexibilidade pode ser limitada e bloqueios de leitura e gravação podem ser necessários, o que pode ter um impacto potencial no desempenho; em terceiro lugar, se a memória compartilhada for usada, a coordenação entre processos para a configuração de pull aumentará sua complexidade e estabilidade de pull. Será afetado. Por essas razões, eles adotaram seus próprios métodos de puxar.

Alta disponibilidade

A atualização da lista de back-end do Nginx depende do cônsul, mas não depende fortemente dele. O desempenho é o seguinte: primeiro, mesmo se o cônsul acidentalmente travar no meio, isso não afetará o serviço do Nginx. O Nginx continuará a fornecer serviços usando a lista de serviços mais recente; Em segundo lugar, se o cônsul reiniciar a fornecer serviços, o Nginx continuará a detectar o cônsul neste momento. No momento, a lista de serviços de back-end do cônsul mudou e será atualizada para o Nginx a tempo.

Por outro lado, o processo de trabalho despeja a lista de back-end localmente sempre que ela é atualizada, com o objetivo de reduzir a dependência do cônsul, pois o Nginx pode ser recarregado mesmo quando o cônsul não está disponível. O fluxograma de inicialização do Nginx é o seguinte:

Quando o Nginx é iniciado, o processo mestre primeiro analisa o arquivo de configuração local, conclui a análise e, em seguida, executa uma série de inicializações e, em seguida, inicia a inicialização do processo de trabalho. Quando o trabalho for inicializado, ele irá para o consul para puxar a configuração e atualizar as informações de roteamento upstream do processo de trabalho. Se o pull for bem-sucedido, ele será atualizado diretamente. Se o pull falhar, o arquivo da lista de back-end de dump configurada será aberto e o dump anterior será extraído Informações do servidor, atualize o roteamento upstream e comece a fornecer serviços normalmente.

Cada vez que você puxar o consul, o tempo limite de conexão será definido. Como o consul ficará pendurado por cinco minutos por padrão sem atualizações, o tempo de configuração do tempo limite de resposta deve ser maior que cinco minutos. Depois de mais de cinco minutos, o cônsul ainda não voltou, então o tempo limite será atingido.

compatibilidade

De um modo geral, este módulo apenas atualiza as informações de roteamento upstream do back-end, não incorpora outros módulos e não afeta as funções de outros módulos, nem afeta os diversos algoritmos de balanceamento de carga do Nginx-1.9.9: least_conn, hash_ip, etc.

Além disso, o módulo suporta naturalmente o módulo de monitoramento de saúde. Se o módulo de monitoramento for incluído quando o Nginx for compilado, a interface do módulo de monitoramento de saúde será chamada ao mesmo tempo e a tabela de roteamento do módulo de monitoramento de saúde será atualizada de tempos em tempos.

Teste de performance

O módulo nginx-upsync-module potencialmente traz sobrecarga de desempenho adicional, como o envio de solicitações ao cônsul em intervalos.Como o intervalo é relativamente longo e cada solicitação é equivalente a uma solicitação do cliente do Nginx, o impacto é limitado. Com base nisso, no mesmo ambiente de hardware, foi feita uma comparação simples de desempenho entre usar este módulo e não usar este módulo.

O ambiente básico Ambiente de
hardware: Intel (R) Xeon (R ) CPU E5645 @ 2,40 GHz
ambientes de sistema de 12 núcleos : centos6.5;
Número do processo de trabalho: 8;
ferramentas de medição de pressão: wrk;
comando de teste de pressão: ./ wrk -t8 - c100 -d5m --timeout 3s http: // $ ip: 8888 / proxy_test

Dados do teste de pressão:

Entre eles, o Nginx (oficial) é o Nginx oficial, e os dados de teste em reload não são executados. Nginx (upsync) é baseado no módulo upsync, registrando / desregistrando os dados de uma máquina com o cônsul a cada 10s; a partir dos dados, pode-se ver que o módulo upsync tem um impacto limitado no desempenho e pode ser ignorado.

Formulários

O módulo tem sido usado em vários negócios da Weibo. O gráfico a seguir compara e analisa o QPS e as mudanças demoradas antes e depois de usar o módulo.

A partir dos dados, pode-se concluir que a capacidade de processamento de solicitações do nginx é reduzida em cerca de 10% durante a operação de recarga, e o consumo de tempo do próprio Nginx aumentará em 50% +. Se for expansão e contração frequentes, a sobrecarga causada pela operação de recarga será mais óbvia.

Durante o Reveillon de 2016, de acordo com as características do tráfego dos diferentes períodos, foram realizadas centenas de expansões / reduções, não sendo afetado o SLA do serviço global durante o processo de expansão.

A versão comercial oficial oferece suporte a DNS e versões push do Nginx plus.
No processo de uso, devido à consistência dos dados e outros problemas, suporte estendido para a versão pull com base no consul

https://github.com/weibocom/nginx-upsync-module está atualmente melhorando o wiki e a documentação. Clique para ler o texto original para entrar.

Perguntas e Respostas

1. O registro das informações de configuração da máquina no consul é ajustado automaticamente pelo sistema Weibo de acordo com o tráfego?
Esses são dois problemas: O processo de registro das informações de backend com os nós durante a expansão é automático e foi integrado ao sistema online. Além disso, o Weibo está atualmente desenvolvendo e avaliando um sistema de avaliação de capacidade online, que atualmente lida com ajustes semiautomáticos.

2. Por que você não considerou zk no início? Seria diferente se você mudasse para zk em vez de puxar em rotação e mudar para link longo?
Atualmente, o módulo tem adicionado suporte semelhante ao etcd e zk. No início, o cônsul era usado porque a empresa já tinha grupos de cônsules e pessoal de operação e manutenção. zk, etcd, consul são essencialmente os mesmos para módulos

3. Por que não puxar o master do Nginx e depois distribuí-lo para cada trabalho, mas usar o processo de trabalho para puxar? O primeiro pode reduzir a interação com a rede e melhorar a consistência de vários trabalhos no Nginx.
Se você usar o mestre para extrair, será necessário modificar o módulo principal. Ao projetar o módulo, um grande princípio é tentar garantir que o módulo tenha 0 dependências. Em geral, isso também é uma troca.

4. O registro das informações de configuração da máquina no consul é ajustado automaticamente pelo sistema Weibo de acordo com o tráfego?
Esta questão é semelhante à questão 1.

5. Com base em quais considerações você escolheu o cônsul para gerenciamento de configuração?
Semelhante à pergunta 2.

6. Você pode projetar um conjunto de APIs e obter Nginx? Não importa se a fonte é cônsul ou um determinado serviço Java. Acho que
as idéias de design de módulos mais gerais são semelhantes aos mencionados acima. Um tipo upsync é projetado internamente e diferentes fontes são usadas. Diferentes tipos podem ser implementados.

7. Além disso, não sei se resolvemos o problema de muitas informações de roteamento do Nginx, que ocupam muita memória. Agora estamos usando o LRU para eliminá-lo. Não sei se existe tal cenário
no Weibo que foi considerado no design. Normalmente, mantemos apenas a tabela de roteamento atual e uma tabela de roteamento expirada. Depois que todas as solicitações suportadas pela tabela de roteamento expirada forem processadas, esta parte da memória será liberada.

8. Para que são utilizadas as máquinas não utilizadas do Weibo quando o tráfego é baixo? Se este lote de máquinas ainda está sendo usado por outros serviços, quando o Weibo carrega dinamicamente esses lotes de máquinas, que tal outros serviços.Atualmente
estamos implantando nuvem híbrida e o pool de buffer é criado na nuvem pública. Quando o tráfego estiver baixo, basta excluí-lo. As máquinas da sala de máquinas geralmente podem executar alguns serviços offline quando o tráfego está baixo. A estratégia de misturar a execução online e offline está atualmente em desenvolvimento.

9. Os resultados reais dos testes de ab e trabalho mostram que as atualizações frequentes da lista de cônsules sob alta pressão falharão. Como você lida com este problema?
Testamos milhares de máquinas a cada segundo e não haverá problemas. Isso tem sido capaz de suportar a maioria (incluindo os predadores) da demanda de expansão. Quando estávamos enfatizando cônsul, havia de fato uma condição falhada de cônsul (single-host prestando serviços), que não estava relacionada ao módulo em si. O desempenho e a configuração do cluster cônsul precisam ser melhorados.

10. Pergunte ao professor. Quero ter um entendimento simples sobre cônsul. Cônsul as informações de roteamento estão armazenadas na memória? Como distinguir as informações de roteamento de diferentes serviços? Só pode ser nomeado por chaves ou cônsul é implantado separadamente para cada serviço?
As informações da tabela de roteamento serão armazenadas em 3 locais. 1. A memória do Nginx melhora diretamente os serviços de roteamento; 2. Armazenado no consul, o armazenamento de cada nó é uma chave de back-end de / $ consul_path / $ upstream / ip: port. 3. Os arquivos no servidor onde o Nginx está localizado são armazenados como instantâneos para evitar que o consulg e o Nginx sejam desativados ao mesmo tempo.

Clique para ler o texto original para acessar o endereço de código aberto do módulo nginx-upsync-module no github.

• Alguns artigos compartilhados pela equipe técnica do Weibo na arquitetura de alta disponibilidade
• Uma estrutura RPC leve que suporta centenas de bilhões de chamadas no Weibo: Motan
• Projeto e prática de plataforma de nuvem híbrida baseada em Weibo Docker
• Discussão sobre a experiência de implantação do Weibo "várias vidas em lugares diferentes"
• Combate de migração de nuvem híbrida baseado em contêiner Docker do Weibo
• Otimização do MySQL e operação e manutenção de 6 bilhões de registros em uma única tabela
• Métodos de solução de problemas para Weibo em sistemas de grande escala e alta carga

Pós-escrito: Ouvi ontem que o colega Sifang saiu do escritório do chefe com o rosto preto e foi fortemente criticado pelo chefe por não ter recrutado ninguém após o Festival da Primavera. Acontece que o Festival das Lanternas acabou, e o ano novo começou oficialmente, então o editor recomenda aos amigos interessados ​​no upsync, Motan, Docker e nuvem híbrida acima mencionados, otimização e operação e manutenção de MySQL com uma única tabela de 6 bilhões de registros podem prestar atenção ao seguinte recrutamento Informação, impiedosamente esmagou o currículo de Sifang para ajudá-lo.

A equipe técnica do Weibo recruta vários talentos técnicos, incluindo C / C ++, Java, big data, operação e manutenção e outras posições técnicas. Os engenheiros estão todos equipados com MacBook Pro e monitores DELL de tela grande e possuem uma riqueza de segredos de desenvolvimento e documentos de treinamento. Valor técnico, a melhor escolha para aumentar a capacidade pessoal. Bem-vindo ao escanear o código QR para detalhes do trabalho.

Este artigo foi planejado por Li Qingfeng, editor Wang Jie e revisor Tim Yang. Se você quiser discutir RPC e arquitetura de microsserviço, siga o relato oficial para oportunidades de ingressar no grupo. Por favor, indique que é da conta oficial WeChat de estrutura de alta disponibilidade "ArchNotes" e inclua o seguinte código QR.