Application of micro-service architecture in large e-commerce
E-commerce is a promotional pull scenario, but also a price war driven scenario. 618 and Double 11 are typical promotions. In fact, are robbing users, expand market share. In such a scene, the second to kill, buying is very keen to play.
What are the system challenges of promotional pull?
As you can see from the figure above, the high availability requirements are very high, requiring 99.99% high availability. Rapid iteration has high requirements on the system tolerance, from tens of thousands of orders to hundreds of thousands of orders or millions of orders. The architecture cannot affect the rapid iteration, so there is the saying of refueling in the air or changing tires on the highway.
In addition, the system needs to be highly scalable (rapid capacity expansion and reduction) to cope with instantaneous massive access (especially in seckilling scenarios). These are requirements for the system.
The architecture of large e-commerce systems
From bottom to top, data layer, buried data Store user behavior data, real-time data in NoSQL, relational database, big data platform.
Infrastructure layer
This layer is actually middleware and services, including MQ messaging, job debugging center, SSO joint login, messaging, distributed file storage, some pictures uploaded by users, etc., in addition to the whole system of application monitoring, automatic publishing framework, support to AB testing.
Basic service layer
The next 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 common services, including OMS, PMS procurement, freight template, distribution area, etc., which are the most commonly used basic services of e-commerce.
Business service layer
What we can see in the business service layer is, for example, the interface that users can see in the front desk, such as shopping cart, order, home page, no matter whether it is micro service, at least it is servitization. This layer is the heart of all web applications. In addition, it is the API docking of third-party platforms.
Virtual categories are like “labels”. For example, our normal categories are called “fresh” and “clothing”, and some virtual categories are called “618 Sale”, which can be interpreted as a label and used as a display.
Exposed to the top layer, we can see that these are the various ends, such as H5, PC and the official website, and this is the final visible end.
Design of microservices architecture
Statelessness of applications
Many sites may not be microservified at first, but in some early projects, we did some individual applications in order to get up and running quickly. With the development of the order quantity, we began to do the so-called “micro-servitization”. The first step is to change the so-called single application into stateless application. From the perspective of SSO login, it is a way to solve the problem of de-statalization. We get a token, and we carry it with us every time we visit, which is called de-statusization. Each of these applications has laterally scalable capabilities. When traffic is high, servers can be added to enhance the ability to scale horizontally.
The application is stateless, but the configuration file is stateful. Such as accessing databases and nodes, this is done through configuration files. The cases I mentioned are basically based on Spring Boot microservization, and related technical frameworks include: Dubbo, ZK, Hystrix, RocketMQ, ElasticSearch, Redis, etc.
Separation of monomer applications
After the stateless application is done, the single application is split. Split has several dimensions, one is from the dimension of the system, the simplest disassembly method is the front and background disassembly. For example, shopping cart, goods, search, home page and so on belong to the front end, and then end to the website operation personnel.
It can also be broken down by functional dimension. 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 architecture reflects the organizational structure, in which the development team is divided into user service development group, price development group, product development group, etc.
It can also be split based on read and write dimensions. Search and mall indexing, for example, are certainly separate services. User registration order payment is a complete business process. These are made up of several microservices.
Service Architecture Building
Heterogeneity of data
Experience and skills in building service architecture in large e-commerce systems. First is the heterogeneity of data. Take the order table as an example. Generally, orders are very large and are divided into tables and libraries according to ID. This method is used to query all orders of users, and it is necessary to retrieve data from each table. Therefore, a table can be heterogeneous according to the user dimension. Data storage is classified into hot data, cold data, and warm data, which have different locations. The data is also aggregated. On some of the order details pages, because there are so many Ajax requests, there are so many requests that you need to do some request merging as well. Backend services also need to be merged.
Taking commodity details page as an example, the data caches of several interfaces are combined in RedIS to obtain aggregated data from REDis, which is called data closed-loop. This is a common practice for optimizing network requests.
The cache
Caching is a common optimization technique in large e-commerce systems. Browser-level caching is set through the response header. It will also use the cache of app client, pack H5/CSS/JS/ images, pull them to the client in advance, make a proxy server on the client, but will not read the data. Can improve the user experience. The use of caching is also commonly used on the network CDN. Once in the access layer, memory level caching can also be used if soft load is used.
The application of message queues
The application of message queues is a good way to decouple services. Also consider the message failure and retry scenario, which requires some additional compensation to prevent data loss. Another mechanism is data checksum compensation. What many scenarios can achieve is ultimate consistency. Large e-commerce systems are very different from financial systems, which is a common way to design distributed systems. In most cases in e-commerce it’s just a matter of achieving final consistency.
Highly available architectural design
High availability architecture design, for e-commerce, in fact, high availability is the most basic requirement. If in the promotion, attracted tens of millions of users, downtime loss is great.
Service degradation, grouping, and fault isolation
For the e-commerce system based on micro-service architecture, the high availability scheme has the following parts. First, service degradation should be supported. To do the downgrade switch, write in the configuration center. For example, in the big promotion, first put the order in the cache, and then fall into the library and other operations. There should also be service grouping and fault isolation. For example, if the application is suspended, services are not affected because services are isolated. As well as limited streaming, many frameworks support it.
Traffic management
In extreme scenarios, traffic management should be carried out at multiple levels. For example, on the day of the promotion, traffic limiting for crawlers and robots will be enabled. Generally, the board is sealed before the promotion. If there is a problem, it is rolled back, such as the rollback of the data version. When setting the data structure, it is necessary to support the rollback with the data version number.
Business design
Business design considerations. You can see the order payment process in the figure. In the design of the time to consider anti-re-design, you can use anti-re-key or anti-re-table scheme, but the cost and cost is very high, will be used in some scenes, such as integral, deduction fee and money related scenes.
Business design takes state machines into account. Especially in order flow state, to do the application of the state machine, including forward and reverse processes, and the results generated.
The architecture of large mobile e-commerce
Dynamic routing
Finally, let’s review the architecture of large mobile e-commerce. Below is the complete architecture of a mobile e-commerce business. From the APP side, mainly do static file cache and intelligent dynamic routing. China’s network environment is very complex, so intelligent dynamic routing needs to be done on the APP side. Can be on some CDN, the dynamic content also do link optimization. There will be some mechanism to detect the network environment, which can be CDN, or domain name, or CAN expose IP.
Buried points and gateways
There is also a very important buried point for APP in mobile e-commerce, which refers to the buried point of the whole link. Every operation of users in app, through network, service layer, middleware, the whole link should be monitored. It is very helpful to quickly locate problems, especially for the optimization of mobile e-commerce performance, the first step is to bury points.
At the network level, there is also gateway access. Such as current limiting, dynamic load. There is not much logic in the gateway and there are different ways to do it. The most complex aspect of a service is its dependency and governance. Optimization of invocation between services is based on business scenarios, such as shopping cart service invocation to price, inventory, promotion, and so on. When the dependent service is not available, such as the price, the dependency is designed to make a cache in the shopping cart service, to call the cache, and finally to verify the final consistency.
Full link monitoring approach, need to do early warning, this is a foundation. Through the data monitoring request, according to the scene to do the early warning scheme.
Welcome Java engineers who have worked for one to five years to join Java architecture development: 697579751
Group provides free Java architecture learning materials (which have high availability, high concurrency, high performance and distributed, Jvm performance tuning, Spring source code, MyBatis, Netty, Redis, Kafka, Mysql, Zookeeper, Tomcat, Docker, Dubbo, multiple knowledge architecture data, such as the Nginx) reasonable use their every minute and second time to learn to improve yourself, don’t use “no time” to hide his ideas on the lazy! While young, hard to fight, to the future of their own account!