Recently the message asked “micro service” a lot of friends, looking for historical articles and can not find, so re-optimize the release, I hope you have a harvest, do not be misled by the “micro service tide”.

The topic of “micro-service architecture” is very hot. Many friends are asking me how to do servitization. Before answering the “how,” you need to understand the “why.”

Voice-over: Do technology must not be this way of thinking, “others are doing, so we have to do”.

Not all businesses are suitable for “servitization”. Why servitization in Internet high availability architecture?

What was the high availability architecture like before servitization?

Before servitization, the typical high availability architecture of the Internet was as follows:

(1)The client, APP, H5, applets, PC browser;

(2) back-end entry, highly available reverse proxy Nginx cluster;

(3) Site application, highly available Web-server cluster;

(4) Back-end storage, high availability DB cluster;

 

More typically, a Web-server cluster accesses a database through techniques such as DAO/ORM.

 

As you can see, initially there is no service layer. What are the typical pain points that the architecture encounters at this point?

Architecture pain point 1: Code copied everywhere

The most common service example is user data access. Most companies have a database to store user data, and each service needs to access 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 proliferation

With the increasing concurrency, users’ data access to the database becomes a bottleneck, and caching is needed to reduce the database read pressure. Therefore, caching is introduced into the architecture. If 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, all lines of business update code:

(1) First eliminate cache;

(2) write db again;

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

(1) Read the cache first.

(2) Read DB when there is no life;

(3) Put the data into 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 the division of database and table. If there is no unified service layer, each line of business needs to pay attention to the complexity caused by the introduction of the division of database and table.

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

Typically, coupling also includes bug changes, and when a bug is found, multiple changes need to be made.

 

Architectural pain point 3: reuse and coupling of libraries

Servitization is not the only solution to the above two pain points. Abstracting 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.

 

Resolving old problems introduces new ones, and versioning of libraries leads to coupling 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.

Voice-over: Sometimes it’s good to copy code.

 

Architecture pain point 4: SQL quality is not guaranteed, and services affect each other

The business line accesses the database through DAO. In essence, THE SQL statements are assembled by the business line. Experienced engineers write high-quality SQL, while less experienced engineers may write some inefficient SQL.

If line A writes A full table scan SQL that causes 100 percent of the CPU in the database, not just one line of business will be affected, but all lines of business will be affected.

Voice-over: Temp programmers are on the hook.

 

Architecture pain point 5: Crazy DB coupling

Lines of business not only access user data, but also access their own data in conjunction with their own business.

Voice-over: the user_biz table also uses the UID primary key.

Typically, join data tables to implement some business logic for the respective lines of business.

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. 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:…

 

What is the high availability architecture after servitization?

In the evolution of the layered architecture of Internet high availability, a “service layer” is introduced.

The user service in the above paper is used as an example to introduce high availability user-service to access user data used for line of business responses.

What are the benefits of introducing a service layer, and what are the problems solved?

Benefit one: call fang Shuang

Before the service layer, the business side needed to assemble SQL through DAO to access user data.

With the service layer in place, 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, prevents code copy

All user data is accessed through user-service. There is only one copy of the code.

Upgrade one upgrade, bug fix one change.

 

Benefit three: Focus, masking the 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 4: SQL quality is 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.

 

Benefits six: provides 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.

 

Benefit seven:…

Servitization does not solve all problems, and the architecture does not necessarily need servitization if it does not encounter these problems.

Any architectural design that deviates from the business is a hooligan.

I hope you’ve had some fun.

The Architect’s Path – Share practical technical articles

Recommended reading:

Summary of Recent Good Articles