Architecture Case丨Suning Tesco: Product Details System Architecture Design

http://blog.csdn.net/xiaoyao880609/article/details/51007465


The commodity details system is a system that displays the basic information, parameters and other details of commodities, and is the entrance to commodity purchases. It is one of the most visited systems in the e-commerce platform. During the Suning.com promotion period, the amount of PV and UV is very large. Such a large amount of visits has high requirements on the concurrent capability of the system. In terms of business, the relationship between it and the surrounding systems is highly coupled. There are many systems that rely on the product details system, such as: promotion system, recommendation system, Dajuhui, and many other marketing systems, as well as master data system, shopping cart, favorites, etc. The high business complexity puts forward more demands on system design requirements.




1. The focus is on data display
2. The page is rich in information, such as: product details, merchant lists, recommendations, rankings, etc.
3. Some data have high timeliness requirements, such as: price, inventory, etc.
4. Businesses rely on many systems
Display
on products It is necessary to design the page to distinguish the displayed content.
Technically it is mainly the decoupling of page cache design, front-end page template and JAVA program.

Data processing All
data comes from other systems. The data is divided into:
basic data. Data used
Aggregated data, data that needs to be processed to be used

Service dependency Decoupling
through MQ, heterogeneous data
Solving the above three problems solves the core problem of this system.

The product details system is divided into three layers: front, middle and rear in design.
1. The front desk is responsible for display, and as the VIEW layer, it does not handle business logic and is responsible for rendering.
2. The middle office is responsible for business logic processing, providing data to the front desk, and also providing services to external systems
3. The background is responsible for master data management, as the data management layer to handle commodity master data, parameters, brands, suppliers, etc., and some contents are open to operations for maintenance, management and exception handling.
Page design:
1. Dynamic and static separation
JavaScript and CSS are placed on the public static server, completely independent subdomains, to prevent the problem of dirty cookies and useless cookies in dynamic domain names, and resolve conflicts between new and old versions of the system through the file version number question.
All pictures are managed by an independent distributed picture system, and the original pictures are subjected to lossless cropping and compression of different specifications.
2. Asynchronous loading and lazy loading Dynamic data such as
product prices, marketing activity information, and inventory are asynchronously loaded
. Non-first-screen data is lazy-loaded to improve the loading time of the first screen, such as reviews, product details, etc.
3. Multi-level caching strategy
a . Browser local cache
Negotiate cache, and control data through Last-modified for some resources with high time-sensitive requirements. Make StatusCode=304
strong cache, JS, CSS and other static resources or some page fragment pseudo-static data can achieve strong cache through Expires, Cache-Control (http1.1 support) settings, and can achieve 200 without forced refresh (from cache)
b. CDN cache
CDN is divided into two lines. There are self-operated CDN and partner CDN. Pictures, static resources and pseudo-static data
are placed on CDNs that are not available.
c. Varnish cache
Varnish is designed for load use The polling method does not use the URL HASH strategy, but uses the space for time strategy, thereby avoiding the problem of hot data and supporting horizontal expansion.
Varnish cache and CDN cache are staggered at the expiration time, so as to avoid too much pressure to fail back to the source at the same time.
d. Precise caching
Precise cache invalidation is used in scenarios where promotional activities are displayed on time. Based on Varnish caching, accurate cache invalidation is achieved by precisely controlling the validity period of the cache to ensure timely switching of promotional activities.
Component logic design:
The purchase button and adding to the shopping cart in the product details system will go through different processes depending on the product. Such as: Dajuhui products, deposit group products, pre-sale products, etc., go through different business processing procedures due to different promotion methods. There are many changes in the promotion model, which may change every month. It is also difficult to achieve true decoupling with the usual interface-oriented programming and the addition of factory methods or the dependency management framework Spring, although doing so already complies with the open-closed principle. We solve this problem nicely with the Observer pattern. Real decoupling between front-end page templates and JAVA applications.

Commodity data unified processing design

Commodity details system commodity master data comes from external systems through MQ messages, such as: commodity basic information, parameters, parameter templates, brands, categories, etc. In our design, we extracted the commonality and divided it into three parts:
accepting MQ messages and persisting them,
parsing the messages through Listener, simplifying
business processing into three actions of add, update, and delete.
Exception components are implemented in the observer mode, which records MQ messages that fail to be processed and Intercept the message and execute it in reverse next time (there will be one or more parameters and brands in an MQ message, so interception is used here).

The decoupling is divided into two parts, the decoupling between the system interaction and the commodity details system components The decoupling of the system and the decoupling of the business process The decoupling between
systems is solved through SOA service governance, but due to the particularity of the business, in the trade-off between service governance and performance and some other factors, we also chose a way to share Redis To solve the decoupling, the decoupling between the components of the

