A estrutura tradicional da pilha de software dos aplicativos on -line do Taobao é Nginx + Velocity + Java, ou seja,:
Neste sistema, o NGINX encaminha a solicitação para um aplicativo Java, que lida com a transação e renderiza os dados na página final usando um modelo de velocidade.
Depois de introduzir o Node.js, inevitavelmente enfrentaremos os seguintes problemas:
Como projetar a estrutura de topologia da pilha de tecnologia e como escolher o método de implantação, é considerado científico e razoável? Após a conclusão do projeto, como dividir o tráfego, que é conveniente e rápido para operação e manutenção? Ao encontrar problemas on -line, como eliminar o perigo o mais rápido possível e evitar maiores perdas? Como garantir a saúde do aplicativo e gerenciá -lo no nível de agendamento de balanceamento de carga? Topologia do sistema
De acordo com nosso pensamento e prática na separação das extremidades dianteiras e traseiras (II) - com base na exploração do modelo das extremidades dianteiras e traseiras, a velocidade precisa ser substituída pelo Node.js, para que essa estrutura se torne:
É claro que esse é o objetivo ideal. No entanto, a primeira introdução da camada Node.js na pilha tradicional é uma nova tentativa, afinal. Para estar seguro, decidimos ativar apenas novas tecnologias na página Favoritos (shoucang.taobao.com/item_collect.htm) de nossos favoritos, enquanto outras páginas continuam usando soluções tradicionais. Ou seja, o nginx determina o tipo de página da solicitação e determina se a solicitação deve ser encaminhada para Node.js ou Java. Então, a estrutura final se tornou:
Plano de implantação
A estrutura acima parece estar bem, mas na verdade o novo problema ainda está esperando a frente. Na estrutura tradicional, Nginx e Java são implantados no mesmo servidor. O Nginx ouve a porta 80 e se comunica com o Java ouvindo a porta 7001 no alto. Agora que o Node.js é introduzido, é necessário um novo processo que precisa executar uma porta de escuta. O Node.js deve ser implantado na mesma máquina com nginx + java, ou node.js ser implantado em um cluster separado?
Vamos comparar as características dos dois métodos:
Os favoritos do Taobao são uma aplicação com um PV médio diário de dezenas de milhões, que possui requisitos extremamente altos para a estabilidade (de fato, a instabilidade on -line de qualquer produto é inaceitável). Se você adotar a mesma solução de implantação de cluster, precisará distribuir arquivos uma vez e reiniciar duas vezes para concluir a versão. Caso você precise reverter, você só precisa operar o pacote de linha de base uma vez. Em termos de desempenho, a mesma implantação de cluster também possui algumas vantagens teóricas (embora a largura de banda e a latência da intranet seja muito otimista). Quanto ao relacionamento um para muitos ou muitos para um, pode teoricamente ser mais totalmente utilizado pelo servidor, mas em comparação com os requisitos de estabilidade, esse ponto não é tão urgente para resolver. Portanto, na transformação dos favoritos, escolhemos a mesma solução de implantação de cluster.
Escala de cinza
Para garantir a máxima estabilidade, essa transformação não removeu diretamente o código de velocidade completamente. Existem quase 100 servidores no cluster de aplicativos. Usamos o servidor como granularidade e introduzimos gradualmente o tráfego. Em outras palavras, embora os processos java + node.js estejam em execução em todos os servidores, se existem regras de encaminhamento correspondentes no Nginx determina se a solicitação para obter a coleção de bebês neste servidor será processada através do Node.js. A configuração do nginx é:
Location = "/item_collect.htm" {proxy_pass http://127.0.0.1:6001; # Node.js Process Withing Port}Somente servidores que adicionaram essa regra nginx permitirão que o Node.js lide com a solicitação correspondente. Através da configuração do NGINX, é muito conveniente e rápido aumentar e diminuir o tráfego em escala de cinza, e o custo é muito baixo. Se você encontrar problemas, poderá reverter diretamente a configuração do NGINX e retornar instantaneamente à estrutura tradicional da pilha de tecnologia para aliviar o perigo.
Quando lançamos pela primeira vez, ativamos apenas essa regra em dois servidores, o que significa que menos de 2% do tráfego on -line é processado no Node.js, e as solicitações para o tráfego restante ainda são renderizadas por velocidade. No futuro, o tráfego aumentará gradualmente dependendo da situação e, finalmente, na terceira semana, todos os servidores serão ativados. Nesse ponto, as páginas de coleta de produtos com 100% de tráfego no ambiente de produção são renderizadas pelo Node.js (você pode verificar o código -fonte para pesquisar a palavra -chave node.js).
mudar
O processo em escala de cinza não é suave. Antes de cortar o fluxo na íntegra, encontrei alguns problemas, grandes ou pequenos. A maior parte do negócio está relacionada a negócios específicos, e o que vale a pena aprender é uma armadilha relacionada a detalhes técnicos.
Verificação de saúde
Na arquitetura tradicional, o sistema de agendamento de balanceamento de carga iniciará uma solicitação get a cada segundo a um URL específico na porta 80 de cada servidor e determinará se o servidor está funcionando normalmente com base no fato de o código de status HTTP retornado é 200 . Se o tempo limite após o 1S for solicitado ou o código de status HTTP não for 200 , nenhum tráfego será introduzido no servidor para evitar problemas on -line.
O caminho para essa solicitação é nginx -> java -> nginx, o que significa que, desde que 200 sejam retornados, o Nginx e o Java deste servidor estão em um estado saudável. Depois de introduzir o Node.js, esse caminho se torna nginx -> node.js -> java -> node.js -> nginx. O código correspondente é:
var http = requer ('http'); App.get ('/status.taobao', function (req, res) {http.get ({host: '127.1', porta: 7001, caminho: '/status.taobao'}, function (res) {res.Send (res.statuscode);}). });No entanto, durante o processo de teste, verificou -se que, quando o Node.js encaminhe essas solicitações, levou vários segundos ou até dez segundos para obter o retorno do lado do Java a cada seis ou sete vezes. Isso fará com que o sistema de agendamento de balanceamento de carga pense que ocorreu uma anormalidade no servidor e depois corta o tráfego, mas, de fato, o servidor pode funcionar normalmente. Este é obviamente um grande problema.
Após uma pesquisa, descobri que, por padrão, o Node.js usará a classe HTTP Agent para criar conexões HTTP. Esta classe implementa um pool de conexão de soquete. O limite superior padrão do número de conexões para cada par de portas host + é 5. Ao mesmo tempo, as solicitações iniciadas pela classe de HTTP Agent incluem Connection: Keep-Alive por padrão, resultando na conexão retornada não sendo liberada no tempo, e as solicitações iniciadas posteriormente só podem ser na fila.
Existem três soluções finais:
Desative HTTP Agent , ou seja, adicione agent: false ao chamar o método get , e o código final é:
var http = requer ('http'); App.get ('/status.taobao', function (req, res) {http.get ({host: '127.1', porta: 7001, agente: false, path: '/status.taobao'}, function (res) {res.send (res.Stusc) (). res.send (404); Defina o limite superior do número de soquete global de objetos http :
http.globalagent.maxsockets = 1000;
Quando a solicitação retorna, ela está desconectada oportuna e proativamente:
http.get (opções, function (res) {}). on ("soquete", function (soquete) {socket.emit ("agentremove"); // Ouça eventos de soquete e despacho de eventos do agente no callback});Na prática, escolhemos o primeiro método. Após esse ajuste, nenhum outro problema foi encontrado no exame de saúde.
combinar
A prática de combinar o Node.js com os cenários de negócios tradicionais acaba de começar, e ainda há muitos pontos de otimização que vale a pena explorar em profundidade. Por exemplo, depois que os aplicativos Java estão completamente centralizados, você pode fazer o teste de implantação de cluster para melhorar a utilização do servidor? Ou os métodos de liberação e reversão podem ser mais flexíveis e controláveis? Todos os detalhes valem mais pesquisas.