Why use the idea of business centralization to structure the trading system
The last article has briefly introduced the design concept of the trading business center. This article will elaborate on why the trading system should be constructed with the idea of the trading business center. To understand this, we must look back at how the evolutionary path of a system changes as the size of the business grows.
First, look at how startups/new business systems evolve; Based on the cloud computing based architecture pattern, most of the start-up system architecture diagrams are shown below
For a small business with a single business, this architecture is also the most efficient way: one to two Web systems, several microservice business systems, and one to two front-end systems. Micro service business system will be members, commodities, category, store, trading, inventory, logistics these divided into different modules/bag on one or several systems, the advantage is very obvious, everyone is familiar with all of the code, the code is, development of high efficiency, it has just started in the company, is very grounding gas and the most appropriate architecture.
With the expansion of the company’s business scale and organization, it will evolve iteratively N times based on the above architecture until the system is no longer the bottleneck restricting the development of the company. During this period, the most important architecture upgrade is the vertical separation of system and database, asynchronous message decoupling, distributed transaction mechanism and stability guarantee. For the sake of quick clarification, we will ignore the intermediate evolutionary version and go straight to the central-platform based version.
Before introducing the business model, let’s take a look at the background of the concept of China development model. China development model was first generated in supercell, a famous Finnish game company with 180 employees, which was later acquired by Tencent at a valuation of 10 billion dollars. Its top10 games in the world during its peak period. Five are from Supercell, which is credited with delivering high-quality games quickly. Alibaba borrowed Supercell’s model of “big middle stage, small front stage” to solve the contradiction between the front end business of rapid innovation and the increasingly heavy core systems such as Taobao and Tmall, so as to improve r&d efficiency and cross-team cooperation.
Can further imagine, if the company business development, especially the Internet business model, 10 times the pace of development is also very normal, it will face the business and technical team size bigger, the business will be more and more complex, with trading, for example, the original is simply supported real purchasing scenario (consumers purchase, platform/merchant shipping), With the development of users and business, there will be virtual goods trading, group purchase, group, auction, SEC kill, pre-sale and other transaction business models.
In the beginning, one system simply supports one single business. In the second stage, you can barely survive by supporting three businesses. In the third stage, if you still use the previous architecture and development mode, you will be stuck in the mire.
[if! SupportLists]1. [Endif] The requirements of the services interact with each other. The cost of modifying and testing regression is very high, but unexpected online problems still occur.
[if! SupportLists]2. [Endif] As more and more needs are supported, no one can control the overall situation.
[if! SupportLists]3. [Endif] The parallel development of multiple requirements is a nightmare. The team often works overtime but still cannot meet the business requirements.
Centralization of business is the best choice to solve these problems. The core capabilities and services of the exchange domain are deposited into stable externalized services through sorting and abstraction, and personalized expansion is supported through reserved extension points. Extension point technology development can completely by the business team, trading China research and development will focus on the construction and the stability of the middle, that greatly improve the development efficiency of collaboration, a business can run fast, rely mainly on the front desk, business China technical team, of course, business segregation and China itself need to be stable and efficient evolution.
Understand the general business process of a transaction
This article is about trading, the result is too much in the middle of the business things, now go straight to trading, look at the two business processes of trading.
Transaction order creation process:
Simplified reverse refund process:
Only two business processes are taken for example, while the others are similar. After analyzing and sorting out the transaction business, it is not difficult to find that the business domains involved in the transaction can be classified into the following aspects: price, preference, inventory, order opening, payment, purchase limit, delivery, order, timeout and after-sales.
Trading business architecture
Through the analysis and sorting of transaction business process and business, the basic capability layer can be modeled and abstracted by using the 20/80 principle
Transaction is a combination of many contracts, and basic capability services are the most atomic. It is also necessary to combine these into trading products with business value through process orchestration to unify external output and management, which is the responsibility of the product layer of the trading platform to solve the problem of commonness and difference.
In addition, the transaction system relies on business services such as membership, goods, stores, inventory, discounts, payment and logistics to complete a real transaction. With these services, we can basically determine the business platform composition of the transaction, as follows:
With the big picture of the whole, we’ll go through each part in detail as follows.
Overall design:
Core Business domain model:
The design of domain model, or comply with the principles of DDD, the key to do well is to understand the business and predict the future period of time, plus abstract induction.
Core class diagram:
From the perspective of overall design, the overall class diagram should focus on the business model itself. According to the previous agreement, we first look at the business model of BA layer
This class diagram, which draws only the macro and important business domain classes, will be used to support the other class diagrams, which will be shown in the BA layer. For now, these class diagrams are sufficient to help understand transactions.
PA layer is the service layer open to the outside world. According to the conventional design, there will be A DTO class corresponding to DO. In addition, considering that car purchase is mainly responsible for the functions of the foreground layer, BA layer will not introduce car purchase, but put it into PA layer.
The BUSINESS object class diagram for the PA layer, in addition to the DTO type, also adds a message event object for notifying interested subscribers of business changes in transactions via event messages. One point to note is that the BA layer DO object, the PA layer is fully available.
Core Service design:
The service access layer is more about the design of the restful service of the front and back end interaction. The PA layer of the transaction has essentially done the design of the microservice open to the outside world (using the Dubbo framework). The restful service of the service access layer is almost the process of packaging parameter conversion of the microservice. There is no need to specify restful separately
Service, look directly at the most important services in PA.
Core link timing design:
To illustrate how the core call link of a transaction works through the most common order purchase and payment processes, the following sequence diagram simplifies the handling of abnormal links and artificially reduces the dependency of the business system. The design of core link dependencies is to better evaluate the rationality of dependencies during the design phase and ensure transaction performance, security, and disaster recovery processing requirements. With the core call link-diagram, you can determine at design time which calls can be reduced, which can be processed asynchronously, which can use pre-caching, which need asynchronous retries, which cannot time out, which need to ensure final consistency, which need idemidematism, and so on. In addition, it also provides a reference for downstream systems to better evaluate their own flow and response time.
There are many technical design points in the transaction section, and almost all the classic technical problems encountered by distributed high-concurrency system have appeared. Due to the limitation of space, the following special article will be specially introduced.
Interested in this piece of welcome to exchange technical solutions and product play.
For more articles, visit http://www.apexyun.com/
Public id: Galaxy 1
Contact email: [email protected]
(Please do not reprint without permission)