E-commerce website Architecture case (2)

The second article of the grid site architecture case series. Mainly explain the website Architecture analysis, website architecture optimization, business split, application cluster architecture, multilevel cache, distributed session.

Five, the website structure analysis

According to the above estimates, there are several questions:

• You need to deploy a large number of servers, peak compute, and possibly deploy 30 Web servers. And these 30 servers, only seconds to kill, activities will be used, there is a lot of waste.
• All applications are deployed on the same server, and the coupling between applications is severe. Vertical slicing and horizontal slicing are required.
• Redundant code for a large number of applications
• Server session synchronization consumes a lot of memory and network bandwidth
• Data requires frequent access to the database, and the database access pressure is enormous.

Large Web sites generally need to do the following architecture optimization (optimization is the architecture design, the general solution from the architecture/code level, tuning is mainly the adjustment of simple parameters, such as JVM tuning, if tuning involves a lot of code transformation, is not tuned, is a refactoring):

• Business Split
• Application cluster deployment (distributed deployment, cluster deployment, and load Balancing)
• Multilevel cache
• Single Sign-on (distributed session)
• DB cluster (read/write separation, sub-database sub-table)
• Service of
• Message Queuing
• Other technologies

VI. website Architecture optimization 6.1 Business split

Vertical segmentation According to business attributes, divided into product subsystem, shopping subsystem, payment subsystem, comment subsystem, customer service subsystem, interface subsystem (docking such as invoicing, SMS and other external systems).

Hierarchical definition according to the business subsystem can be divided into core system and non-core system. Core System: Product subsystem, shopping subsystem, payment subsystem, non-core: Comment Subsystem, customer service subsystem, interface subsystem.

Business splitting: Upgrading to subsystems can be the responsibility of specialized teams and departments, professional people do professional things, solve the problem of coupling and extensibility between modules; Each subsystem is deployed separately to avoid a centralized deployment that causes an app to hang and all apps unavailable.

Level definition function: For traffic bursts, protect critical applications, achieve graceful degradation, and protect critical applications from impact.

After splitting the architecture diagram:

Reference Deployment Scenario 2

(1) If each application is deployed separately

(2) Combined deployment of core and non-core systems

6.2 Application Cluster Deployment (distributed, clustered, load balanced)

Distributed deployment: The application is deployed separately after the business is split, and the application communicates remotely through RPC;

Cluster deployment: High-availability requirements for e-commerce sites, with each application deploying at least two servers for cluster deployment;

Load balancing: Required for high-availability systems, general applications are highly available through load balancing, distributed services are highly available through built-in load balancing, and relational databases are highly available through master-and-standby methods.

Cluster deployment back frame composition:

6.3 Multilevel Cache

Caches are generally divided into two types of local caches and distributed caches, depending on where they are stored. This case uses a level two cache, the design of the cache. The first-level cache is a local cache, and the level two cache is a distributed cache. (There are page caches, fragment caches, and so on, which are finer-grained divisions)

Basic immutable/rule-changing information such as first-level caching, cached data dictionaries, and popular hotspot data, all caches required for level two cache caching. Access level two cached data when a primary cache expires or is not available. If no level two cache is available, the database is accessed.

Cached proportions, typically 1:4, can be considered using caching. (theoretically 1:2).

The following cache expiration policies are available based on business characteristics:

(1) the cache automatically expires;

(2) cache trigger expires;

6.4 Single Sign-on (distributed session)

The system is divided into several subsystems, and after being deployed independently, it will inevitably encounter the problem of Session management. Can use session synchronization, Cookies, distributed session mode. E-commerce websites generally use distributed session implementation.

Further, we can build a perfect single sign-on or account management system according to the distributed session.

Process description

(1) When the user first logs in, the session information (user ID and user information), such as the user ID key, write to the distributed session;

(2) When the user logs in again, obtains the distributed session, whether there is session information, if not, the login page is transferred;

(3) Generally using the cache middleware implementation, it is recommended to use Redis, so it has a persistent function, convenient distributed session downtime, can be loaded from the persistent storage of information;

(4) In the session, you can set the session to maintain the time, such as 15 minutes, after the automatic timeout;

Combined with the cache middleware, the distributed session can be used to simulate session sessions well.

E-commerce website Architecture case (2)