vivo 商城前端架构升级—前后端分离篇

本文主要以 vivo 商城项目的前后端分离经验，总结前后端分离思路，整理前后端分离方案，以及分离过程中遇到的问题及解决方案。

一、前言

vivo官方商城在2015年创建网上商城，开辟网络销售渠道，几年来日活和销售额持续增长，极大的助力了vivo手机的销量。

而随着业务版本迭代越来越快，业务内容逐渐增多，前后端不分离模式的弊端也逐渐显露出来，迭代效率无法跟上逐步增长的业务需求，多端扩展成本高。

为此，我们在2019年开始进行商城项目的架构升级，进行前后端分离，前端技术升级，接口规范化，以便应对未来更多的业务挑战。

二、背景

架构升级，第一步面临的问题便是前后端分离，前后端不分离的痛点已经无需赘述，既影响开发效率，又影响开发体验，但商城仍然处于业务高速发展时期，不能因为技术重构而停下业务版本的迭代。

因此业务版本迭代必须要和前后端分离同时进行，那怎么才能做到双线并行，鱼和熊掌兼得呢？方案要如何设计？如何应对技术升级带来的风险和不可控因素呢？

让我们带着这些问题来看看vivo商城是如何一步步实现前后端分离。

三、前后端分离

1、基本思路

先分析我们的业务模块，是标准的树形结构，每个功能模块包含若干子模块，每个子模块又可以包含若干更小的子模块，每个子模块对应的页面地址页类似于面包屑，形成层级包含关系，并且与功能模块的包含层级一个一个地对应，如下图：

那如果我们能控制某个模块的页面请求，让它返回分离之后的新页面，别的请求还访问老页面，岂不是就能逐个功能模块进行分离？嗯，理论上是可行的。

比如以订单模块为例，我们可以拦截订单相关页面的请求，使得订单页面的请求访问新的资源，其他页面请求还访问老的资源，如下图：

2、逐步分离方案

那么问题来了，如何实现按访问路径去请求不同资源？商城目前的页面请求和接口请求都是通过 Nginx来做统一的门户入口，我们能否通过Nginx区分页面请求路径，从而达到路由控制的目的？

通过学习研究Nginx配置，发现 Nginx路由匹配有这样一条特性：

location 匹配首先检查使用前缀字符定义的 location，选择最长匹配的项并记录下来，如果没有匹配的正则 location 和精确匹配的 location，则使用前面记录的最长匹配前缀字符 location。

这条信息非常重要，Nginx 的 location 匹配会采用最长的匹配路径，因为我们的页面路径层级结构跟功能模块的层级结构是对应的，那我们 location匹配的路径越长，匹配的功能模块的粒度就越细，匹配的相应页面就越精确。

比如个人中心（路径为/my）下包含订单相关模块（路径为/my/order）,根据Nginx最长匹配原则，就可以通过控制匹配路径长度，来控制要分离的模块的大小，比如通过拦截/my/order来拦截所有的订单相关页面。

location /my/order {
  # 匹配所有以/my/order开头的请求,其他请求不会被拦截，如/my/coupon则不会被拦截
  # 如订单列表页面 https://shop.vivo.com.cn/my/order/list 会被拦截
  # 将匹配到的页面请求转发到新的静态资源服务器
  proxy_pass http://new-download;
}

这篇好文章是转载于：学新通技术网