background

The microservice architecture is already the preferred architecture method for large and complex systems. The following takes the application scenario of a large e-commerce system as an example to introduce the architecture practice of microservices in large and complex systems.

content

E-commerce architecture practice

E-commerce is a promotion-driven scenario, as well as a price war-driven scenario. Every year, 618 and Double 11 are typical promotional activities. In fact, they are all grabbing users and increasing market share. In such a scenario, flash sales and snap-ups are very popular ways to play.

What is the challenge of the promotional pull to the system?

You can see from the picture above:

The requirements for high availability are very high, requiring 99.99% high availability. Rapid iteration requires high system capacity. From tens of thousands of orders to hundreds of thousands or millions of orders, the architecture cannot affect the rapid iteration, so there is talk of refueling in the air or changing tires on the highway.
In addition, in order to cope with the instantaneous massive access (especially the flash sale scenario), the system needs to be highly scalable (rapid expansion and contraction), these are the requirements for the system.

Architecture of large e-commerce system

From bottom to top, the data layer, buried point data stores user behavior data and real-time data in NoSQL, relational database, and big data platforms.

Large-scale e-commerce system technical architecture

1. Infrastructure layer

This layer is actually middleware and services, including MQ messages, JOB debugging center, SSO joint login, message sending, distributed file storage, some pictures uploaded by users, etc. In addition, there are The entire system of application monitoring and the framework of automatic release support AB testing.

2. Basic service layer

The upper layer is the basic service layer, which actually uses the components and services provided by the infrastructure layer, plus some business logic, to build some public services, including OMS, PMS procurement, freight templates, delivery areas, etc. These These are the most commonly used basic services for e-commerce.

3. Business service layer

What we can see in the business service layer is, for example, the interfaces that users can see at the front desk, such as shopping carts, orders, and home pages, whether they are microservices or not, at least they are service-oriented. This layer is the heart of any web application. In addition, it is the API docking of the third-party platform.

4. Other

Virtual categories are equivalent to "labels". For example, our normal categories are called "Fresh Food" and "Clothing", and some virtual categories are called "618 Sale", which will aggregate a lot of products, which can be understood as a label , for display purposes.

We can see that exposed at the top, these are the various terminals, such as H5, PC, official website, and this is the final visible terminal.

Microservice architecture design

1. Stateless application

Many websites may not be microservice-oriented at the beginning. In some early projects, we will make some monolithic applications for fast online delivery. With the development of the order volume, we began to do the so-called "micro-service". The first step is to turn the so-called single application into a stateless application. From the perspective of login SSO, it is a solution to de-state method of transformation. We will get a Token, and each visit will bring the Token, which is the so-called de-statement. After that, each application has the ability to scale horizontally. When there is a large amount of visits, the ability to scale horizontally can be enhanced by adding servers.

This kind of application is stateless, but the configuration file is still stateful. For example, the databases and nodes to be accessed are done through configuration files (the configuration can be centrally managed through nacos). The cases I mentioned are basically based on Spring Boot for micro-services. Related technical frameworks include: Dubbo, ZK, Hystrix, RocketMQ, Elasticsearch, Redis, etc.

2. Splitting of single application

After making the application stateless, it is the splitting of the single application. The split has several dimensions:

One is from the dimension of the system, the easiest way to disassemble is to disassemble the front and back ends, such as shopping carts, products, search, home pages, etc. belong to the front end, while the back end is used by website operators.
It can also be split according to the dimension of function. For user services, from the Service layer to the table structure, they can actually be deployed independently. This is the concept of microservices. The technical structure reflects the organizational structure. Under this structure, the development team is divided into user service development group, price development group, product development group, etc.
It can also be split according to the read and write dimensions. For example, the index of search and mall must be two independent services. User registration and order payment is a complete business process. These are composed of several microservices.

Service architecture construction

1. Data heterogeneity

The experience and skills in building service architecture in large-scale e-commerce systems are first of all heterogeneous data. Take the order table as an example. Generally, orders are very large, and the tables and databases are generally divided according to ID. In this method, when querying all orders of users, it is necessary to retrieve data from each table, so a table can be heterogeneous according to the user dimension. For data storage, it is divided into hot data, cold data, and warm data, which exist in different places. Data is also aggregated. On some order details pages, because there are many AJAX requests, due to the large number of requests, some request merging is also required. The background service also needs to be merged.

