This article mainly uses the front-end and back-end separation experience of the vivo mall project to summarize the front-end and back-end separation ideas, sort out the front-end and back-end separation schemes, and the problems and solutions encountered in the separation process.
I. Introduction
The Vivo official mall established an online mall in 2015 and opened up online sales channels. Over the past few years, daily activity and sales have continued to grow, which has greatly boosted the sales of vivo mobile phones.
As the business version is iterated faster and faster, business content is gradually increasing, and the drawbacks of the front-end and back-end non-separation model are gradually revealed. The iteration efficiency cannot keep up with the gradual increase in business needs, and the cost of multi-end expansion is high.
To this end, we began to upgrade the architecture of the mall project in 2019, carry out front-end and back-end separation, front-end technology upgrades, and interface standardization to meet more business challenges in the future.
Two, background
The first step of architecture upgrade is the separation of front and back ends. The pain points of not separating front and back ends need not be repeated. It affects development efficiency and development experience. However, the mall is still in a period of rapid business development and cannot be caused by technological reconstruction. Stop the iteration of the business version.
Therefore, the business version iteration must be carried out at the same time as the separation of the front and back ends. How can we achieve dual-line parallelism and have both fish and bear paws? How to design the plan? How to deal with the risks and uncontrollable factors brought about by technological upgrading?
Let's take these questions to see how the vivo mall realizes the separation of front and back ends step by step.
Three, front and rear separation
1. Basic ideas
First analyze our business modules. It is a standard tree structure. Each functional module contains several sub-modules, and each sub-module can contain several smaller sub-modules. The page address page corresponding to each sub-module is similar to breadcrumbs, forming The level containment relationship, and one-to-one correspondence with the containment level of the function module, as shown below:
So if we can control the page request of a certain module, let it return to the new page after separation, and other requests still visit the old page, wouldn't it be possible to separate the functional modules one by one? Well, it is feasible in theory.
For example, taking the order module as an example, we can intercept requests for order-related pages, so that requests for order pages access new resources, and requests for other pages also access old resources, as shown below:
2. Gradual separation scheme
So the question is, how to request different resources according to the access path? The mall’s current page requests and interface requests are made through Nginx as a unified portal entry. Can we distinguish the path of page requests through Nginx to achieve the purpose of routing control?
Through studying the Nginx configuration, I found that Nginx route matching has such a feature:
Location matching first checks the location defined with prefix characters, selects the longest matching item and records it, if there is no matching regular location and exact matching location, use the longest matching prefix character location recorded previously.
This information is very important. Nginx's location matching will use the longest matching path, because our page path hierarchical structure corresponds to the hierarchical structure of functional modules. The longer the path matched by our location, the granularity of the matched functional modules. The finer it is, the more accurate the corresponding page will be matched .
For example, the personal center (path is /my) contains order-related modules (path is /my/order). According to the Nginx longest matching principle, the size of the modules to be separated can be controlled by controlling the length of the matching path , such as by intercepting /my/order to intercept all order related pages.
location /my/order {
# 匹配所有以/my/order开头的请求,其他请求不会被拦截，如/my/coupon则不会被拦截
# 如订单列表页面 https://shop.vivo.com.cn/my/order/list 会被拦截
# 将匹配到的页面请求转发到新的静态资源服务器
proxy_pass http://new-download;
}In the same way, the page path under the evaluation module under the personal center all starts with /my/remark, then the evaluation module can be blocked by adding the configuration location /my/remark {}. When the sub-modules under the personal center are separated, the matching range can be expanded by shortening the matching path.
location /my {
# 匹配所有以/my开头的请求，即个人中心的所有页面都被拦截
# 如个人中心首页 https://shop.vivo.com.cn/my 会被拦截
# 将匹配到的页面请求转发到新的静态资源服务器
proxy_pass http://new-download;
}When all modules are separated step by step, the root path can be directly intercepted, and all page requests can be taken from new static resources.
3. Two lines in parallel
Technology serves the business, and the evolution of technology can bring improvements to the business. The business version is iterating at a high speed, just like a space shuttle struggling to climb. With the above solution, you can replace parts and even engines for the aircraft in flight. Module reconstruction is carried out gradually while the business version is iterated. The business is iterated gradually according to the version, but each iteration generally does not involve too many modules, but focuses on iterating or modifying one or two modules. When a certain time When the business version involves a certain module, we can separate the module and develop the business version content at the same time as the separation. That is, the business function development is completed, and the module separation and reconstruction are completed. The test students only need to test Once, improved version iteration and test efficiency.
Of course, the business version is generally an iteration of some common modules, such as commodities, settlement, shopping carts and other modules. There are always some relatively stable or uncommon modules for a long time or even one or two years without major changes. In this case, a separate version is needed for iteration. Fortunately, these modules are not too many and the business is relatively stable.
4. Quality assurance and risk aversion
In general business iterations, only some module codes need to be modified, adapted, or supplemented. The complete refactoring of the entire module will undoubtedly increase additional development and testing workload, and more changes and modifications will bring about There are more risks and uncontrollable factors, so how to ensure the quality of reconstruction?
At the same time, the business version planning may only involve the business content of this version, not the historical functions of the module. What reference standards should be used to test these historical functions? How to ensure test coverage and ensure that all business scenarios can be Is it covered?
Regarding reference standards, online standards are the best standards. Now web pages provide both http and https access methods. The content accessed by the user is the same, and the server configuration is basically the same. Change the https configuration to the new configuration, but the http remains unchanged. The latest page can be accessed in the form of https, while the old page is accessed in the form of http. Of course, these two pages can be accessed at the same time, so we can compare the old and new pages to ensure that the pages are consistent before and after separation. Sex.
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;
}
}In order to ensure test coverage, we have introduced a code coverage check tool to accurately detect whether a certain line of code is covered by test cases. Through the code coverage report, we can clearly see which codes have been executed, which branches have not been executed, and why they have not been executed. Based on these feedbacks, test cases can be adjusted and supplemented to ensure comprehensive test coverage.
5. Problems encountered
(1) Online deployment sequence
There are three main parts of the online process, namely server-side interface release, front-end static resource release, and Nginx modification. These three operations are dependent on the front and back. If the order is wrong, it will cause online accidents. Therefore, they must be strictly followed. The following publishing order:
- Server interface release
The server interface is forward compatible. During the separation process, it is not directly modified on the old interface, but a new interface is opened to ensure that the new and old interfaces can be called during the release.
- Front-end static resource release
The front-end page depends on the server-side interface, so you must ensure that the server-side interface has been published before you can post the front-end page, otherwise the problem of interface 404 will occur.
- Nginx configuration modification
This step must be put to the end. If Nginx is modified before the front-end static resources are released, a page 404 will appear when the user visits the page.
(2) Disaster tolerance measures
When there is a problem with the version online, how can I quickly roll back without affecting users? Because we are directly intercepting user requests and redirecting to the new static resource server, if there is an online problem, just turn off this part of the interception configuration to achieve the purpose of fast rollback. The server interface is forward compatible, so there is no need to go back.
Fourth, the result
According to this plan, after a year of gradual iteration, we iterated 8 versions, and finally completed the separation of the front and back ends of the wap side, allowing professional people to do professional things. Looking back now, what problems have we solved this technological upgrade, and what improvements and positive effects have it brought us?
The launch speed of pure front-end business is increased by 10+ times
Release R&D manpower, professional people do professional things, and the development efficiency can be doubled
Lay a good foundation for native and multi-end channel expansion
- Accumulate technical experience and empower more businesses
Five, summary
The entire front-end and back-end separation process is long and tortuous. In this process, the biggest problem we face is how to strike a balance between labor costs, business requirements and technology upgrades. This is a very challenging problem for us. In many cases, references and solutions can be found for technical problems, but how can we formulate technical solutions under the circumstances of complicated manpower, resources, versions, and technology accumulation, take all parties into consideration, actively promote problem solving, and identify and avoid risks in advance? Our real test.
Author: vivo official website store front-end team