Este artigo usa principalmente a experiência de separação front-end e back-end do projeto do shopping vivo, resume as ideias de separação front-end e back-end, organiza os esquemas de separação front-end e back-end e os problemas e soluções encontradas no processo de separação.
I. Introdução
O shopping oficial da Vivo inaugurou um shopping online em 2015 e abriu canais de venda online Nos últimos anos, a atividade diária e as vendas continuaram crescendo, o que impulsionou muito as vendas de celulares vivo.
À medida que a versão de negócios itera cada vez mais rápido, o conteúdo de negócios aumenta gradualmente e as desvantagens do modelo de não separação de front-end e back-end são gradualmente reveladas. A eficiência da iteração não pode acompanhar o aumento gradual das necessidades de negócios e o custo da expansão multi-end é alto.
Para tanto, começamos a atualizar a arquitetura do projeto do shopping em 2019, realizar separação front-end e back-end, atualizações de tecnologia de front-end e padronização de interface para atender a mais desafios de negócios no futuro.
Dois, fundo
A primeira etapa da atualização da arquitetura é a separação de front-end e back-end. Os pontos problemáticos de não separar front-end e back-end não precisam ser repetidos. Isso afeta a eficiência do desenvolvimento e a experiência de desenvolvimento. No entanto, o shopping ainda está em um período de rápido desenvolvimento de negócios e não pode ser causado por reconstrução tecnológica. Pare a iteração da versão comercial.
Portanto, a iteração da versão de negócios deve ser realizada ao mesmo tempo que a separação das extremidades frontal e posterior.Como podemos alcançar o paralelismo de linha dupla e ter ambos? Como desenhar o plano? Como lidar com os riscos e fatores incontroláveis decorrentes da atualização tecnológica?
Vamos fazer essas perguntas para ver como o shopping vivo realiza a separação das pontas frontal e traseira passo a passo.
Três, separação dianteira e traseira
1. Ideias básicas
Primeiro analise nossos módulos de negócios. É uma estrutura de árvore padrão. Cada módulo funcional contém vários submódulos, e cada submódulo pode conter vários submódulos menores. A página de endereço da página correspondente a cada submódulo é semelhante a breadcrumbs, formando A relação de contenção de nível e correspondência um a um com o nível de contenção do módulo de função, conforme mostrado abaixo:
Portanto, se pudermos controlar a solicitação de página de um determinado módulo, deixá-la retornar para a nova página após a separação, e outras solicitações ainda visitarem a página antiga, podemos separar os módulos de função um por um? Bem, é viável em teoria.
Por exemplo, tomando o módulo de pedido como exemplo, podemos interceptar solicitações de páginas relacionadas ao pedido, de modo que as solicitações da página de pedido acessem novos recursos, e outras solicitações de página também acessem recursos antigos, conforme mostrado na figura a seguir:
2. Esquema de separação gradual
Portanto, a questão é: como solicitar recursos diferentes de acordo com o caminho de acesso? As solicitações de página atuais da loja e as solicitações de interface são feitas por meio do Nginx como uma entrada de portal unificada. Podemos distinguir o caminho das solicitações de página por meio do Nginx, de modo a atingir o objetivo de controle de roteamento?
Ao estudar a configuração do Nginx, descobri que a correspondência de rota do Nginx tem esse recurso:
A correspondência de localização primeiro verifica a localização definida com caracteres de prefixo, seleciona o item de correspondência mais longa e o registra, se não houver nenhuma localização regular correspondente e localização de correspondência exata, use a localização de caractere de prefixo mais longa registrada anteriormente.
Esta informação é muito importante. A correspondência de localização do Nginx usará o caminho de correspondência mais longo, porque nossa estrutura hierárquica de caminho de página corresponde à estrutura hierárquica dos módulos funcionais. Quanto mais longo o caminho correspondido por nossa localização, a granularidade dos módulos funcionais correspondentes. Quanto melhor for, mais precisa será a correspondência da página correspondente .
Por exemplo, o centro pessoal (caminho é / meu) contém módulos relacionados ao pedido (caminho é / meu / pedido). De acordo com o princípio de correspondência mais longo do Nginx, o tamanho dos módulos a serem separados pode ser controlado controlando o comprimento do caminho correspondente , como por interceptação / meu / pedido para interceptar todas as páginas relacionadas ao pedido.
location /my/order {
# 匹配所有以/my/order开头的请求,其他请求不会被拦截，如/my/coupon则不会被拦截
# 如订单列表页面 https://shop.vivo.com.cn/my/order/list 会被拦截
# 将匹配到的页面请求转发到新的静态资源服务器
proxy_pass http://new-download;
}Da mesma forma, o caminho da página no módulo de avaliação no centro pessoal começa com / my / comment, então o módulo de avaliação pode ser bloqueado adicionando o local de configuração / my / comment {}. Quando os submódulos sob o centro pessoal são separados, o intervalo de correspondência pode ser expandido encurtando o caminho de correspondência.
location /my {
# 匹配所有以/my开头的请求，即个人中心的所有页面都被拦截
# 如个人中心首页 https://shop.vivo.com.cn/my 会被拦截
# 将匹配到的页面请求转发到新的静态资源服务器
proxy_pass http://new-download;
}Quando todos os módulos são separados passo a passo, o caminho da raiz pode ser interceptado diretamente e todas as solicitações de página podem ser obtidas de novos recursos estáticos.
3. Duas linhas em paralelo
A tecnologia atende aos negócios, e a evolução da tecnologia pode trazer melhorias para os negócios. A versão empresarial está iterando em alta velocidade, como um ônibus espacial lutando para subir. Com a solução acima, você pode substituir peças e até mesmo motores da aeronave em vôo. A reconstrução do módulo é realizada gradualmente enquanto a versão do negócio é iterada. O negócio é iterado gradualmente de acordo com a versão, mas cada iteração geralmente não envolve muitos módulos, mas se concentra em iterar ou modificar um ou dois módulos. Em um determinado momento Quando a versão de negócios envolve um determinado módulo, podemos separar este módulo e desenvolver o conteúdo da versão de negócios ao mesmo tempo que a separação, ou seja, o desenvolvimento da função de negócios é concluído, e a separação e reconstrução do módulo são concluídas. Os alunos do teste só precisam testar Uma vez, iteração de versão aprimorada e eficiência de teste.
Claro, a versão empresarial é geralmente uma iteração de alguns módulos comuns, como commodities, liquidação, carrinhos de compras e outros módulos. Sempre há alguns módulos relativamente estáveis ou incomuns por um longo tempo ou mesmo um ou dois anos sem grandes mudanças. Nesse caso, uma versão separada é necessária para a iteração. Felizmente, esses módulos não são muitos e o negócio é relativamente estável.
4. Garantia de qualidade e aversão ao risco
Em iterações de negócios em geral, apenas alguns códigos de módulo precisam ser modificados, adaptados ou complementados. A reconstrução completa de todo o módulo sem dúvida aumentará a carga de trabalho de desenvolvimento e testes adicionais, e mais mudanças e modificações trarão Existem mais riscos e fatores incontroláveis, então como garantir a qualidade da reconstrução?
Ao mesmo tempo, o planejamento da versão de negócios pode envolver apenas o conteúdo de negócios desta versão, não as funções históricas do módulo. Quais padrões de referência devem ser usados para testar essas funções históricas? Como garantir a cobertura do teste e garantir que todos os cenários de negócios possam ser Está coberto?
Com relação aos padrões de referência, os padrões online são os melhores. Agora, as páginas da Web fornecem métodos de acesso http e https. O conteúdo acessado pelo usuário é o mesmo e a configuração do servidor é basicamente a mesma. Altere a configuração de https para a nova configuração, mas o http permanece inalterado. A página mais recente pode ser acessada na forma de https, enquanto a página antiga é acessada na forma de http. Claro, essas duas páginas podem ser acessadas ao mesmo tempo, para que possamos comparar as páginas antigas e novas para garantir que as páginas sejam consistentes antes e depois da separação. Sexo.
server {
listen 80;
server_name shop.vivo.com.cn;
# 老的配置不变
...
}
server {
listen 443;
server_name shop.vivo.com.cn;
# 分离模块配置
location /my {
proxy_pass http://new-download;
}
}Para garantir a cobertura do teste, introduzimos uma ferramenta de verificação de cobertura de código para detectar com precisão se uma determinada linha de código é coberta por casos de teste. Através do relatório de cobertura de código, podemos ver claramente quais códigos foram executados, quais ramificações não foram executadas e por que não foram executadas. Com base nesses feedbacks, os casos de teste podem ser ajustados e complementados para garantir uma cobertura de teste abrangente.
5. Problemas encontrados
(1) Sequência de implantação online
Existem três partes principais do processo on-line: liberação da interface do lado do servidor, liberação do recurso estático do front-end e modificação do Nginx. Essas três operações dependem da frente e do verso. Se o pedido estiver errado, isso causará acidentes on-line. Portanto, devem ser estritamente seguidas. A seguinte ordem de publicação:
- Liberação da interface do servidor
A interface do servidor é compatível com versões futuras. No processo de separação, a interface antiga não é modificada diretamente, mas a nova interface é aberta para garantir que as interfaces novas e antigas possam ser chamadas durante o período de lançamento.
- Liberação de recursos estáticos de front-end
A página front-end depende da interface do lado do servidor, portanto, você deve garantir que a interface do lado do servidor foi publicada antes de postar a página do front-end, caso contrário, o problema da interface 404 ocorrerá.
- Modificação de configuração Nginx
Esta etapa deve ser finalizada. Se o Nginx for modificado antes que os recursos estáticos de front-end sejam liberados, a página 404 aparecerá quando o usuário visitar a página.
(2) Medidas de tolerância a desastres
Como posso reverter rapidamente quando há um problema com a versão online sem afetar os usuários? Como estamos interceptando diretamente as solicitações do usuário e redirecionando para o novo servidor de recursos estáticos, se houver um problema online, apenas desligue esta parte da configuração de interceptação para atingir o propósito de reversão rápida. A interface do servidor é compatível com versões futuras, portanto, não há necessidade de voltar atrás.
Quarto, o resultado
De acordo com este plano, após um ano de iteração gradual, iteramos 8 versões e, finalmente, concluímos a separação das extremidades frontal e posterior do terminal WAP, permitindo que profissionais façam atividades profissionais. Olhando para trás agora, que problemas resolvemos com essa atualização tecnológica e quais melhorias e efeitos positivos ela nos trouxe?
A velocidade de lançamento do negócio front-end puro aumentou mais de 10 vezes
Libere mão de obra de P&D, profissionais fazem coisas profissionais e a eficiência de desenvolvimento pode ser duplicada
Estabeleça uma boa base para a expansão do canal nativo e multi-end
- Acumule experiência técnica e capacite mais empresas
Cinco, resumo
Todo o processo de separação de front-end e back-end é longo e tortuoso. Nesse processo, o maior problema que enfrentamos é como encontrar um equilíbrio entre os custos de mão de obra, requisitos de negócios e atualizações de tecnologia. Esse é um problema muito desafiador para nós. Em muitos casos, referências e soluções podem ser encontradas para problemas técnicos, mas como podemos formular soluções técnicas sob as circunstâncias de mão de obra, recursos, versões e acúmulo de tecnologia complicados, levar todas as partes em consideração, promover ativamente a solução de problemas e identificar e evitar riscos antecipadamente? Nosso verdadeiro teste.
Autor: equipe de front-end da loja do site oficial da vivo