Author: Xianyu Technology Jinyi/Ma Bao
The background,
With the rapid growth of idle fish business, the number and complexity of business have increased sharply, and the R&D side has two obvious changes in business support: On the one hand, such as home page, search and other traditional flow pages, trial and error and adjustment become more frequent, only card level dynamic ability has been unable to meet the demand, more page level structure adjustment is coming, just take home page as an example, about half of the time last year, are doing page structure adjustment. On the other hand, more DAU leads to the growth of more vertical businesses, such as city, game, excellent products, rental, second floor, etc., which also need their own traffic type “front page”, and in this process, the same type of structure and ability of the page code is repeated, development and maintenance costs are very high.
So is there a solution that can quickly cover traffic-type pages in various business scenarios, and not only adapt to this rapid and variable amount of structural changes, but also can quickly try and error, with as little duplication of code as possible? The answer is yes. Based on the characteristics of flow-type pages that emphasize display and light interaction, our solution is to establish a set of end-to-end page-level description protocol, plus the cloud platform that connects to the protocol to dynamically adjust and render the flow-type page structure. On the one hand, protocol adjustment can be directly mapped to page structure adjustment, so that less code or even NO Code can adjust the page structure. On the other hand, common protocols can be used for horizontal expansion in different service scenarios to reduce development and maintenance costs.
Second, the extension of streaming scene protocol
Last year, Xianyu proposed a containerization solution based on a set of three-level protocols, including Page, Section and Component, which can better describe the situation of a single Page:
• The Page layer protocol mainly contains the information of the entire Page Sections, as well as configuration information such as drop-down refresh and drop-down loading; • The Section layer protocol contains the layout information of the current Section, initialization Event, LoadMore Event, Components and other information; •Component layer protocols are business-specific, black-box for containers, rendering is left to the business side; DX resolution rendering Handler is provided by default.
In the container, the event center is based on the way of event transfer, and the data center is based on the data drive of MVVM. In terms of UI rendering, Xianyu combines the list container with dynamic template rendering DXFlutter to realize page rendering and page refresh capability after data update.
To accommodate complex multi-page scenarios and nested containers, we extend the three-tier protocol design to include Container, Page, Section, and Component. The newly designed Container layer protocol contains information about multiple pages and their corresponding configuration information, such as tabs:
|– Container
|– Page
|– Section
|– Component
Because we need to layout multiple pages at the Container level, we can currently support three types of pages:
Pager + TAB + multi-page form, each page is a single ListView form 3. Pages contain child containers, in the form of nested containers
In the case of the most complex nested Container, the nested child is actually a Component to its parent page, but its internal data structure is a complete Container structure. In the protocol, we give it type=”sub_container”, This time will use the default SubContainerRenderhandler renderer (a container) to parse and render of the container, and in the process of dealing with the corresponding gestures, here we will give the parent container and the container separately into the type specified in the agreement, and provide the type of corresponding gestures responsiveness. The switch message between pages in the sub-container is sent by notification. If it is in the form of TAB +pager, it only needs to set the corresponding monitor on the broadcast message in TAB, and the sub-page can also receive the instruction to switch pages through notification message. In this organizational form, TAB and Pager can communicate with each other under the condition of decoupling.
Iii. Design of cloud platform
The overall design
At present, the traffic platform provides support for business services in the form of two packets. Operation and development can build pages and configure the corresponding resource bit data on the traffic platform. After the data is modified, the platform will write the modified part to TDDL first and then actively synchronize it to cache. The cache can be read by the client package deployed on the service service platform. Normally, if the cache exists, the service only needs to read the cache when responding to the idle client request. Only when the cache does not exist, the service needs to actively pull the corresponding resource configuration data.
Client Two-party package design
The client two-party package deployed in service services has basic capabilities such as configuration acquisition, fractional computing, dynamic registration, and remote invocation. In addition, the client two-party package also has corresponding designs for DISASTER recovery (Dr) bottom pocket and exception monitoring. Depending on the form of two packets, the business side service can obtain the resource and configuration information of the traffic platform in a decoupled way.
Shunting design
Due to the changeable demands of flow-based pages, there is a common demand for AB experiments in trial-and-error scenarios. We designed a set of traffic diversion system on the cloud platform to minimize the cost of AB experiments in streaming scenarios.
When a user requests a container page, the user, version, LBS and other relevant information will be uploaded to the cloud platform through a unified protocol. After the platform gets the information, it will go through the concept layer, diversion layer, instance layer and resource layer. Finally, all instances will be associated with resources and release plan. In this way, the request can finally be mapped to a certain delivery scheme, so that the corresponding user can see the determined page collocation, so as to achieve the purpose of the cloud experiment diversion, and finally let the user see the experimental page he should fall on. In this way, for AB experiments of new or adjusted pages, we only need to configure the traffic conditions that the corresponding experimental pages need to meet on the cloud, which greatly reduces the r&d cost of business trial and error.
Security disaster
The traffic-type page generally bears the role of the business entrance of the corresponding business, and is the portal. Its stability is self-evident, so disaster recovery and the bottom of the bottom are also considered in the overall design of the integrated end cloud.
The air disaster
Under normal circumstances, a client request platform, through the business party service interface userid, city, equipment information uploaded to the cloud, according to the flow design and the second party before the package cache design, if hit, the second party to the cache, it can get will return to cache resource data directly, or you will go to flow request data resources platform and back.
In abnormal cases, or the corresponding cache is not obtained, a copy of the bottom data prepared by us in the cache will be used at this time. The bottom data will inform the business side and server side to prepare new bottom data and remove the old bottom data when the platform operation changes.
Client Dr
Client-side Dr Mainly considers network exceptions or unavailable interface services and still needs to ensure normal page display. In this case, we design three levels of cache at the end: memory cache, disk cache, and preset cache. Cache memory and disk cache will do save action after the callback interface to success, in the case of failure will be preferred to get memory buffer and disk cache, and when the two parts are getting less than, will try to get a preset cached data in the apk package that can ensure the page regardless of any circumstances normal display.
The client interacts with the cloud platform protocol
Since the end-to-end containerization protocol is event-based interaction, the boundaries of overall event interaction have been further broadened with the addition of cloud platforms. As an example, take clicking on a card in your watch list that triggers a watch mark. Traditionally, the client side has written the attention and refresh logic, and then invokes the refresh method when clicked. But if use end-to-end protocol to realize, will become a click will list interface binding events on the current card back to the platform, what is this event, is transparent to end side, in the current scenario is a focus on events, so this event by clicking on the event to the cloud, the cloud to get the corresponding key events, will be issued by the corresponding data, Then the end side only refreshes the data, after refreshes, the current card will appear the attention mark. The benefits are reduced business dependence on side to side release, maximum use of data-driven design, reduced dependency and improved reusability. This design, together with the description and rendering of the page structure by the containerized protocol, will greatly reduce the end-to-end logical coupling and improve the efficiency of business development in the flow-type page that emphasizes the presentation and light interaction.
Summary and Outlook
At present, the containerization construction scheme of End-to-end cloud has been implemented in the scene of xianyu multi-business. Two previous problems have also been solved: 1. Dynamic ability of page structure adjustment: Taking the home page as an example, after the implementation of containerization protocol, page structure adjustment can take effect only by simple modification of cloud platform configuration and few code changes, which greatly reduces the cost of business maintenance. 2. Flow-based page support for horizontal business scenes: with the help of cloud platform configuration and end-to-end container rendering protocol, a new business scene can be completed in about half of the usual development time. More page skeleton codes are deposited in the SDK based on container protocol. In the streaming scenario, the integrated cloud construction system at the lower end reduces the redundant code logic in the specific scenario of flow-based pages in the end-to-end multi-service. The containerized construction scheme of the whole cloud makes it possible for Less Code or even No Code to quickly adjust the page structure and quickly build show-oriented, light interactive and dynamic operation flow-based pages in new business scenarios.