Recently, I attended some technical conferences in the industry, and the topic of “micro-service architecture” was very hot. I have also talked about the practice of service-oriented architecture in some occasions. This paper is expected to discuss my understanding of service-oriented architecture in an easy-to-understand language, hoping to give us some enlightenment. If there are omissions, you are welcome to add.

 

1. Why servitization of the Highly available Internet Architecture?

High availability architecture before servitization

Before servitization, the highly available architecture of the Internet looked like this:

(1) The client is browser and APP client

(2) The back-end entry is a highly available NGINx cluster used to do reverse proxy

(3) The middle core is the highly available Web-server cluster, and the main coding work of r&d engineers is in this layer

(4) The back-end storage is a db cluster with high availability, and the data is stored in this layer

 

More typically, the Web-Server layer accesses databases through techniques such as DAO/ORM.

 

As you can see, there is no service layer at first. What are the pain points of the architecture?

Architecture Pain point 1: Code copied everywhere

Most companies have a database to store user data. Each business has requirements for accessing user data:

Before there was user service, each line of business had to access user data by writing SQL through DAO to access user library, which led to code copy virtually.

 

[Architecture Pain Point 2: Complexity Diffusion]

With the increasing concurrency, user data access to the database has become a bottleneck, and caching needs to be added to reduce the database read pressure, so caching is introduced into the architecture. Since there is no unified service layer, each line of business needs to pay attention to the complexity caused by the introduction of caching:

For write requests to user data, all lines of business need to update the code:

(1) Eliminate cache first

(2) Write data again

For user data read requests, all lines of business are also updated code:

(1) Read cache first. If a match is hit, return

(2) Read the database

(3) Add the data to the cache

This complexity is typical of “business independent” complexity where the business side is forced to upgrade.

With the increasing amount of data, the database needs to be split horizontally, so the architecture introduces separate database and table. Since there is no unified service layer, each line of business needs to pay attention to the complexity caused by the introduction of separate database and table:

This complexity is also typical of “business independent” complexity where the business side is forced to upgrade.

Including bug modification, a bug is found, multiple places need to be modified.

 

Architecture Pain point 3: Reuse and coupling of libraries

Servitization is not the only solution to the above two pain points. Abstracting out a unified “library” is the easiest solution to think of:

(1) Code copy

(2) Complexity diffusion

Methods. Abstract out a user.so, which is responsible for accessing the entire user data to avoid copying code. As for complexity, user.so is the only place to look.

Solving old problems introduces new ones, versioning of libraries and coupling of code between lines of business:

Business line A upgrades user.so from version 1 to version 2. If the code of business line B is incompatible with that of business line B, the service of B will have problems.

If service line A notifies service line B to upgrade, service line B will perform some upgrades that are irrelevant to its own services for no reason. Of course, this problem does not exist if each line of business copies a copy of the code.

 

[Architecture pain point 4: SQL quality is not guaranteed, business interaction]

The line of business accesses the database through DAO:

If line A writes A full table scan SQL, it will cause cpu100% of the database, affecting not only one line but also one line. All lines of business will be affected.

 

[Architecture Pain Point 5: Crazy DB coupling]

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

Typically, join data tables to implement some business logic for the respective lines of business. In this case, table-user of service line A is coupled with table-a, table-user of service line B is coupled with table-b, and table-user of service line C is coupled with table-c. The result is as follows: Table -user, table-A, table-B, table-C are all coupled together.

As the data volume becomes larger and larger, the ABC database of the line of business cannot be split vertically and must use a large library (crazy, a large library of 300 + business tables =_=).

 

[Architecture Pain Point 6:…]

 

Ii. What problems does servitization solve?

In order to solve the above problems, the “service layer” is introduced during the evolution of the layered architecture of Internet high availability.

As an example of the user service in the above paper, user-service is introduced to access user data used for the response of the line of business. What are the benefits and problems of introducing a service layer?

[Benefit 1: Call fang Shuang]

Before the service layer: The business side needs to assemble SQL to access user data through DAO

After the service layer: the business side accesses user data through RPC as if calling a local function, which is very cool

User = UserService::GetUserById(uid);

Passing in a UID and getting a User entity is just like calling a local function, with no concern for serialization, network transport, back-end execution, network transport, serialization, etc.

 

[Benefit two: reusability, prevent code copy]

All user data is accessed through the user-service. There is only one copy of the code. There is no copy. Upgrade one upgrade, bug fix one change.

 

[Benefit 3: Focus, shielding underlying complexity]

Before there was a service layer, all lines of business needed to focus on the details of caching, repository and tables.

 

With the service layer in place, only the service layer needs to focus on the underlying complexity, shielding details upstream.

 

[Benefit four: SQL quality guaranteed]

Originally, the business directly upstream concatenated SQL to access the database.

 

With the service layer, all the SQL is provided by the service layer, and the line of business can no longer do whatever it wants. If the underlying services are more stable, they can be maintained by more experienced engineers, rather than the SQL that is difficult to close and control.

 

【 Benefit 5: Database decoupling 】

Originally, the databases of each business were mixed in a large database, which joined each other and was difficult to split.

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

 

[Benefit six: provide limited interface, unlimited performance]

Before servitization, the upstream of each line of business can manipulate the database as much as they want. When performance bottlenecks are encountered, each line of business is prone to bickering and buck-passing.

After servitization, the service only provides limited general interface. Theoretically, the service cluster can provide unlimited performance. Performance bottleneck appears, and the service layer is optimized in one place.

 

Recommended reading:

Carefully organize | 2017 in the second half of the article directories

From Neurons to Deep Learning (II)

Concurrent server (ii) : threads

Quicksort (Basic)

Focus on server background technology stack knowledge summary and sharing

Welcome to pay attention to exchanges and common progress

Coder youdao coding

Code agriculture Youdao, to provide you with easy to understand technical articles, so that technology becomes simpler!