Prefácio
Para resolver os vários problemas trazidos pelo modelo tradicional de desenvolvimento da web, fizemos muitas tentativas, mas devido à lacuna física entre as extremidades dianteiras e traseiras, as soluções que tentamos são semelhantes. Aprendendo com a dor, hoje repensamos a definição de "frente e back-end" e introduzimos o NodeJS, que é familiar para os alunos do front-end, tentando explorar um novo modo de separação front-end.
Com o aumento de diferentes terminais (PAD/Mobile/PC), os desenvolvedores têm requisitos cada vez mais altos. A capacidade de resposta do lado do navegador puro não pode mais atender aos altos requisitos da experiência do usuário. Geralmente, precisamos desenvolver versões personalizadas para diferentes terminais. Para melhorar a eficiência do desenvolvimento, a necessidade de separação das extremidades dianteiras e traseiras é cada vez mais valorizada. O back -end é responsável pelas interfaces de negócios/dados, o front -end é responsável pela lógica de exibição/interação e podemos personalizar e desenvolver várias versões da mesma interface de dados.
Este tópico foi discutido muito recentemente, e alguns ônibus do Alibaba também estão fazendo algumas tentativas. Após uma longa discussão, nossa equipe decidiu explorar um conjunto de esquemas de separação front-end e back-end com base nos NodeJs. Houve alguns entendimentos e pensamentos em mudança no processo. Eu gravei aqui. Espero também que os alunos que vi participaram da discussão e nos ajudem a melhorá -la.
1. O que é a separação front-end?
Durante a discussão inicial dentro do grupo, descobri que todos têm um entendimento diferente da separação front-end. Para garantir que eles possam discutir no mesmo canal, chegaremos a um acordo sobre o que é "separação de front-end".
Um exemplo de separação de front-end que todos concordam com o SPA (Application de uma página única). Todos os dados de apresentação utilizados são fornecidos pelo back-end através da interface assíncrona (AJAX/JSONP), e o front-end apenas o exibe.
Em certo sentido, o SPA atinge a separação do front-end, mas há dois problemas com este método:
Entre os serviços da Web, o SPA é responsável por uma proporção muito pequena. Em muitos cenários, também há um modo híbrido síncrono/síncrono + assíncrono, e o SPA não pode ser usado como uma solução geral.
No modelo atual de desenvolvimento do spa, a interface é geralmente fornecida de acordo com a lógica de apresentação. Às vezes, para melhorar a eficiência, o back -end nos ajuda a lidar com alguma lógica de apresentação, o que significa que o back -end ainda está envolvido no trabalho da camada de visualização, não na separação real dos front e back -ends.
A separação do front-end ao estilo de spa é distinguida da camada física (pense que, desde que seja o cliente, o front-end e o back-end é o servidor). Essa classificação não pode mais atender às nossas necessidades de separação front-end. Acreditamos que somente dividindo responsabilidades podemos atender aos nossos cenários de uso atual:
Front-end: Responsável por camadas de visualização e controlador.
Back -end: Somente responsável pela camada do modelo, processamento de negócios/dados, etc.
Por que essa divisão de responsabilidades será discutida mais adiante.
2. Por que devemos separar as extremidades da frente e de trás?
Em relação a esse problema, o artigo de Yu Bo explica de maneira muito abrangente na evolução do modelo de P&D da Web. Vamos revisá -lo brevemente:
2.1 Cenários aplicáveis para modelos de desenvolvimento existentes
Os modelos de desenvolvimento mencionados por Yu Bo têm seus próprios cenários aplicáveis, e nenhum deles substitui completamente o outro.
Por exemplo, para o MVC, que é baseado principalmente no back -end, é muito eficiente realizar alguns negócios de exibição síncrona, mas ao encontrar uma página síncrona e assíncrona, será mais problemático se comunicar com o desenvolvimento de back -end.
O Ajax é o principal modelo de desenvolvimento de spa, que é mais adequado para o desenvolvimento de cenários do tipo App, mas é adequado apenas para criar aplicativos, porque o SEO e outros problemas são difíceis de resolver. Para muitos tipos de sistemas, esse método de desenvolvimento também é muito pesado.
2.2 As responsabilidades frontal e traseiro não são claras
Em sistemas com lógica de negócios complexos, temos mais medo de manter o código misturado com as extremidades dianteiras e traseiras. Como não há restrição, o código de outras camadas de MVC pode aparecer em cada camada. Com o tempo, não há manutenção.
Embora a separação das extremidades dianteiras e traseiras não possa resolver completamente esse problema, ela pode ser muito aliviada. Porque é garantido de um nível físico que você não pode fazer isso.
2.3 Questões de eficiência de desenvolvimento
A Web de Taobao é basicamente baseada no Webx da MVC Framework, e a arquitetura determina que o front-end só pode confiar no back-end.
Portanto, nosso modelo de desenvolvimento ainda é que o front-end escreve demos estático e o back-end os traduz em modelos de VM. Não vou falar sobre o problema com esse modelo e fui criticado por um longo tempo.
Também é doloroso desenvolver diretamente com base no ambiente de back-end e é problemático configurar, instalar e usar. Para resolver esse problema, inventamos várias ferramentas, como o Vmarket, mas o front-end ainda precisa escrever VMs e confiar nos dados de back-end, para que a eficiência ainda não seja alta.
Além disso, o back -end não pode se livrar do forte foco na exibição e, portanto, se concentrar no desenvolvimento da camada lógica de negócios.
2.4 Limitações no desempenho do front-end
Se a otimização do desempenho for feita apenas no front end, geralmente precisamos de cooperação de back -end para criar faíscas. No entanto, devido às limitações da estrutura de back -end, é difícil para nós usarmos o cometa, o bigpipe e outras soluções técnicas para otimizar o desempenho.
Para resolver alguns dos problemas mencionados acima, fizemos muitas tentativas e desenvolvemos várias ferramentas, mas nunca houve muita melhoria, principalmente porque só podemos usar o pequeno espaço dividido por nós no back -end. Somente separando verdadeiramente as extremidades dianteiras e traseiras, podemos resolver completamente os problemas acima.
3. Como separar as extremidades da frente e de trás?
Como separar as extremidades da frente e da parte traseira? De fato, há uma resposta na primeira seção:
Front-end: Responsável por camadas de visualização e controlador.
Back -end: Responsável pela camada do modelo, processamento de negócios/dados, etc.
Imagine, se o front-end masters o controlador, podemos fazer o design de URL, podemos decidir se sincronizar a renderização no servidor de acordo com a cena ou gerar dados JSON com base nos dados da camada de exibição, e também podemos fazer facilmente bigpipe, cometa, soquete etc. de acordo com as necessidades da camada de apresentação. É inteiramente o método de uso determinado pelos requisitos.
3.1 Desenvolvimento de "pilha completa" com base em nodejs
Se você deseja implementar a camada da figura acima, inevitavelmente precisará de um serviço da web para nos ajudar a perceber o que fazemos antes e depois do back-end, para que haja o título "Desenvolvimento de pilha completa baseada em nodejs"
Essa imagem parece simples e fácil de entender, mas não tentou e haverá muitas perguntas.
No modo SPA, o back -end forneceu a interface de dados necessária e o front -end do View já pode ser controlado. Por que adicionar a camada de nodejs?
Que tal adicionar mais uma camada?
Adicionar mais uma camada aumentará a carga de trabalho do front-end?
Adicionar mais uma camada levará a outra camada de risco. Como quebrá -lo?
Nodejs pode fazer alguma coisa, por que você ainda precisa de java?
Não é fácil explicar esses problemas claramente. Deixe -me falar sobre meu processo de compreensão abaixo.
3.2 Por que adicionar uma camada de nodejs?
Nesta fase, desenvolvemos principalmente o modelo MVC de back -end. Esse modelo dificulta seriamente a eficiência do desenvolvimento do front-end e impede que o back-end se concentre no desenvolvimento de negócios.
A solução é permitir o front-end para controlar a camada do controlador, mas é difícil fazê-lo sob o sistema de tecnologia existente, porque é impossível permitir que todos os front-end-end-Firnds aprendam Java, instalem o ambiente de desenvolvimento de back-end e escreva VMs.
O NodeJS pode resolver esse problema muito bem. Podemos fazer o que o desenvolvimento nos ajudou a fazer antes, e tudo parece tão natural.
3.3 Problemas de desempenho
A camada envolve a comunicação entre cada camada e definitivamente haverá certas perdas de desempenho. No entanto, a estratificação razoável pode tornar as responsabilidades claras e colaborativas, o que melhorará bastante a eficiência do desenvolvimento. As perdas causadas pela estratificação serão definitivamente compensadas em outros aspectos.
Além disso, depois de decidirmos amarrar, podemos minimizar as perdas otimizando os métodos de comunicação e os protocolos de comunicação.
Por exemplo:
Depois que a página de detalhes do bebê do Taobao é estática, ainda há muitas informações que precisam ser obtidas em tempo real, como logística, promoções etc. Como essas informações estão em diferentes sistemas de negócios, o front-end precisa enviar 5 ou 6 solicitações assíncronas para preencher esses conteúdos.
Com o NodeJS, o front-end pode procurar essas 5 solicitações assíncronas no NodeJS e pode facilmente fazer Bigpipe. Essa otimização pode melhorar muito toda a eficiência de renderização.
Você pode pensar que não há problema em enviar 5 ou 6 solicitações assíncronas no PC, mas no lado sem fio, é muito caro estabelecer uma solicitação HTTP no telefone celular do cliente. Com essa otimização, o desempenho é várias vezes melhorado.
Os detalhes do Taobao são baseados na otimização do NodeJS. Estamos em andamento. Após o lançamento, compartilharei o processo de otimização.
3.4 A carga de trabalho do front-end aumentou?
Comparado a apenas cortar páginas/demos, deve ser um pouco mais, mas há ligações e comunicações no modo atual. Esse processo leva muito tempo, é propenso a bugs e é difícil de manter.
Portanto, embora a carga de trabalho aumente um pouco, a eficiência geral do desenvolvimento será bastante aprimorada.
Além disso, os custos de teste podem ser muito salvos. As interfaces desenvolvidas no passado são destinadas à camada de apresentação e é difícil escrever casos de teste. Se a separação frontal e traseira for feita, mesmo o teste poderá ser separado. Um grupo de pessoas é especialista em testar a interface e o outro grupo de pessoas se concentra em testar a interface do usuário (esta parte do trabalho pode até ser substituída pelas ferramentas).
3.5 Como controlar os riscos trazidos adicionando a camada de nós?
Com o uso em larga escala do nó, os alunos do departamento de sistema/operação e manutenção/segurança definitivamente ingressarão na construção da infraestrutura. Eles nos ajudarão a melhorar possíveis problemas em cada link e garantir a estabilidade do departamento.
3.6 Nó pode fazer alguma coisa, por que você ainda precisa de Java?
Nossa intenção original é separar as extremidades dianteiras e traseiras. Se considerarmos esse problema, será um pouco contrário à nossa intenção original. Mesmo se usarmos o Node para substituir o Java, não podemos garantir que não encontraremos nenhum problema que encontramos hoje, como responsabilidades pouco claras. Nosso objetivo é se desenvolver de maneira em camadas, pessoas profissionais e focar em fazer coisas profissionais. A infraestrutura baseada em Java já é muito poderosa e estável e é mais adequada para fazer o que é agora a arquitetura.
4. Separação de front-end baseada em nó de Taobao
A figura acima é o que eu entendo na separação e nas camadas de front-end e back-end do Taobao com base no nó, bem como no escopo das responsabilidades do nó. Uma breve explicação:
A extremidade superior é o servidor, que é o que chamamos de back -end. Para nós, o back -end é uma coleção de interfaces, e o servidor fornece várias interfaces para usarmos. Como existe uma camada de nós, não há necessidade de limitar a forma de serviço que é. Para desenvolvimento de back -end, eles usam apenas interfaces que se preocupam com o código comercial.
O servidor está no aplicativo Node.
Há uma camada de proxy do modelo no aplicativo Node que se comunica com o servidor. Essa camada é usada principalmente para suavizar a maneira como chamamos diferentes interfaces e encapsulamos alguns modelos necessários pela camada de exibição.
A camada de nós também pode atingir facilmente o VMCommon original, o TMS (citando o sistema de gerenciamento de conteúdo do Taobao) e outros requisitos.
Qual estrutura usar para a camada de nós depende do desenvolvedor decidir. No entanto, é recomendável usar uma combinação de Express + XTemplate, que pode ser usado para as extremidades dianteiras e traseiras.
Todo mundo decide como usar o nó, mas o que é emocionante é que finalmente podemos usar o Node para implementar facilmente o método de saída que queremos: JSON/JSONP/RESTful/html/bigpipe/comet/soquete/síncrono e assíncrono. Pode ser feito o que você quiser, e é decidido inteiramente com base no seu cenário.
A camada do navegador não mudou em nossa arquitetura e não queremos alterar seu entendimento anterior do desenvolvimento no navegador devido à introdução do nó.
A introdução do nó é apenas para entregar a parte de controle front-end que deve ser controlada pelo front-end.
Temos dois projetos em desenvolvimento neste modelo. Embora eles ainda não tenham sido lançados, já provamos a doçura em termos de eficiência do desenvolvimento e otimização de desempenho.
5. O que mais precisamos fazer?
Integre o processo de desenvolvimento do Node ao processo SCM existente do Taobao.
Construção de infraestrutura, como sessão, módulo de módulos gerais.
Melhores práticas de desenvolvimento
Histórias de sucesso online
Entendimento de todos sobre o conceito de separação da frente e traseiro do nó
Segurança
desempenho
...
Não haverá muita tecnologia que precise de inovação e pesquisa, e houve muito acúmulo pronto. De fato, a chave é a abertura de alguns processos e o acúmulo de soluções gerais. Acredito que, com mais práticas de projeto, essa área se tornará gradualmente um processo estável.
6. "Midway Island"
Embora o modelo "Desenvolvimento de pilha completa baseada no NodeJS" seja emocionante, ainda há muito para transformar o desenvolvimento da pilha completa com base no nó em algo que todos podem aceitar. Nosso projeto "Midway" em andamento é resolver esse problema. Embora não demoremos muito antes, estamos chegando cada vez mais perto do nosso objetivo! !