Shulou(Shulou.com)06/03 Report--

| | Source of this article: https://yq.aliyun.com/articles/511876 |

Author Ryu Xin, original title "how to achieve a peak of 325000 transactions per second?" Ali trading system TMF2.0 technology revealed ", technical details are authorized to reprint.

General introduction

On Singles Day in 2017, the trading peak reached 325000 transactions per second, which brought great challenges to the entire trading system. On the one hand, the system needs to support all the transaction needs of dozens of business departments throughout the group: consider how to respond to the demand more quickly and speed up the release cycle; how to provide rapid support for new small businesses and reduce the barriers to entry; whether the business is open enough to achieve self-service expansion; whether the new requirements already have reusable assets in other business departments.

The characteristics of the Internet determine that the business system is a distributed architecture built according to domain services. The e-commerce business is characterized by a long business life cycle, from investment promotion, selection, supply chain, warehousing, marketing / shopping guidance, issuing orders, performance, logistics, after-sales, etc., its long business link, upstream of business logic has an impact on the downstream. On the link of this main line of business, many systems have been built to support it, such as commodity platform, shopping cart system, order issuing system, fulfillment system, preferential system, logistics system, supply chain system and so on. Around these core systems, there are countless auxiliary systems / services, such as service platform, Tmall SMC, Taobao CPC and so on.

In the process of each business requirements analysis, it is necessary to be able to analyze requirements, evaluate technical solutions, encode, co-tune and release from the full-link perspective of the business life cycle. This whole process is also a complex cross-team assistance process, and the pain points are mainly reflected in:

1) lack of demand management mechanism from a full-link perspective, and low coordination efficiency

2) the entry threshold for the platform is high, and new small businesses cannot make quick trial and error.

3) the business is not well separated from the platform, which can not support the development of business self-service (Self-Service)

4) lack of reusable business assets.

Pain point 1: lack of demand management mechanism from the perspective of full-link business, and low efficiency of coordination

The tracking and management of business requirements lacks a full-service link perspective, which is mainly reflected in:

The description of requirements is often a sentence. The detailed description of requirements is basically explained in the form of later documents, emails and organizational requirements clarification meetings. In the explanation, we will try our best to pull up the platform developers who can think of and may be related to it, and the scene is spectacular.

Demand delivery is inefficient and requires repeated communication. In the process of modeling and decomposition, business requirements are lack of effective delivery carriers and forms, which can not be transmitted to the development accurately and seamlessly, resulting in repeated communication and clarification, requirements rework and repeated workload.

There is a lack of platform capacity, and it takes a long time to evaluate the technical solution. When technical students evaluate the needs to achieve changes to the platform, due to the lack of platform capabilities and the separation of business and platform code, it is very difficult to evaluate the new renewal for the technical solution evaluation. what capabilities can the existing platform take? Which businesses will be affected by the changes? Which surrounding systems do they have an impact on? How much work is there? These basically need to be repeated after the code analysis and evaluation.

Similar demand for repetitive construction. After the requirements are released and put online, the personnel will be replaced with the passage of time. No one knows how this requirement was realized at that time. When you encounter a solution assessment with similar needs, you can only turn over the code or repeat the implementation again.

Pain point 2: the entry threshold for the platform is high, and new small businesses cannot quickly try and make mistakes.

New small businesses have a growth rule, in the early business model verification stage, the need to play is relatively simple, hoping to release frequent quick trial and error. However, although the shared trading platform, commodity platform and marketing platform can support a variety of business models and marketing methods. But for new small businesses, these are not applicable in the early days, and they want the platform to be tailored flexibly, such as:

1) whether the order issuing process can be tailored to a minimalist process instead of having to follow a complete process

2) separate from other business codes at run time, and do not want to be affected or affected by other businesses

3) the pace of business release can be controlled by itself, and we don't want to wait for the weekly return of the whole network.

Pain point 3: business and platform are not well separated, unable to support business self-service (Self-Service) development

Alibaba's e-commerce business is varied, and the positioning of each department is also different, some of which are oriented to "vertical" industries, such as Tmall automobile business, box horse fresh business, air travel business, and so on; while some are positioned for platform business supporting all industries, such as cost-effectiveness, shopping guides, and so on. Therefore, the business itself will be divided into "vertical" and "horizontal" dimensions. In the process of a business interaction, the business complexity lies in the superposition of the business "vertical" dimension and the "horizontal" dimension, and the conflict of business rules caused by the superposition.