product details system and the decoupling of the business process.
The 1.0 era is quite satisfactory, and the mobile terminal is completely transferred to the PC.
We use the standard deployment method Varnish+Apache+JBoss.

This kind of architecture is not a problem for small and medium systems, but a system with a huge amount of visits such as the product detail system will be a bit difficult. The mobile terminal has higher performance requirements.
In the 2.0 era, PC and mobile services are separated, mobile services are merged, and performance optimization is
performed.
Atomic layer service sharing.
To limit the performance of mobile processor and memory, use the merger of services, and use Nginx+Lua for mobile.
b. Public service A public service is
proposed The public service is used to accept the public asynchronous request service of PC, WAP and APP.
c. Distributed file system The
product details page is under a lot of pressure during the back-to-source process. Because it cannot be downgraded, we propose to put the product details page as a static page in the distributed file system. When the pressure on DB and Redis is too high, directly adjust the In the era of data 3.0 in the distributed file system,

the focus is on optimizing the performance of the mobile terminal, the interface merging is more granular, and the aggregation service layer is added.
Multiple terminals use Nginx+Lua, and Nginx's asynchronous non-blocking event processing mechanism consumes less resources and has high concurrency capabilities.

Use Nginx+Lua as the overall access layer Add a three-layer cache to
the Nginx access layer
Only the aggregated information will call the service layer to reduce dependencies The data of the
service layer is pushed and refreshed by the worker, which is completely isolated from the DB.
Mobile terminal connection multiplexing, link multiplexing, anti-hijacking SDK development, etc.
The front, middle and back layers of the product details system and the design methods of each layer are introduced above, and the evolution of the deployment architecture is also introduced. The following is the
1.0 version of the data flow structure of the product details system:

There are two problems with this structure:
data differences The structure result is not associated with the front-end display, and the data changes cannot be displayed in the front-end in time,
or front-end interface dependency problem has not been solved.
Version 2.0:

The front end is divided into three parts:
basic information components do not need to process messages, aggregated information components (requires combination of messages or calculations to provide services), and real-time data components to deal with external dependencies. After the
data is heterogeneous, it will be in the form of MQ Notify the basic service and refresh the cache. After this structure, the front end has no direct dependence on the data layer.
Back-to-source is the most troublesome problem in caching. As the business complexity of the system increases, it is difficult to control the pressure that various business data brings to a system when back-to-source. If the back-to-source processing is extremely In this case, the DB pressure will rise instantaneously, the DB will be unavailable, or the number of connections will be full, etc., and the "stop-the-world" problem similar to the JVM GC recovery will occur in the past. We changed back-to-source from passively updating cached data to actively pushing cached data to fundamentally solve this problem.
Data changes are pushed and cached to Varnish through the listener

. The original PC, mobile, and TV products, development, and testing are sub-centers and sub-departments. Harmonization. After the merger, the work efficiency will be improved, the product quality will be improved, and small teams will be able to fight.
Display separation refers to the separation of the display side of PC, WAP, APP (IOS, ANDROID), and TV in combination with the company's business characteristics, product characteristics and the guiding ideology of decoupling.
Logic fusion and separation refers to fusion and sharing at the atomic service layer, starting from the principle of single service responsibility, providing independent services at different ends and adding their own characteristics to achieve interface scalability and service isolation. To truly achieve a package deployment and multi-terminal use without affecting each other, and achieve the lowest cost in terms of business scalability and maintainability.
In the physical layer, in order to avoid multi-terminal resource competition and mutual interference, it is independently deployed. Mysql is used for the

product details system database, and the master-slave plus read-write separation structure is adopted. Note: the master and slave are not on the same physical machine, nor in the same group of routers. In the application layer, data with high business requirements on timeliness is operated in the write library, and data with low business requirements on timeliness is operated in the read library. The master-slave structure ensures that when the master library fails, for example, the rock machine automatically switches to the slave library. The read library achieves high availability through LVS for load balancing.
The DalClient component supports the sub-database and sub-table of the database, and supports horizontal expansion.
The application layer logic first obtains business data from Reids, and if it does not exist in Redis, then obtains it from DB. Redis adopts the sharding scheme, each sharding consists of a master and a slave, and then ensures high availability through sentinel. When the master fails, such as network beating, sentinel will automatically switch the slave to the master, and this switch is in milliseconds. The master and the salve are synchronized in two ways, active and passive, to achieve final consistency, which is in line with the BASE theory evolved from the CAP theory.
Learn from the idea of ​​memory generation in JAVA GC to solve the shocking group phenomenon caused by the expiration of Redis cache.