Wang Yang: Technical leader and technical expert of Maoyan Movie Commodity Business Line. Leading the construction of Maoyan’s commodity supply chain and trading system from 0 to 1, and in the process of splitting Maoyan and Meituan and integrating with Dianping’s film business, it has ensured the smooth switching of commodity business from a technical level, and is also the source of Meituan’s “Dianping”. Lecturer of Domain Driven Design course. Before joining Maoyan Movies, he worked for Ant Financial, and participated in the construction of Alibaba Internet Banking from 0 to 1, as well as the research and development of Alipay wallet, Huabei and other products.
Introduction: The Internet movie industry experienced major changes in 2016, including the split of Maoyan Movies and the original Meituan, and the integration of Maoyan Movies and Commentary Movies. When there are major changes in the business, the technology usually undergoes major reconstruction. During the whole process of splitting and integration, the Maoyan back-end technical team has made more adjustments and reflections on the system architecture and domain model, and explored A set of technical solutions with a relatively balanced cost and benefit. This article will share the specific process, steps and methods of practice, hoping to provide some reference cases for technical teams who encounter business split and integration in the post-Internet era.
one. statement of problem
Internet companies with a certain scale usually have many subdivisions and vertical businesses. In order to improve efficiency, most companies will adopt a platform-based idea: build a common basic platform, and all business lines are based on this basic platform. Build your own business and technical services. This approach can reduce labor costs on the one hand, and improve the efficiency of new business development on the other hand. In order to develop rapidly, Maoyan’s commodity business adopted this development model at the beginning, and built the entire business transaction on Meituan’s group buying system, as shown in Figure 1:
As can be seen from the above figure, the commodity business is completely dependent on Meituan's commodity, order, payment, promotion, and coupon services, and the coupling is very high. Since Meituan and Maoyan were the same company at the time, this coupling was acceptable. However, after Maoyan became independent, the organizational structure and business planning were quite different. This coupling became a major problem for the follow-up development of commodity business.
Based on the consideration of independent development, Maoyan needs to separate the commodity business from the group purchase system and integrate it with the commodity business of Dianping Movies to form a new business and technical system to support subsequent business development.
After a lot of status analysis and research, the team determined the goals of this technology upgrade:
● Product demand cannot be interrupted.
● Lowest customer perception.
● The old and new systems can be switched freely.
● Lowest trial and error cost.
● Continuous phased delivery and verification.
The complexity of the e-commerce system, from supply chain to transaction to settlement, is already very high. Coupled with the time required for business switching and data integration, it will inevitably be a protracted battle. In order to reduce risks and allow business, finance and other teams to better cooperate with us, the technical team must produce in stages and do online verification.
After determining the above five goals, we need to think about how to design the overall plan around these goals.
two. Technology split plan
First, let's analyze the business scenario. Figure 2 is a simplified diagram of the commodity business:
As can be seen from Figure 2, the entire business can be disassembled into four major modules, so that we can roughly determine the division of the team: supply chain, transaction, consumption, and post-consumption service. After determining the composition of the team, we need to make a clear division of the importance and priority of services. The dimensions of the analysis are as follows:
● The basic data level, such as merchants, users, and contracts, are the resources accumulated by the company for a long time and cannot be rebuilt in the short term. Therefore, the services at this level should reuse the previous services as much as possible.
● At the core service level, the core of the supply chain is placing orders, the core of transactions is commodities, orders, payment, and promotions, and the core of consumption is logistics, commodity coupons and corresponding gateway services. These are the main processes of transactions and must be reconstruction.
● At the financial level, such as the settlement with merchants and the accounts reflecting the operation of the business, when the company is split, it usually requires independent accounting, so the services at this level must also be rebuilt.
● Non-functional services, such as customer service and after-sales services, usually do not have a high priority, but if they are not available, they will affect the user experience. Therefore, try to reuse the previous services and consider rebuilding them later.
After the above analysis, we have determined the services that need to be rebuilt in the first phase of the project.
2.1 Preliminary solution for splitting
After determining the services that need to be rebuilt, you can't rush to develop them. You should think about how to switch if all the services are already available. There are a few things to consider:
● How the product will be sold during the switching period.
Earlier, we established the goal of "free switching between the old and new systems", so in the process of switching, it is necessary to ensure that the last order of the merchant and operation can be sold in the three systems of Meituan, Dianping, and Maoyan, which can improve the switching efficiency. Flexibility to reduce transaction losses caused by switching.
● Version issues.
As mentioned above, the commodity business was built on group buying at the beginning, and most of the interfaces called by the client are the interfaces of Meituan group buying. The most intuitive way is to add judgment in the group purchase interface, and divert the transaction requests of the movie category to Maoyan. This method is fast and has no traffic loss, but the burden of modifying the interface parameters and expanding the business in the future is relatively heavy. Maintainability is relatively poor.
● The mode and granularity of switching.
In order to achieve the goals of "free switching between old and new systems" and "minimum trial and error cost", during the switching process, the old and new coexist will inevitably be in a state, so we cannot simply replace the interface, but adopt a more flexible switching method and finer switching granularity.
● Relationship with Maoyan's existing business.
Maoyan itself has a set of seat selection transactions, but subject to industry models, it cannot support commodity transactions for the time being. Considering that integration is definitely required in the future, the relationship between the two sets of transactions needs to be considered in advance.
2.1.1 Single and double push
In response to the problem of sales, Maoyan adopts the method of "single and double push", as shown in Figure 3:
Under normal circumstances, the ordering system will push the product to the product center after confirming the product information submitted by the merchant. In order to sell products in the three systems of Meituan, Dianping, and Maoyan, Maoyan needs to do the following steps:
● Migration of historical orders.
First, synchronize the currently available products to Maoyan from the Meituan Commodity Center to keep them aligned.
● Establish relationship mapping.
For merchants, no matter if a product is sold in several systems, it is one product. When counting sales and settlement, it should be one product, so we need to associate products in multiple product centers. This is relatively simple to do, as long as you assign an id to the cat's eye product, and then save the other party's id in the product data.
In addition, in order to distinguish the products of the two systems, we use a segmentation strategy to allocate product ids. For example, the current Meituan product’s maximum id is X, then the Maoyan product uses 2×X as the starting id, while in the United States Before the group product id increases to 2*X, we must have completed the switch, and we no longer need to consider the problem of unification of the id sequence.
● Double push of products, and inventory distribution in proportion.
After the Maoyan ordering system confirms the product information, it pushes the products to the two commodity centers of Meituan and Maoyan, creates their own inventory, and allocates the inventory according to the current transaction ratio. Since the two systems of Meituan and Dianping are integrated, it is only necessary to push Meituan group purchase, and Dianping can be sold.
2.1.2 Business Entry Recycling
After solving the sales problem, let's consider the version and switching method.
As we all know, once the mobile app is released, it is difficult to change the code, so after the switch is completed, it is difficult for the old version to support the existing system. However, after analysis, we found that 2~3 versions of several apps involved in Maoyan can cover more than 90% of the clients, and the core service is self-built enough to support the iteration of more than 3 versions, so that when all the switching is completed, you can Reduce the traffic loss of the old version to less than 5% (the user's willingness to trade in the old version has a certain loss), which is an acceptable range.
In order to speed up the switching, we need to replace all the business entrances in the transaction and consumption links, that is, the interfaces called by the client, with Maoyan's own interfaces before the core services are built. As shown in Figure 4:
On top of Meituan's services, a business process layer is first established to provide the client with the interfaces required for transaction and consumption links, and then the business process layer transfers the basic services of Meituan group buying. For example, the ordering operation, which originally called the interface of Meituan order directly, is now transferred by the transaction business system. Once the development of Maoyan's order system is completed, it only needs to replace the Meituan order service with the Maoyan order service to achieve seamless connection .
2.1.3 Switching method and granularity
After the service entry is recovered, the granularity of handover needs to be considered next.
At present, there are several granularities: merchandise, theater, app, entrance location (show page, payment page, ticket machine, search, recommendation). Taken together, the cinema + entrance location is a reasonable granularity.
The granularity of commodities is too fine, and the data changes dynamically, which makes it difficult to maintain; the dimensions of the app are too coarse, and the scope involved in one-time switching is too large, and it cannot be rolled back; the granularity of theaters is in the middle, the data changes are small, and the traffic It's easier to control, so we used cinema as the main switching granularity.
In addition, because the characteristics of the commodity business itself are relatively fragmented, there are many entrances, and services such as search and recommendation of Meituan and Dianping have to be connected, so the location of the entrance is used as an auxiliary switching granularity.
Before switching, assign fixed channel numbers to all display portals, as shown in Figure 5. The payment page is channel 1, and the ticket machine is channel 3. The client needs to bring the channel number when requesting background data; then the commodity business system abstracts the query logic into a processor, for example, the Maoyan payment page processor is connected to Maoyan's commodity center , and Meituan's payment page processor is connected to Meituan's commodity center, and public processes such as sorting and lowest price calculation can be abstracted into the parent class.
When a query request arrives at the commodity business system, the channel distribution controller selects the corresponding processor according to the channel number. At the same time, the channel distribution controller needs to ask for the channel switching service suggestion to see whether to use the group purchase system or the Maoyan system. And we only need to maintain a list of theaters + channels that follow the Maoyan system in the channel switching service, and then use the configuration push service to dynamically update, we can achieve free switching between the two dimensions of theater + entrance location.
Through the above methods, the back-end system has realized the free switching of the two systems at the commodity display level, but the follow-up transaction process is still very long, and the client needs to be able to distinguish which interfaces should be used in the future before it can go to the correct transaction process. . Figure 6 shows the changes that the client needs to cooperate with:
The client needs to maintain two sets of transaction interface lists, one for Meituan and the other for Maoyan. When the backend interface returns the product data, it will carry the mark of whether the product is Maoyan. If it is true, the subsequent processes will use the Maoyan transaction interface; if it is false, the Meituan transaction interface will be used. After the switch is completed, all the tags returned in the background become true. The client can also consider deleting this logic and directly use the interface list of Maoyan.
2.1.4 Unified id service
Finally, consider the relationship between commodity transactions and existing businesses.
The core of the transaction is the order, and there is already a set of seat selection orders in Maoyan, but the models of the two are very different and cannot be reused. The complexity of data fusion.
To unify the order id, a statistical id service is required, as shown in Figure 7. Before placing an order, each transaction business obtains the order number from the unified id service, and then places the order, which ensures that the order numbers of the entire company are distributed in the same increasing sequence, reducing the complexity of system integration such as promotion and settlement.
2.2 Self-built core services
After completing the design of the pre-plan, the next step is to analyze the core services required for the transaction. The following is the behavior analysis diagram of the commodity business:
As can be seen from the above figure, the entire transaction process can be simply divided into three stages: before the transaction (commodities as the core), during the transaction (orders as the core), and after the transaction (that is, the consumption process, with commodity coupons as the core). The following is a detailed analysis of how the core model of each stage should be designed.
2.2.1 Commodity output model
According to the function of commodities, we can divide the existence form of commodity information into three stages: editing stage, use stage, and business aggregation stage. The following is a description of the three stages:
● Editing stage, ie products that are not yet formed.
At this stage, the above single process is the core, and the writing model of the product is maintained. Therefore, it is necessary to focus on the addition, deletion and modification of the product, and make an audit mechanism and operation records. The model at this stage is mainly maintained in the top order system.
● In the use stage, that is, the products that have passed the review and are allowed to be sold.
This stage maintains the basic information of the product, some of which are read-only, such as the product title, price, store to which it belongs, etc.; the other part is variable, such as inventory, sales, and product status. The model of the use stage is mainly maintained in the commodity center.
● The business aggregation stage, that is, the commodity after integrating other information.
This stage maintains the reading model of the product, and cannot change any information about the product. For example, the product list aggregates multiple product information, and the product details aggregates the basic information and promotion information of the product. When external systems, such as search and other services, need to be connected to the commodity system, commodities in the business aggregation stage should be output. The model at this stage is mainly maintained in the commodity business.
After the three stages of commodities are defined, the relationships of the systems can be organized according to the way each system uses the commodities, and the output model shown in Figure 9 can be obtained.
2.2.2 Order Processing Model
Order is one of the most important models in the transaction process, and it is also the most easily coupled module with business. Therefore, when designing the order model, it is necessary to focus on how to separate the order from the business process, and only focus on the basic information and status flow of the order. The main points to consider are:
● Command model and query operations need to be separated, namely CQRS.
For example, placing an order and querying order details are two operations. The former is the main process of the transaction, and the information of the order will be written, while the latter will not change any information of the order, and only need to query the order. In addition, placing an order focuses on business processes, and the core indicators are stability and accuracy, while inquiring about order details focuses on data aggregation, and the core indicators are integrity and user experience.
● Business process and order processing need to be separated.
For example, placing an order may be divided into several steps: judging whether the product is available for sale, calculating the price of the product, locking the inventory, writing order data, etc. These steps are business processes and the order shouldn't care. And the transaction process of each business may be different, so a more flexible method is needed to handle the transaction process.
After considering the above two issues, we designed an order processing model, as shown in Figure 10.
First, a task processing engine must be developed, which is responsible for processing individual tasks in the business process, such as locking inventory, generating commodity coupons, pushing order information, and so on. Each task corresponds to a database record, which is used to describe which processor to use, where to get the data used, and what to do after the steps are completed. The records are also connected by numbers to process priorities. and dependencies.
The order receiving service is responsible for disassembling the ordering process of different businesses into sub-tasks, determining the priorities and dependencies between tasks, performing simple arrangements, and then writing them into the database of the task engine, while the task engine Responsible for fetching these tasks, analyzing and executing tasks that have been programmed. The advantage of this method is that the business process is very finely divided, and some task processing steps can be reused between different businesses. When a new transaction business is accessed, only the corresponding subtask processor needs to be added, and then the order is received. The rules of configuration and arrangement in the system can be quickly supported.
As shown in Figure 10, we separate the order writing model and the query model, so that the three operations of addition, deletion and modification follow the writing model of the order core system, while the user query operation follows the query model of the order query system. Every time the order information changes, the order core will notify the task engine, and the task engine is responsible for updating the query model. There will be a time delay during this period, so the query model for order query and maintenance can only be used by the user to display the demand, while the query of the order status during the refund process must follow the order core writing model, because the status of the writing model is real-time. .
After the user successfully pays the order, the order core will receive the payment success message, then split the different types of orders, and notify the task engine one by one to execute the business process after the payment is successful, such as generating commodity coupons and pushing order information to Meituan orders list etc.
2.2.3 Commodity vouchers and settlement model
Commodity vouchers and logistics are the core models in the consumption process, and settlement just needs the data of the consumption dimension, so the designs of the two are closely related. Since commodity coupons are similar to logistics, this article only introduces the model of commodity coupons.
The essence of a commodity voucher is a string of numbers, which is used as a voucher for redemption services. Its features:
● First, it must be chaotic enough that you can't just enter a number and use it;
● Second, it should not be repeated, otherwise it is impossible to distinguish which service it corresponds to.
In terms of data operations, commodity coupons need to support operations such as generation, verification, and revocation.
After the above analysis, we have designed a model of commodity coupons and settlement, as shown in Figure 11:
In order to be chaotic enough, the system needs a random number generation module. At the same time, in order not to repeat it, an anti-collision table needs to be established for random numbers. After each random number is generated, it is necessary to check whether it has been used in the anti-collision table. Since random numbers are limited, the more codes are generated, the higher the probability of collision, which will have a certain impact on the degree of concurrency. In order to optimize this problem, we adopt the asynchronous generation method: first pre-generate a certain number of coupon codes and add them to a queue of available coupon codes. Under different concurrency numbers, as long as the capacity of the queue and the pre-generation speed are adjusted, can be supported.
When the user verifies the coupon code through a POS machine and other equipment, the commodity coupon will send a message to the settlement system, and the settlement system will write a flow of data to the database, and aggregate it together according to the settlement cycle to form a payment plan. The settlement system will also scan the settlement cycle agreed in the contract every day to trigger payment operations.
2.3 Switching between online and offline
In the front-end solution introduced above, we have embedded the switching point in the client in advance. When the transaction model is built, there are actually a large number of clients online that support switching between the two systems. But at this time, we can't rush to switch all merchants to the new system, we need to consider more issues:
● Whether the existing services in the old system are already supported in the new system. For example, promotions and coupons can only be switched when the business is aligned, otherwise it will interfere with the normal operation of the business.
● Whether the merchant settlement mode supports switching. In the process of splitting, settlement and financial data are the only data that cannot be migrated, and any changes require clear accounting between the two companies' financials before they can be implemented. Therefore, before switching, it is necessary to classify the merchants according to the settlement mode, and give priority to switching merchants with simple settlement methods to the new system to verify the correctness of online services and the rationality of the switching plan.
● Whether the transaction process relies on third-party systems. For example, in the post-transaction process, Maoyan relied on the theater's third-party coupon system, which resulted in this part of theaters being able to switch only after connecting to the third-party system they depended on.
After analyzing the above three factors and determining the list of merchants that can be switched, you can start to promote the online and offline switching together with the business. During the switching process, it should be noted that the offline switching is usually slower than the online switching, so the offline switching should be started in advance, and the business team should train the merchants well.
three. Technology Integration Solution
After technical splitting, Maoyan actually has a complete commodity supply chain and trading system, and the commodity business of Dianping also has its own supply chain and trading system. In order to reduce maintenance costs in the future, we must adapt the commodity business of Dianping to the supply chain and transaction system of Maoyan.
The solutions at the supply chain level are similar to the solutions for splitting, which will not be described in detail here, but will focus on the adaptation and integration methods at the transaction level. When designing a fusion technology solution, we need to focus on the following issues:
● Migration problem of the client calling interface. The Dianping client was connected to Dianping's business services before, and it needs to be replaced with Maoyan's business services.
● Transaction flow connection and page jump problems. After the integration, the core transactions such as order, payment, and coupon consumption must follow the Maoyan transaction system, so the entire transaction page and jump should use the Maoyan page.
● Existing data integration issues. Before the integration, Dianping has accumulated a large amount of commodity order and coupon data. This part of the data needs to be integrated with Maoyan data to meet the query needs of users and merchants.
3.1 Service entry adaptation
For the problem of the client calling the interface, the solution is similar to the split solution. The business layer is also established in advance, and the interfaces used by the client are recycled to the business system, and then adapted to the business service of Maoyan, as shown in Figure 12. .
In order not to maintain two sets of business systems as much as possible, Maoyan first adopted a simple adaptation when integrating the first phase of the project. The purpose is to draw the business entrance to Maoyan's trading system first, and then let the comment client directly in the subsequent development. Docking with the business system of Maoyan will gradually replace the adaptation layer of Comments. When there are fewer and fewer versions to be adapted, this adaptation layer can be discarded.
3.2 Use the touch screen version in the transaction process
The connection and jump of the transaction process is a relatively difficult problem. First, Maoyan has not done development on the comment client before, and it is expensive to create a set of native transaction pages in order to integrate it. Second, when iterating on functions in the future, There are too many terminals to be adapted, which will slow down the speed of product iteration. After comprehensively considering the factors of traffic, experience and team, Maoyan decided to use the touch screen version to solve this problem.
Commodity trading has a characteristic, that is, most of the ordering operations will go through the product details page first, so as long as you start from the product details page and create a set of touch-screen pages, you can guide the transaction process to the Maoyan page.
However, the display of products is usually fragmented, and there may be various entrances such as search, recommendation, product list, guess what you like, etc., so the first step in entering the transaction is to make the display entrance jump to the touch screen version of the product as much as possible. Details page, then continue to place an order, pay, and then jump to the result page of the touch screen version. After the order is successful, Maoyan will push its own order data to the order center of Dianping, and set the jump of the order details page to the touch screen version. Once the user clicks on the order list, it will return to the controllable range of Maoyan, and subsequent refunds, consumption, and customer service will go back to the trading system of Maoyan. The specific method is shown in Figure 13.
During the whole process, you may encounter some other problems, such as jump login: the comment client logs in to the comment account, while the touch screen version of Maoyan logs in to the Maoyan account, so this method also depends on the integration of accounts. You also need to be careful when jumping to the cashier. You need to use the same verification method and parsing rules for the comment cashier and Maoyan cashier. Otherwise, it is very easy to have an incorrect amount or fail to pay. These are also issues to consider for the touchscreen version.
The premise of using the touch screen version is: the transaction process must go through the product details page. If the transaction process does not go through the product details page, multiple business portals must be adapted, but the process after jumping to the cashier is still possible. reusable.
3.3 Data Integration Ideas
Data integration is the most tedious part of technology integration, and there are usually three approaches:
● There is no integration at the data level, and which data source should be used at the code level. The advantage of this method is that the data does not need to be changed, but two sets of data sources need to be maintained, which is costly.
● The data layer establishes the mapping relationship, and then converts the data into the model required by the business side through the transformation layer. The change cost of this method is relatively controllable, and the interoperability of the two systems can be quickly realized.
● Completely integrate the data level, and migrate the data of the two parties to one data source. The advantage of this method is that only one set of data models is retained, which is highly maintainable in the later stage, but it is difficult to integrate and needs to focus on processing differential data.
In the integration process of Maoyan and comment data, the following two methods are mainly used, as shown in Figure 14:
The query data usually uses id, and we can simply divide the data id into two categories: one cannot be changed, such as theater id; the other can be changed, such as order id.
For theater IDs, Maoyan and Dianping have their own set of sequences, and these two sets of IDs are attached to their respective merchant systems and cannot be easily unified, so they can only achieve interoperability by establishing a mapping relationship. The example in the left half of Figure 14 is to solve the scenario where the data id cannot be changed:
First, establish a mapping relationship between the theater id of the review and the theater id of Maoyan. For example, the theater id of Maoyan = 1 and the theater id of the review = 2, which may point to the same theater (only for example use, not guaranteed to be a corresponding relationship). The Maoyan app and Dianping app still use the previous id, but when querying data, they will first go through the data conversion layer, analyze the mapping relationship by data conversion, and get unified theater information.
For the order id, the user usually does not manually record the order id, and completely relies on the background to return. At this time, the reviewed order data can be migrated to the Maoyan database according to the Maoyan format, and the id is converted into the id of the Maoyan sequence. , if the fields are different, you can use extended fields or difference tables to make a layer of compatibility.
The right half of Figure 14 describes this approach: when the user queries the order list, the order id of Maoyan is returned, then when entering the details, the order data of Maoyan will naturally be queried, thus realizing data integration .
It should be noted that when modifying the order id, it is usually necessary to modify all order-related data, such as promotions, commodity coupons and other systems, which are based on the order id, which requires modifying all the involved data at the same time. It needs to be proceeded with caution.
4. Case inspiration and lessons
The process of technology splitting and integration lasted for nearly half a year in Maoyan. During this period, many difficulties were encountered, and a lot of thinking about the system architecture and model was also carried out. The following are the inspirations obtained from the case:
● When large companies are doing vertical business, if they want to reuse platform services, it is best to establish a business layer between the client and platform services, and do a layer of service transfer, which can provide better flexibility for service replacement .
● When designing the system model, try to make the business entrance channelized and the processing process componentized, which can not only improve the horizontal scalability of the system, but also make more precise control of each entrance
● When different businesses are developing rapidly, You can have your own core services, but you must use a unified id generation strategy to ensure that the main ids of the model belong to the same increasing sequence, which can reduce the complexity of data integration for future integration or platformization.
● At the data model level, try to separate the command model from the query model. On the one hand, it can completely separate the main process and data display operations; on the other hand, it can also reduce the complexity of data operations.
● The flow control and switching granularity of the system should be fine enough to improve the ability to deal with risks.
There are also some lessons learned from this case:
● When designing a technology split and integration scheme, it is necessary to fully consider the impact of non-technical factors, such as settlement and finance. Data can neither be migrated nor modified. At this time, the financial conclusion is likely to affect the overall switching scheme and model design. .
● Offline switching should be carried out in advance, so that feedback from the front-line business can be collected as soon as possible, and problems can be repaired in parallel, so as to ensure that the online switching process will not be slowed down.
V. Summary and thanks
Technology splitting and integration is a huge project, involving many technical points. Due to the limited space, this article only introduces the overall design scheme, hoping to provide a reference case for engineers in the industry who encounter the same problem.
Finally, I would like to thank all the technical, product, operational and commercial, and financial team members who participated in this technology split and integration, as well as colleagues from Meituan Dianping who helped me. With the close cooperation of everyone, such a complex technical upgrade can be completed in a limited time.
From November 9th to 12th, Beijing National Convention Center, the 6th TOP100 Global Software Case Study Summit, Hao Jinghua, Meituan Food Delivery Algorithm Architect, will share the "Meituan Delivery Intelligent Scheduling System Evolution"; Meituan Dianping Wine Travel Quality Team Tool Chain Wang Peng, the person in charge, will share the "Practice of Automated Testing and Continuous Integration Tool Chain under Microservice Architecture".
The TOP100 Global Software Case Study Summit has been held for six sessions to select outstanding global software R&D cases, with 2,000 attendees every year. Including product, team, architecture, operation and maintenance, big data, artificial intelligence and other technical special sessions, on-site learning of the latest research and development practices of first-line Internet companies such as Google, Microsoft, Tencent, Ali, Baidu and so on. Application entrance for the single-day experience ticket for the opening ceremony of the conference