For the processing of business overlay, each system is basically based on the SPI extension mechanism, and these SPI are lack of organization and isolation according to the business dimension. In the case of few types of business and small logical superposition of different services, the problem of customization and diversification of business can be solved to a great extent. However, with more and more kinds of business, the superposition effect of all kinds of business on the same extension point becomes more and more prominent. The weakest point is the writing of the filter method (filter) that needs to be executed in the SPI interface. Once the filtering method is not well written, it may cause the logic that should not be executed to be executed, or skip the logic that should have been executed later.

In the shared platforms, there are hundreds of SPI that can be extended to the business side. Whether the final logic of a business is correct, it is necessary for the business to ensure that each node in the hundreds of SPI decision trees registers in the correct location, the filtering conditions in the filtering method are correct, and the execution logic must be accurate. Not only that, the SPI registered for this business is correct, and the SPI for other business registration is also correct, which ultimately leads to a high degree of coupling between the business and the business. This coupling further leads to a large number of joint adjustment, integration and regression among business parties and between business parties and platforms, which can not achieve self-service business design, development and delivery.

Pain point 4: lack of reusable business assets

Whether an enterprise's IT system construction is mature, the industry has some guiding frameworks to evaluate, such as the TOGAF framework. In this information system construction framework, there is a very important system maturity assessment project-Enterprise Continumm (Enterprise Unity).

The key here is that enterprises need to build:

Architectural entity (Architecture Continuum): this entity can extract reusable components from a particular architecture into a warehouse (Reposity) for subsequent similar business reuse (Gerneralization for future re-use). In specific applications, reusable components can be selected from the component repository and adapted to the actual application scenario (Adaptation for use).

Solution entity (Solutions Continuum): similar to an architectural entity, you need to be able to select and replicate quickly from reusable solution libraries in different markets. For emerging market delivery, it can also be extracted into reusable solutions to the asset repository.

After years of development, we have a variety of business support tools and games in the domestic markets of Taobao and Tmall, such as electronic vouchers, pre-sale, shopping vouchers, red packets and so on. Can we achieve rapid reuse of business models in the face of international market delivery?

Ideas to solve these problems

The applications involved in the whole e-commerce system are as high as 7000,000: it is necessary to consider whether the assessment of demand has a full-link perspective; whether the technical assessment of business requirements is comprehensive and whether the scope of influence of the technical scheme is in place; the whole link stability guarantee of the service, calling link monitoring, strength dependence and so on. In addition, in the face of hundreds of business requirements every day, 500 + independent release changes: it is necessary to consider whether the requirements release of various business parties will have an impact on each other; whether the requirements code has intruded into the platform, resulting in platform corruption; how to control quality under high-frequency requirements release; whether business monitoring and fault analysis can be carried out according to the business dimension.

In the face of these challenges, there are six key issues that the TMF2.0 framework needs to address:

Business full-link visualization: business analysts and technicians can conduct requirements discussion, impact analysis, and technical solution evaluation in a full-link visual manner based on the same set of business languages. the rules seen in the business view are the rules actually running on the running system. In the scenario of supporting large-scale business delivery, business visualization is very necessary to improve efficiency.

Structural requirements: based on the revealed business capabilities, existing business rules to complete the structural decomposition of requirements to reduce communication costs.

Business configuration: this is the premise of visualization. Business should be configured online and released online when the requirements are clear.

Integration of business testing: automatic use case screening and automated testing according to the modified code.

Business monitoring: monitor with a refined business dimension, not just limited to the trading market.

Troubleshooting: quickly get the fault snapshot, restore the fault site and quickly locate the cause of the problem when there is a business failure.

Key Design ideas of TMF2.0

In response to the problems mentioned above, the main ideas of TMF2 in architectural design are:

Plug-in architecture in which the business package is separated from the platform: the platform provides a plug-in package registration mechanism to realize the business plug-in package registration at run time. The business code is only allowed to exist in the plug-in package and is strictly separated from the platform code. The code configuration library of the business package is also separated from the code base of the platform and is provided to the container for loading by the way of two-party package.

