guide
Due to the complexity of the online car-hailing business itself and the constraints of our vertical domain architecture, the technical team of the online car-hailing server encountered a series of problems during the iterative process of peer rendering business requirements, which affected the efficiency of research and development. This article starts with these specific problems, analyzes the causes, introduces our solution ideas and plans, and the construction and implementation process of the plans.
1. Review of server architecture evolution
In the past few years, in order to meet the personalized travel needs of different users, Didi has gradually launched more and more categories and functions. With the continuous increase of categories and functions, the complexity of our system is also increasing. In order to meet this challenge, the technical team of the car-hailing service has built a "travel platform", which is also called the Gulfstream platform internally. The evolution of the Gulfstream platform has mainly gone through the following stages.
Gulfstream Platform 1.0 (2017-2018)
In the 1.0 stage, the main business focus of Didi online car-hailing is to enrich categories and provide users with more choices, including private cars, luxury cars, and preferential services. At this stage, the Gulfstream platform is still a single service, and the main challenge is how to quickly add new categories and support differentiated development among multiple categories.
To address these challenges, we introduce configuration and plugins. Configuration allows new categories to be launched quickly and reused, improving development efficiency. Plug-in can isolate the difference logic between different categories to ensure the independence and flexibility of each category
Gulfstream Platform 2.0 (2018-2020)
In the 2.0 stage, with the continuous enrichment of categories and the increase of personalized functions, the development team has also continued to grow, and the scale of the system has gradually increased, but the daily iteration efficiency and stability have declined significantly. In order to solve these problems, we modified the Gulfstream platform from two directions.
First of all, according to the idea of domain-driven design (DDD), the single service is split to reduce the complexity of the overall system. At the same time, it also solves the problem of online conflict and queuing caused by the parallel development of team members, and improves the development efficiency.
Secondly, within the domain service, we have aggregated and abstracted functions. By aggregating and abstracting businesses with similar functions, we can avoid repeated development of functions and further improve development efficiency and code maintainability. .
Gulfstream Platform 3.0 (2020-present)
In the 3.0 stage, we developed a set of business framework called DuKang, which divides the business logic of API into two levels. The first is the process layer, which is used to connect the state flow and provide a general process implementation. Different categories can customize their own processes according to their own needs to meet differentiated business requirements.
The second is the capability component layer, which is responsible for completing various vertical functions. The strategy pattern is used in the component to implement different behaviors. For example, the playlist component provides different methods such as delayed playlist and real-time playlist. Different categories can choose the suitable method according to their own needs. At the same time, components also support a plug-in mechanism, allowing categories to inject unique patterns.
Through the Dukang framework, we can effectively constrain the implementation of each service system, maintain a unified specification, allow services in different domains to reuse capability components, and improve development efficiency and code reusability.
For the detailed construction ideas of the Gulfstream platform, you can refer to the previous article "Evolution of Didi Chuxing Platform Business Architecture" . A simple example of the system architecture is as follows:
2. New issues and challenges
Before discussing the challenges of new problems, let us unify some basic concepts.
Page : Refers to the overall area that the user sees on the terminal, including various UI controls, such as the passenger homepage seen when opening the app, and the waiting page for the driver to arrive after receiving the order, etc.
Components : Functional blocks independently displayed on the page, usually with specific business attributes, such as the small helper component in the figure below, which is mainly used to display some important business tips and some marketing activities in the current scenario.
Template : Different UI presentation styles within the component, depending on the definition and existence of the component.
Function : Indicates some specific business scenarios, such as the function of guaranteeing the fleet, the function of self-selecting cars, etc.
Data source : The backend service interface that provides component rendering data.
During the continuous construction of the Gulfstream platform, the iterative efficiency of rendering requirements has not improved. After further in-depth analysis, we found that although the domain service can realize the reuse of functional logic through the capability layer, when doing the rendering logic of the peer Something went wrong. Components in different locations are responsible for different domain services, and these domain services each have their own rendering specifications. Therefore, when the same function wants to be displayed on different components, it needs to be adapted according to the rendering specifications of these components. For example, some components require to return rendering data directly through the interface, while others require data configuration on the platform, which leads to a large cost for a function in rendering docking. At the same time, in addition to the internal problems of the server system, there are also some external communication and collaboration, data development and other challenges.
The figure below shows the current status of rendering processing in the system. Specific issues can be discussed in conjunction with the figure below.
Multi-terminal problem
Didi covers multiple terminals, including Android, iOS, and applets. Since we have divided services in different domains, each domain service needs to directly provide relevant display data to the terminal. For example, the sales domain service provides relevant data on the home page, and the transaction matching domain service provides relevant data on the waiting page, etc. However, this leads to the need for all domain services to be connected to all terminals at the same time, which increases the cost of communication and collaboration and affects iteration efficiency.
At the same time, online car-hailing products require that the experience of multiple terminals be consistent in most cases. However, due to the independent development and implementation of each terminal, and there is no place for unified management and control, inconsistencies often occur. For example, when the length of the same label display content exceeds the limit, iOS will truncate the display, while Android will use marquee display and so on. Inconsistencies in the implementation of multiple terminals will also affect our iteration efficiency. For example, when a product wants to dynamically replace the online display content, due to the different implementations of each terminal, the dynamic capabilities are uneven, and the product has to be differentiated for each terminal. ; After the same function is launched, due to the inconsistent implementation of the buried points at each end, the collected data is very different, and the reason needs to be checked every time, and even different data analysis strategies need to be formulated for different ends. In short, multi-terminal consistency is conducive to the improvement of product experience and efficiency.
Rendering logic management is difficult
The location of components on the terminal is limited, but the functions are constantly accumulating, which leads to the need to display different content on a component according to different business scenarios. According to statistics, there are 40 to 50 display forms and hundreds of display scenarios on some hot components. Faced with such a complex situation, the management of traffic distribution and prioritization is very complicated, and all domain services need to be implemented repeatedly. Complex logic, there is a lot of repetitive work.
Difficult to access functions across processes
There are many functions that need to be perceived in the whole process. For example, the carpooling rights card needs to be perceived in many stages such as bubbling, waiting for a response, and the end of the trip. The pages in these stages are processed by different domain services. They belong to different teams and have their own independent set of specifications for rendering access. As a result, when a function such as carpooling rights is connected to a cross-process display, it needs to be connected with different domain services and needs to be adapted one by one. Access costs are high.
Data is difficult to see
The front and rear ends of each component are custom-implemented by developers from different teams, and there is a lack of unified specifications. The following figure shows an example of carpooling rights. It can be seen that although there are buried points in each location, everyone’s specifications are different. Similarly, it is very difficult to string these data together. Every time you want to look at the data, you need to separately raise the requirements of the data product for development and implementation. The cycle is long and the cost is also high.
The above are a series of problems we encountered in rendering. From the above problems, we can see that the core problem in the current architecture is the lack of unified rendering standards and specifications among the various levels of the system, resulting in a lot of repetitive work As well as the lack of communication between each other, it can be mainly summarized into these three aspects:
Front-end & Back-end : How to build a unified component cognition, how to ensure the consistency of multiple terminals, and how to reduce the collaboration cost of multiple terminals.
Backend : How to manage the complex function display logic in the component, and how to ensure that a single function can be quickly accessed when the whole process is perceived.
Data & front-end & back-end : how to build a unified front-end and back-end data specification, and how to quickly see the data clearly
3. Solutions
The core idea to solve these problems is to carry out standardization, and form a unified cross-end rendering platform through the standardization of different levels. The detailed solution idea is as follows.
Component Standardization
The idea of component standardization is to divide our pages into different components according to functional modules, and then unify the UI specifications and data interaction protocols for these components, and then develop components according to the unified UI specifications and interaction protocols at each end. Manage and control the process and R&D model, so that the architecture of each terminal can be unified, and the experience of each terminal can be consistent as much as possible. Aiming at the problem of multi-terminal consistency, Android and IOS are also exploring ways such as cross-terminal technology, which is not discussed in this article.
With these multi-terminal unified standardized components, in order to realize the reuse of components and reduce the cost of communication and collaboration between the terminal and the back end, we have built a component management platform and a rendering gateway. Terminal R&D configures the page on the management platform, which components are on the configuration page, in what form these components are laid out, where the component data comes from, and so on. With these configurations, when the terminal performs page rendering, it no longer interacts with the downstream services of each component, but interacts with the rendering gateway. The rendering gateway will obtain the configuration of the corresponding page in the configuration background according to the page ID passed in by the terminal. The proxy requests downstream services, and gets the data of each component for unified distribution. Through this form, the cost of communication and collaboration between the terminal and each backend can be effectively reduced. At the same time, this standardized component can be easily reused across pages to improve iteration efficiency.
In addition to benefiting development, component standardization is also of great help to the product business. The previous product iteration process lacked centralized precipitation. As a result, every time a new function needs to be displayed, even if the display style is similar to the previous function, However, since there is no place to check, they will still look for UI redesign, R&D and redevelopment. This is also the main reason for the explosion of display styles on a component. After standardization, the product business can see all the current display styles on the components on the platform. New functions can choose to reuse the previous templates to improve R&D efficiency. At the same time, components and templates can be centrally controlled to maintain a unified experience.
Through the standardization of components, the overall requirements development model becomes the following form:
The component standardization construction process is mainly the construction of the rendering gateway and the component management platform. The following will focus on introducing the detailed solutions of these two parts:
rendering gateway
The rendering gateway mainly provides two interfaces, the layout interface and the data interface. The layout interface is responsible for delivering the layout information of the page, including some static configuration of the page and what components are there. The data interface is responsible for obtaining the data required for component rendering. In the actual running process, considering the performance and experience issues, the layout interface will also return the data of the core components, and the page can be rendered after getting the layout data on the terminal. For some non-core components on the page For components loaded asynchronously, after receiving the layout data, the terminal will request the data interface to obtain the data of these components. The detailed interaction is as follows.
Component Management Platform
The component management platform mainly provides a configuration background to manage component-related content. The main functions include:
Page management , management page identification and page component relationship, etc., you can configure which components the corresponding page contains in the page management, and you can perform some component experiments and grayscale configurations, and the page also provides version management capabilities.
Component management , define components, and manage component templates, including template UI specifications, IDL interaction protocols, etc.
Data source management , registration of downstream data sources, parameter mapping conversion, etc., when the component is registered to the page, the corresponding data source will be configured, so that the gateway can directly proxy the request to obtain the component data according to the configuration.
Component panorama , a component view created for product business. Business and products can track which pages the current app has, which components each page is composed of, and which display styles are supported by each component. You can also see some Which functions will be displayed under this component, and how the traffic of these functions is allocated.
In addition to the core management capabilities mentioned above, the management platform also provides some capabilities in the development experience, such as the multi-version function, which can realize multi-branch parallel configuration development and testing similar to git; gateway interface documents and mock capabilities, due to the interaction of all components The protocol is hosted on the platform. Based on this, the platform will realize the mock function of interface documents and downstream component data to improve the efficiency of joint development and debugging.
Function access standardization
The main idea of the standardization of function access is to unify a set of standard rendering processing logic, and access and use services in different fields. adaptation. In order to unify the rendering processing logic, we have expanded the capabilities of the rendering framework based on the Dukang framework, and solidified the rendering process as context construction -> function filtering -> function decision -> function rendering. Among them, context construction is to assemble the necessary context data required for rendering. Function filtering is to filter out functions that are not displayed in the current scene according to rules such as region, time, and category. Function decision-making is to prioritize the remaining functions and select the final display. function, and function rendering is to fill in data with the selected function. In addition to the rendering framework, we have also accumulated some standard reusable capabilities, such as Kaicheng, whitelist, material management, etc. For the configuration of these capabilities, we have built a function management platform for centralized management.
The following introduces the detailed construction plan of the rendering framework and function management platform.
render frame
The main idea of the rendering framework is to standardize and constrain functions through a set of unified function execution processes. The framework limits the execution process of functions according to context construction -> function filtering -> function decision -> function rendering. The framework only constrains the execution process. The specific logic is still the closed-loop implementation of related functions. For example, functional filtering, if it is just simple filtering, the business side can directly use the standard opening function; if there are some complex strategies that cannot be abstracted, the business side can code them in their own packages. This can not only maintain the standardized definition of functions, but also maintain the flexibility of the business.
Function Management Platform
The function management platform mainly provides function management capabilities. The main functions of the platform are as follows:
Function display strategy configuration , combined with the accumulated display rules of cities, categories, scenes, etc., configure display strategies corresponding to different functions
Function priority configuration , configure the priority between functions under the component, the priority supports multiple groups, such as different cities, the priority may be different
Functional copywriting material configuration , configuring the copywriting and related materials required for the corresponding function display, this part is due to the great differences in the configuration methods of different functions, we combined an internal general configuration platform to achieve, on the general configuration platform, rd first according to the actual Requirements, develop function copywriting and material configuration templates, connect the function management platform with the general configuration platform, and integrate the corresponding configuration pages to form a unified configuration platform.
Functional full-link view , which is mainly provided for product business use. Previously, due to the lack of unified specifications and precipitation, it was difficult to see where a function was revealed and how the effect of each place was transformed in a centralized place. . After our standardization, we can provide a full-link view of functions, and easily see on which components each function is exposed, what is the corresponding traffic distribution, what is the conversion funnel, and so on.
data standardization
After standardizing the access of components and functions, data standardization is a matter of course. We only need to record the unique identifiers of pages, components, templates, functions, etc. defined earlier in the log of each stage, and open up the data link at the same time, according to the unified According to the specifications for data reporting, collection, cleaning and aggregation, a set of standard data solutions can be formed. In the subsequent function development process, no additional data development is required, and the required components or functions can be seen according to the identification of the components or functions. data.
Buried protocol unified
The core of the unification of buried point protocol is to enable the aggregation of buried point information of different services. As long as everyone adopts a set of fixed protocols, agrees on the fields to be aggregated, and aggregates through data collection and cleaning steps, data unification can be realized. We have formulated a series of protocols such as front-end reporting, gateway sending logs, and data source service logs, and unified the identification of pages, components, templates, and functions. The overall idea is as follows, through the unified management and control of the platform, the unified configuration of buried points, and the unified reporting of buried points by each service using the SDK.
The data link is opened
Open up the data link from the terminal to the back-end service, aggregate the data into a unified data warehouse through a standard protocol, and then form a unified data dashboard. The main data link diagram is as follows:
Summarize
To sum up, we have completed the construction of the entire cross-terminal unified rendering platform through the standardization of components, function access and data. At present, the platform is still in the process of continuous construction and promotion. The rendering gateway, component management platform, rendering framework, embedded point The construction of the specifications has been completed, and the function management platform and data link are still under construction. Currently, the unified rendering platform has access to 20+ pages, and will continue to cover all rendering scenarios in the future.
The overall system architecture diagram of the platform is as follows:
END
Author and department introduction
The author of this article, Wu Jun, is from Didi’s online car-hailing travel technology team. As a research and development team for online car-hailing business, travel technology has built an end-user experience platform, C-end user product ecology, B-end transportation capacity supply ecology, travel safety ecology, Service governance ecology, core guarantee system, and create a travel platform that is safe, reliable, efficient, convenient, and user-reliable.
Job Offers
We are recruiting for the backend of the team and testing requirements. Interested partners are welcome to join. You can scan the QR code below and submit your resume directly. We look forward to your joining!
R & D Engineer
Job description:
1. Responsible for background research and development of related business systems, including business architecture design, development, complexity control, and improvement of system performance and research and development efficiency;
2. With business sense, through continuous technical research and innovation, iteratively improves the core data of the business together with products and operations.
Test Development Engineer
Job description:
1. Build a quality assurance system applicable to the online car-hailing business, formulate and promote the implementation of relevant quality technical solutions, and continue to ensure business quality;
2. In-depth understanding of the business, establish communication with various roles in the business, summarize business problems and pain points, create value for the business in an all-round way, and work without fixed boundaries;
3. Improve business code quality and delivery efficiency by applying relevant quality infrastructure;
4. Precipitate efficient testing solutions, and provide generalized solutions to support landing applications in other business lines;
5. Solve difficult problems and complex technical problems in business quality assurance;
6. Forward-looking exploration in the field of quality technology.
