- It is easy to separate the front and back ends of a single project. How about multiple projects together?
- How to do more efficient lift based on the conventional front end separation mode
- How are the PAAS capabilities of the front-end split mode provided?
background
With the increasing number of business lines and platforms in the front end of the department, the responsibilities of the front end are gradually increasing, resulting in various problems and challenges. Currently, there are 31 people in the front end team, responsible for 15+ businesses/projects and platforms. The total PV of the front end project is at least 20 million, and the MAU (monthly active users) is more than 100 million due to the tool-type application. Faced with such a large user volume and business pressure, the team gradually encountered various problems in the process of development and maintenance.
The first is the problem of infrastructure. There is no perfect and unified standard specifications and facilities, resulting in different technology stacks and implementation ideas of each project, and low function reuse rate. In terms of member promotion, how can so many members improve their skills and problem-solving ability? There are other issues that the role is more concerned with, including the overall improvement of front-end development efficiency, and the improvement of upstream and downstream collaboration efficiency. Finally, the guarantee of overall stability, the need to find errors and experience-related problems in the first time, which is another very important issue.
solution
Faced with the above problems, we try to solve them from different angles and dimensions. The first dimension is from the outside to the inside, mainly from the flow, followed by the front end, the view layer, the back end, and the overall stability guarantee. The second dimension is from upstream to downstream, starting from the process of project iteration, from the interaction and visual design of UE/UI students at the beginning, to the development of FE students, and then to the testing of QA students at the downstream. Optimize collaboration process and details to improve overall collaboration efficiency.
The solution
After two dimensions of disassembly, we roughly put forward four solutions. Two of them belong to the first dimension, namely, unified view service and automatic monitoring, and the front component library and material center belong to the second dimension.
The focus of this article is on unified View services, how to better solve problems and improve performance based on the basic front and back end separation pattern.
Unified View Service
background
In addition to its own essential work, the front end is also responsible for the glue layer between the front and back ends, also called the view layer, mainly including routing control, view rendering, data processing/aggregation, resource management, CDN optimization, etc. In the process of maintaining the view layer, we found that the framework and implementation of the view layer are different among most businesses, and each large business direction has its own independent view services. As a result, front-end rendering service development and maintenance, learning and access costs are very high. Then there is responsibility optimization, which thoroughly clears out the fuzzy areas between the front and back ends to make the front and back ends clearer and focus on improving the productivity of all parties. Finally, after completing the optimization in terms of responsibilities, microservitization can be completely completed together with the back end in terms of overall architecture.
The solution
Faced with the above problems, the first is to unify different rendering services (view layer) within the department for normalized management, and the second is the ability of elastic expansion, to achieve the minimum cost of access to different projects and capacity expansion. The third is isomorphic support, which uniformly solves SEO, overall performance improvement and user experience problems in different scenarios. Finally, the microservice architecture is connected to the back-end microservice architecture to make the service more independent.
The difficulties in
The first is the performance requirements, the ability to support multiple services/services, data source aggregation, and the demand pressure of ten million PV. Of course, the most important is the cost of multi-product line access and the performance and maintenance problems after access. The second is the requirement of flexibility/stability, providing platform-based support, ensuring the orthogonal relationship between services, and overall platform-based monitoring, operation and maintenance.
The performance requirements
The guarantee of performance requirements is as follows:
After the traffic passes the BGW and BFE, it reaches the gateway of the web disk microservice, which distributes requests, authenticates users, classifies traffic, and performs other functions. The Gateway primarily forwards requests to either the unified view service or the back-end service. All containers in the unified View service cluster have inner Routers and rendering services inside. After the Gateway forwards the request to the view service, it is first received by the Inner Router, which is responsible for the topology and traffic processing of the downstream rendering service, and then reverse proxy to the rendering service. If the rendering service is under too much pressure, it will notify the Inner Router and ask it to request other rendering service instances to ensure availability. The interaction between the rendering service and the back-end service is realized using BNS and UFC, and the protocol is uniformly handled internally, including IDC room optimization. With the help of the ability of network disk micro-service, to ensure the performance requirements.
These are the most basic capabilities provided by the view layer, but to capture the ability to uniformly manage different product lines, we have also provided some PAAS capabilities, such as access layer configuration, which is responsible for handling traffic and topology on the gateway and inner Router itself. One-click toolkit provides quick initial infrastructure and runtime, as well as daemons, monitoring, log processing, and more. The incoming business party can then simply incrementally take the business code online.
In addition, the deployment level of rendering services is also divided into public deployment and private deployment, with public deployment serving internal platforms and private deployment serving online products.
Stability and flexibility guaranteed
Guarantees for flexibility and stability. Using the ideas of microkernel architecture for reference, we extract the general functions and mechanisms and encapsulate them into the system core. It is the minimum set of capabilities for a service implementation.
Outside core, the corresponding enterprise general services, IDC optimization and tracking mechanism, authentication and data aggregation capabilities are added to encapsulate into a general enterprise framework.
In the enterprise framework outside, but also increased the network disk in the general function, including rendering mechanism, APP isolation, AB test grayscale release, encapsulation into the department level general framework.
Finally, it runs the business and services on the department framework, including commercialization, content mall, open platform, and web disk business.
With these four layers, the application can scale in both horizontal and vertical dimensions. Provides very strong flexible scalability.
The overall architecture
The overall architecture from top to bottom is the application framework, department framework, enterprise framework, basic services and underlying support. Expand on the base service by adding different capabilities at each layer and then using operations like Compose.
Finally, through such a series of design and operation, the performance, flexibility, stability and scalability of the whole view service are guaranteed.
earnings
- Front-end projects/platforms within the department are managed on the Unified View Service (PAAS)
- More front scene experiment and landing ability
- Product performance is greatly improved
- Greatly save hardware resources, the current product line of machines in hundreds (full business), but unified management only need 20 1-core CPU containers (view rendering service) to meet.
About the manometry data
20 containers support 20 million PV (926QPS) and 1000QPS under normal performance requirements, meaning that of the 1000 transactions sent per second, 95% of the requests are processed and returned within 1s. Moreover, it is the test data of the whole upstream and downstream of the online, not purely testing nodeJS, because purely testing NodeJS is meaningless, after all, no online service can be implemented with only one NodeJS.
The throughput of the service improved by 427%, the flat response improved by 74.7% for concurrent and 47.7% for non-concurrent services.
About benefits that can’t be quantified very well
- Unified View service provides the PAAS capability to manage view layers in a unified manner, saving resources and improving development and access efficiency.
- Separate responsibilities and focus on core business
- Give the front end more possibilities and use a variety of frills to increase efficiency.
The last
It’s a little rough, please contact the author if you have any questions or more information.