Full-link unified business identity: the platform needs to have the ability to logically isolate business and business according to "business identity", rather than the traditional SPI architecture without distinguishing business identity and simple filtering. How to design this business identity has also become the key to the isolation architecture between businesses.

Separation of administrative domain and running domain: business logic cannot be calculated dynamically at run time, but can be defined and visualized during the static period. The rule superimposed conflicts in the business definition also make conflict decisions in the static machine. During the run time, it is executed strictly in accordance with the business rules and conflict decision policies defined by the stator.

Plug-in Architecture based on the Separation of Business package and platform

The business customization package and platform separation architecture shown above can be divided into three levels. The bottom layer is the business specification layer, including some transaction models, the division of transaction domain, the division of business domain, and the configuration items in the transaction startup environment. Based on this theoretical model, some definition and specification work can be carried out, such as interface definition, process specification, model specification and so on, and many of them can be reused in different fields.

Above the business specification layer is the solution layer. We all know that Alibaba is currently following the strategy of internationalization, so different solutions will be built in different markets, and different solutions will have their own different business games and business logic. So combine different market solutions with their own processes and rules. But in the process, you will find that there are many reusable places for different market solutions, such as marketing models. Therefore, the formed reusable basic implementation can be reused in different solutions, so in the face of different markets, there is no need to consider the content of the reusable basic implementation, just pay attention to the market-related business.

The next layer is the business customization layer. Even in a market, there will be a variety of customization methods, these different details will have different business logic, which is the reason for the development of business customization layer. The team will assemble some business customization packages according to the underlying demand points, so that different business logic and play can be implemented.

In such a complex separation architecture, the most important thing is to clearly divide the responsibilities between different levels, and the whole code is strictly and consciously separated. Therefore, in the final deployment process, we should first complete the reuse of the underlying business, and then form solutions in different markets, and then achieve differentiation points for different businesses under the solution.

Full-link unified business identity

What is mentioned above is the separation of the business and the platform. After the separation of the business and the platform, it is necessary to separate the business and the business, that is, a unified business identity, which is similar to the ID card number, and must be unique in the whole transaction chain. Business identity needs to be abstracted through three dimensions: people, goods and market, such as market type, vertical market, channel source and so on. After this unique business identity is determined, business processes and business rules can be associated.

Based on business identification, the team also provides a UIL-based business identification scheme, the overall design is based on the standard model to abstract, custom syntax, unified management model. In fact, 99% of the goods can be effectively identified through the four dimensions of sample model, buyer model, seller model and category model. After the business identity is determined, the business configuration and deployment can be managed uniformly according to the business identity dimension, in which we should pay attention to the core elements such as configuration isolation, hot deployment, configuration rollback, configuration certainty and so on.

Business management domain is separated from running domain

After the business identity is determined, it is necessary to define the business, which involves the separation of the management domain and the running domain. Management domain refers to the definition of business life cycle, business identity, business objects, including business processes, business management and so on. After these operations are completed, the configuration file will be sent to, and the various platforms on the running domain will automatically parse the configuration file issued by the configuration domain, and then parse the configuration file into business commands for execution.

In the business domain mentioned above, a core problem is how to define business: the core three elements are business identity, business superposition relationship, and conflict decision-making, that is, business is defined based on business protocol standards, and the execution unit executes business logic according to the protocol.

In the business overlay relationship, the complexity of the business lies in the conflicts of business rules in different dimensions. The complexity of business can be divided into two dimensions, one is horizontal dimension, the other is vertical dimension.

Vertical dimension, also known as "industry". Often a specific "business object" (such as a commodity) can confirm which industry it belongs to during the static period. There is no superposition of business rules between industries. For example, the payment timeout period can be set to 1 day timeout. However, Tmall Automobile has changed the timeout, and it will certainly not change the timeout setting of other businesses. Horizontal dimension, also known as product dimension, has the following characteristics: products can be used by multiple vertical businesses, a vertical business can use multiple products, and whether the product is effective or not needs to be combined with business sessions. For example, whether the "electronic voucher" is effective depends on whether the user has chosen the delivery method of the "electronic voucher".

Through the analysis of business complexity, we can draw a conclusion: the complete rules of a business session = 1 vertical business rule set + N horizontal business rule sets. Therefore, when doing business definition and management, we are specifically managing which horizontal business is superimposed with a certain vertical business. How are the business conflicts caused by superposition resolved? Business management should be based on this point. This is the key point.