Taking the product details page as an example, the data cache of several interfaces is merged in Redis, and the aggregated data is obtained from Redis, which is called data closed loop. This is a common practice for optimizing network requests.

2. Cache

Caching is a commonly used optimization technique in large-scale e-commerce systems. Browser-level caching is set through response headers. It will also use the cache of the App client to package H5/CSS/JS/ images, pull them to the client in advance, and act as a proxy server on the client, but it will not read data, which can improve user experience. The use of caching is also commonly used on the Internet with CDN. After entering the access layer, if you use soft load, you can also use memory-level cache.

3. Application of message queue

The application of message queue is a good way to do service decoupling. Also consider message failure and retry scenarios, some additional compensation needs to be done to prevent data loss. Another mechanism is data checksum compensation. What can be achieved in many scenarios is eventual consistency. Large-scale e-commerce systems and financial system scenarios are very different. This is a common way when designing distributed systems. In most cases in e-commerce, as long as the final consistency is achieved.

Highly available architecture design

High availability architecture design, for e-commerce, in fact, high availability is the most basic requirement. If tens of millions of users are attracted during the promotion, downtime will cause great losses.

1. Degradation of services, grouping and isolation of faults

For e-commerce systems based on microservice architecture, the high-availability solution has the following parts:

The downgrade of the service must be supported first. The switch to be downgraded is usually written in the configuration center. For example, during a big promotion, put the order in the cache first, and then perform operations such as storage.
At the same time, there must be service grouping and fault isolation. For example, during a seckill, the application of the seckill is deployed separately. When the application of the seckill is suspended, other services will not be affected because of the isolation of services.
At the same time, a limited flow mechanism is required, which is supported by many frameworks.

2. Traffic management

In extreme scenarios, traffic management must be carried out at multiple levels. For example, on the day of the promotion, the traffic of crawlers and robots will be limited. Generally, the board will be closed before the big promotion. If there is a problem, it will be rolled back, such as the rollback of the data version. When setting the data structure, it must support the rollback with the data version number.

business design

Thinking about business design. From the figure, you can see the order payment process. When designing, it is necessary to consider the anti-heavy design. You can use the anti-heavy key or anti-heavy table solution, but the cost and cost are high, and it will be used in some scenarios, such as points, deduction and other money-related scenarios.

Business design should consider the state machine. Especially in the flow state of the order, the application of the state machine must be done, including the forward and reverse processes, and the results produced.

Architecture of large mobile e-commerce

1. Dynamic Routing

The figure below is a complete architecture of mobile e-commerce. From the App side, the main thing is to cache static files and intelligent dynamic routing. China's network environment is very complex, and intelligent dynamic routing needs to be done on the App side. You can go to some CDNs and do link optimization for dynamic content. There will be some mechanisms to detect the network environment, which can be CDN, or domain name, or IP can be exposed.

The overall structure of the e-commerce APP system

2. Buried points and gateways

For Apps in mobile e-commerce, there is another very important point is the buried point, which refers to the full link buried point. From every operation of the user in the App, this operation passes through the network, service layer, and middleware, and the entire link must be able to be monitored. It is very helpful for quick positioning problems, especially for the optimization of mobile e-commerce performance, the first step is to bury the point.

At the network layer, there is also gateway access. Such as current limiting, dynamic load. There is not much logic added to the gateway, and there are different approaches. For services, the most complicated thing is service dependencies and governance. The optimization of calls between services should be based on business scenarios, such as shopping cart services, calls to prices, inventory, promotions, etc. When the dependent service is unavailable, such as the price is unavailable, when designing the dependency, a cache should be made in the shopping cart service to call the cache, and finally verify the final consistency.

The practice of full-link monitoring requires early warning, which is a foundation. After the data monitoring request comes in, an early warning plan is made according to the scene.

at last:

The above is the application of microservices in large-scale e-commerce systems. Many knowledge points and architectural usages have not been explained one by one. Interested readers can delve into the thinking logic behind these usages.