Evolution of large-scale website system architecture (i)

Objective

The purpose of writing this article is to help you think and clarify the idea, and how to evolve from a simple website architecture to a large website architecture, focusing on technical aspects

A simple website

Since I have not done PHP, then take JSP as an example, JSP as the front end of the site, e-commerce website as an example, describe a simple site architecture

Front Jsp+css+js

Back-end Java SSH

Web Container Tomcat

MySQL Database

Developers, 1 artists, one front, one Java

The deployment scenario is:

One server, deploying Tomcat and MySQL

The architecture diagram is as follows:

Application and Database Distributed deployment

Then the site runs for a period of time, began to profit, the user also increased, the data volume of the database is not very large

However, more and more users access, will occupy a large number of server memory and CPU, should be to separate the database and application deployment, the frame composition is as follows

So the site can run for some time.

Solution-coupled development

Then we look at the development of the problem, but the development and operations are often inseparable, because the website business development faster, we must add new features above, otherwise we can not play, more and more functions, developers have become more dependent on each other, the previous development model is, Java programmer from JSP has been written to DAO, all do, then now have 5 Java developed together, each responsible for different functions, such as user module, commodity module, order module, trading module, and so the problem came

1 Java programmers often do some CSS work, and write a lot of JavaScript, we use jquery

2 Not every time to wait until all the modules have been completed development before the launch, many times only need a module to complete the modification, you can go online, and then the code is written in a project, version control becomes quite difficult, and each time the function of one module can affect the function of another module, Cause the project to become very unstable, the project is in operation, this situation will be fatal, unlimited overtime will not help, pain ah.

Solutions 1 (Modular)

This is a scheme that I thought of many years ago, so many functions can not be confused in a project, I mean the Java Web project, at least in the development of the modular, the different functions of the separate, the module through the interface calls, such as the user module, application module, commodity module, Order module, trading module, and so on, different people responsible for the development, then how to communicate between the modules, I was the solution, each back-end module is a JAR package project, when released into the jar package to other module calls, the project is built through MAVEN, so development to deployment is more automated, The basic implementation of modular development, project release has become more stable.

with Maven disadvantages of doing modularity

The idea comes from spring, and they also modularize different functions, and there are many drawbacks to this form:

1 with the passage of time, the various modules are constantly updated, the version has been upgraded, if module a depends on the module b,c

Can be understood as a is the Web front module, b is the user module, C is the order module

Such as:

If B or C changes, then A has 2 options:

1 Do not update B and C, can still be used, bring the consequences will be not get the latest B and C functional support

2 If you select Update, a needs to rejoin the new B or C jar package and perform debugging and testing work.

From the perspective of interface dependence

Because B and C need to look up the database, so B and C's Jar package exposes too much API to a, and no good control, for project a developers, the interface is not clear, almost all public methods can be called, so B and C changes to the upper Class A, the impact is not controllable.

From the perspective of system performance

Since both B and C are to be looked up to the database, in the case of a jar, the memory and CPU resources of all the servers in a project cannot be deployed in a distributed manner.

Solution 2: Modular and distributed deployment

So what should be the solution, preferably a distributed deployment, a and b,c through network communication calls

This brings the benefits

1 A,b,c for distributed deployment

2 B,c provides a clear interface to a call, as long as the interface is unchanged, B and C modify the internal business logic, a does not need to be rebuilt and deployed, to maximize the decoupling, that is, to modify some functions of the system, other modules can be unaffected, or less affected, and the scope of the impact can be controlled.

Http://www.cnblogs.com/tangyanbo/p/4387167.html

Evolution of large-scale website system Architecture (i) (EXT)