Introduction of key models of TMF2.0

The following is a detailed description of the key model of TMF 2.0, including the main line of business configuration and the main line of business operation.

In the main line of business configuration, the business PD of the project looks at which business domains are involved in the current business, what functions and products can be used under these business domains, and which business points can be expanded. This needs the support of the capability domain model, through the structured data revealed by this model, to study the capabilities of each domain and the variable points of each capability in the platform, so as to set it pertinently. In the configuration model, through the key view template, the template is exposed, and then the configuration data is saved and distributed to the main line of business operation. The service configuration main line and the service running main line interact with each other.

Based on the key model of TMF 2.0, the business definition of the whole trading platform is visual, manageable and configurable. Business definition visualization includes system capability visualization, business process visualization, business rule visualization, product overlay visualization, etc.; business configurable, WYSIWYG business rule configurability, all systems based on TMF2 standards can immediately acquire business configurability without additional development Configuration versioning, there is a perfect versioning management mechanism for business configuration, configuration push can quickly take effect or fallback by version; business multi-tenant management, different business systems can be completely isolated by tenants. Different tenants have their own data space and configure push policies.

Operation and maintenance oriented to Business Dimension & Stability guarantee

When the business is separated from the platform and has the identification of business identity, we can guarantee the reliability from the business dimension, which mainly include: 1) fault monitoring by business dimension; 2) cluster deployment by business dimension; 3) stability guarantee by business dimension, etc.

1) Fault monitoring by business dimension

In the past, when business identification was not achieved, the daily monitoring of the trading market is still relatively extensive, and we can only monitor the trend of trading volume as a whole. Some businesses, especially new small ones, have very small early trading volumes. Even if the malfunctioning trade falls to zero, it is impossible to monitor it from the trading market, and it is not until the customer complains that there is a fault.

Based on the business system built on TMF2, because of the "business identity" mark, we can mark the business identity throughout the interface call link and write it to the log. And in all kinds of monitoring market, it can be displayed in groups according to the business dimension.

2) Cluster deployment by business dimension

In the past, all transactions on Taobao and Tmall were issued and fulfilled through the same set of BUY and TP. When a business has new requirements or troubleshooting and other reasons, to upgrade deployment, it is inevitable that all machines will be upgraded and deployed in batches. Each upgrade release is a change behavior, as long as there is a change, a new failure may occur.

A business system based on TMF2 because of the identification of "business identity". We can do pre-routing according to the business identity. Assign different clusters to different business identities, and deploy services separately by cluster. From the physical isolation, under the demand of rapid iterative release of some businesses, it can also ensure the stability of the business.

3) guarantee the stability according to the business dimension

In the past, in the absence of business identity identification, when doing performance optimization and promotion guarantee, it was impossible to use different QoS strategies to ensure differentiation according to the business dimension. For example, traffic can not be allocated according to the business dimension to limit traffic, and performance baselines can not be established and performance degradation can be monitored according to the business dimension. The Libra project currently being done by the business platform is different from the simple monitoring of physical indicators in the past, which is that it can carry out scene monitoring according to the business. For example:

The performance baselines of each business under various call scenarios can be established according to the business dimension, such as RT, QPS, etc. Once there is a significant difference between a release and the preset baseline, the business with degraded performance can be quickly found and improved.

The strong and weak dependencies of external service invocation can be established according to the business dimension, and various plan switches of the global and business dimensions can be established by combining the strong and weak dependencies.

You can build a global call link monitoring disk based on the global or business dimension.

Effect of transformation of trading platform

The average development cycle of business requirements is shortened to 12 days: for example, in automobile 4S service, it takes one month (uncompleted) on the old system and 7 days to complete the new system; in Wudaokou business, the workload is evaluated in two months in the old system and 12 working days in the new system; in ele.me business, the evaluation of the old system takes two weeks and is completed in 2 days based on the new system.

Decoupling the platform from the business: the business customization of the completed business only exists in the business package; when the platform remains unchanged, the release of the business side is more flexible (there are multiple single business releases, there is no need for other business parties to return to the case).

Business asset database: 50 + business asset database has been accumulated, and new business can be quickly copied, adjusted and released.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.