Internet Architecture [Service-oriented]

Why should the high-availability architecture of the Internet be service-oriented?

[High availability architecture before serviceization] Before serviceization

, the high availability architecture of the Internet is roughly the following architecture:

(1) The client is a browser browser, and the APP client
(2) The backend entrance is a highly available nginx cluster, It is used for reverse proxy
(3) The intermediate core is a highly available web-server cluster, and the main coding work of R&D engineers is at this layer
(4) The back-end storage is a highly available db cluster, and data is stored in this layer

More Typically, the web-server layer accesses the database through technologies such as DAO/ORM.

It can be seen that there is no service layer at first. What pain points will the architecture encounter at this time?

[Architecture Pain Point 1: Code is copied everywhere]

To give an example of the most common business -> access to user data, most companies have a database to store user data, and each business has the need to access user data:

when there are users Before the service, each business line used DAO to write SQL to access the user database to access user data, which invisibly led to the copying of the code.

[Architecture Pain Point 2: Complexity Diffusion]

As the amount of concurrency increases, user data access to the database has become a bottleneck, and a cache needs to be added to reduce the read pressure of the database. Therefore, a cache is introduced into the architecture. Since there is no unified service Layer, each business line needs to pay attention to the complexity caused by the introduction of the cache:

for user data write requests, all business lines must upgrade the code:
(1) first eliminate the cache
(2) write data again
For user data read requests, All business lines also need to upgrade the code:
(1) Read the cache first, and return if it hits
(2) If it misses, read the database
(3) The complexity of putting data into the cache
is a typical "business-independent" complexity, and the business side needs to be forced to upgrade.

As the amount of data increases, the database needs to be split horizontally, so the sub-database and sub-table are introduced into the architecture. Since there is no unified service layer, each business line needs to pay attention to the complexity caused by the introduction of sub-database and sub-table. Sexuality:

This complexity is also a typical "business-independent" complexity, and the business side needs to be forced to upgrade.
Including the modification of bugs, if a bug is found, multiple places need to be modified.

[Architectural Pain Point 3: Reuse and Coupling of Libraries]

Service-oriented is not the only way to solve the above two pain points. Abstracting a unified "library" is the first solution that is easy to think of:
(1) Code copying
(2) Complexity method of
diffusion . Abstract a user.so is responsible for the access of the entire user data, thereby avoiding code copying. As for complexity, there is only one place to pay attention to, user.so.

Solving old problems will introduce new problems. The version maintenance of the library and the code coupling between business lines:
Business line A upgrades user.so from version 1 to version 2. If it is not compatible with the code of business line B, it will This leads to problems in business B;
if business line A informs business line B to upgrade, business line B will do some upgrades that are "unrelated to its own business" for no reason, which is very frustrating. Of course, this problem does not exist if each business line copies a code.

[Architecture Pain Point 4: SQL quality is not guaranteed, and business affects each other]

The business line accesses the database through DAO:

In essence, SQL statements are assembled from various business lines. It is no problem for senior engineers to write high-quality SQL. Engineers with less experience may write some inefficient SQL. If business line A writes a full table scan SQL, resulting in 100% of the database CPU, affects not only one business line, but all business lines will be affected.

[Architecture Pain Point 5: Crazy DB Coupling] The

business line does not access user data, but also accesses its own data in combination with its own business:

Typically, some business logic of their respective business lines is implemented by joining data tables.
In this case, the table-user of business line A is coupled with table-A, the table-user of business line B is coupled with table-B, and the table-user of business line C is coupled with table-C , the result is: table-user, table-A, table-B, table-C are all coupled together.
With the increasing amount of data, the database of the business line ABC cannot be split vertically, and a large database must be used (crazy, a large database has more than 300 business tables =_=).

What problem does service solve?

In order to solve many of the above problems, the "service layer" was introduced in the evolution of the high-availability layered architecture of the Internet.

Taking the user service mentioned above as an example, user-service is introduced to access user data used in the line of service response. What are the benefits of introducing a service layer and what problems does it solve?

[Benefit 1: The caller is cool]
Before there is a service layer: the business side needs to assemble SQL access through DAO to access user data After
there is a service layer: the business side accesses user data through RPC, just like calling a local function, very cool
User = UserService::GetUserById(uid);
Pass in a uid and get a User entity, just like calling a local function, and don't need to care about the complexity of serialization, network transmission, back-end execution, network transmission, and serialization.

[Benefit 2: Reusability, prevent code copying]

This is not described, all user data access is carried out through user-service, there is only one copy of the code, and there is no copy.
One upgrade is upgraded, and one bug is modified.

[Benefit 3: Concentration, shielding the underlying complexity]

Before there is no service layer, all business lines need to pay attention to the details of caching, sub-database and sub-table.


After having the service layer, only the service layer needs to focus on the complexity of the underlying layer, shielding the details from the upstream.

[Benefit 4: SQL quality is guaranteed]

It turns out that the business directly splices SQL to access the database upstream.

With the service layer, all SQL is provided by the service layer, and the business line can no longer do whatever it wants. If the underlying service has better requirements for stability, it can be maintained by more senior engineers, instead of being difficult to close and control like the original SQL.

[Benefit 5: Database decoupling]

It turns out that the databases of each business are mixed in a large library, and they are joined to each other, which is difficult to split.

After serviceization, the underlying database is isolated and can be easily split for expansion.

[Benefit 6: Provide limited interfaces, unlimited performance]

Before service, the upstream of each business line can manipulate the database as they want, but when a performance bottleneck is encountered, each business line is easy to argue and blame each other.
After serviceization, the service only provides limited general interfaces. In theory, the service cluster can provide unlimited performance, and performance bottlenecks occur, and the service layer is optimized in one place.