This sharing mainly looks at microservices from the perspective of servitization, mainly to sort out the concept of microservices, without in-depth explanation.

Microservices from the perspective of servitization

In the process of the development of Internet architecture, when the business complexity, data volume and throughput increase sharply, there will be some technical pain points, the following are the most common ones:

Pain point 1: Code copied everywhere

Take the most common business example: access to user data.

Most companies have a database to store user data, and each business has a need to access user data.

Each line of business uses DAO (Data Access Object) to write SQL to Access user database to Access user Data, which leads to code copy virtually.

Once a service layer is abstracted, a uniform copy of the code solves the problem of code reuse. At the same time, the business side accesses user data through RPC as if calling a local function, such as using

__Thu Sep 14 2017 11:39:57 GMT+0800 (CST)____Thu Sep 14 2017 11:39:57 GMT+0800 (CST)__User = UserService::GetUserById(uid);
__Thu Sep 14 2017 11:39:57 GMT+0800 (CST)____Thu Sep 14 2017 11:39:57 GMT+0800 (CST)__Copy the code

Passing in a UID and getting a User entity is just like calling a local function, with no complexity of serialization, back-end execution, network transport, deserialization, etc., convenient and efficient.

Pain point two: proliferation of complexity

This content mainly talks about the following two points:

1. Complexity due to caching

As the number of visits increases, the database becomes a bottleneck, and caching is needed to reduce the pressure of reading and writing the database. Therefore, 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. To eliminate the cache
  2. To write data
  • For user data read requests, all lines of business are also updated code:
  1. Read cache first, return if hit
  2. In death, read the database
  3. The data is then stored in the cache

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

2. Complexity caused by separate databases and tables

With the increasing amount of data, the database needs to be split horizontally, so the architecture introduces separate database and separate table. At this time, because 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 separate table.

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

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

Pain point 3: library reuse and coupling

Servitization is not the only solution to these two pain points. Another approach is to abstract out a unified “library”. Such as abstracting a user.so, which is responsible for accessing the entire user data to avoid copying code. As for complexity, user.so is now the only place to focus.

But this introduces a new problem: the versioning of the library and the coupling of the code between the lines of business.

For example, if line A updates User. so from version 1 to version 2, if it is incompatible with line B’s code, it will cause problems for B’s business. If Line A notifies Line B of an upgrade, then Line B will upgrade, but this is an upgrade unrelated to its own business.

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

In essence, SQL statements are pieced together from each line of business. Experienced engineers can write high-quality SQL with no problem, while less experienced engineers may write some inefficient SQL. The line of business accesses the database through the DAO. If line A writes A SQL for A full table scan, causing 100 percent of the CPU in the database, it affects not only this line of business, but all lines of business.

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.

Pain point 5: Crazy DB coupling

The line of business not only accesses the User database, but also accesses its own database in conjunction with its own business.

Typically, join data tables to implement some business logic for their 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 final result is as follows: Table -user, table-A, table-B, table-C are all coupled together.

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

As mentioned above, the service layer is abstracted from this situation. In a nutshell, it is used to unify a piece of data access or sub-business logic. This refers to servitization.

From this perspective, microservice essentially refers to the implementation of fine-grained servitization.

Specific delivery to 58 home /58 speed

As mentioned above, with more and more complex business, more and more data and more and more concurrency, 58 went through these stages, so the system architecture took the road of micro services.

Specifically, in 2015, 58 Home’s architecture encountered similar problems:

  • Vertical business expansion, housekeeping, beauty, fast transport, platform, some similar business code copy more and more serious

  • As the amount of data and concurrency increases and the complexity of the underlying architecture spreads upstream, all callers need to pay attention to caching, branch libraries, and storage engines, reducing the efficiency

  • Jar package coupling. Multiple systems depend on a common JAR package. A service upgrade causes compatibility problems, affecting other services

  • Database coupling, multiple services share a database, mutual coupling, mutual influence

  • The SQL quality is low and services are coupled. If one service writes a low-quality SQL, other services are affected

We didn’t start with the microservices architecture directly, but it evolved through different stages.

To put it simply, when we first started, we identified common pain points, abstracted out common data access and sub-services, and then sank them into microservices.

To be more specific, early 58home abstracted the user center, order center, payment center and so on to build microservices.

From the point of view of 58 express, it is a unified stage at the beginning, that is, when the system does not carry out business separation, because the business volume is also small at the beginning, so it is still feasible.

Later the whole system split into site, database, cache these three parts.

Then we carried out a vertical split, the platform, home economics, beauty, fast transport these business split.

Then, it will carry out servitization architecture in terms of express transportation.

More recently, we’ve been evolving an architecture, and we know that the express segment actually has multiple business forms, some for little C, some for little B. Small C is moving service, small B is the goods of the service, big B is the best service. These three pieces they were all coupled together, and now they’re being broken up.

This is what happens when the architecture evolves, and when we talk about it more specifically, we are actually doing some microservices architecture things.

This is all about vertical separation of businesses. Let’s look at our system layering.

Our current system is divided into four layers, as follows:

  • Layer 1: site platform

  • Layer 2: business service layer. It pulls things up that are common to the underlying data, as mentioned above, for example, it addresses the pain point of copying code, it can’t be copied over and over again, so it abstracts the code as a service. To solve the coupling of the library, if there is no servization before, may use code library, jar package, DLL, SO library to solve the problem of code copy, a library, multiple services depend on, the library version upgrade, the influence range is very large, multiple services may be coupled together because of the reason of a library. This is what happens at this layer, which addresses the underlying complexity masking problem. If there is no service layer, then the whole thing is involved.

  • Layer 3: basic data service layer. Contains no complex business logic, just a proxy for data access, CRUD to the database layer. The original design was a relatively simple “DAO layer.”

  • The fourth layer: data layer. The data layer includes caching and DB.

Initially there was no business services layer, with business applications accessing the database directly, leading to a lot of coupling; When the architecture evolved to the second stage, we abstracted some general business independent basic services, such as geographic location service, latitude and longitude service, short url service, SMS service, etc. In the third phase, we abstracted some common business services, such as Passport service, order center service, payment center service, etc. In the future, we will further abstract more generic business services. In short, the idea of the evolution of the entire microservice architecture is: “common + universal pain point” abstraction sinking.

Issues that need attention

Many architects see only the benefits of microservices, but microservices can add complexity to system operations and maintenance, add complexity to configuration files, and make it harder to track down problems and monitor systems. In order to solve these problems, it is necessary to have the support of supporting technical system, for example, the introduction of automatic on-line platform to solve the problem of operation and maintenance complexity, the introduction of configuration center to solve the problem of configuration coupling, the introduction of monitoring platform and call chain platform to solve the problem of monitoring and problem tracing. Microservices require a set of technical infrastructures, not just a simple service framework, which is often much more complex than the service framework itself.

Microservice system supporting infrastructure includes, but is not limited to, the following:

  • Configuration center to decouple systems logically (but physically keep upstream and downstream connections) from configuration file coupling

  • Message center, decoupled from call relationships between systems, decoupled logically and physically (physically no longer connected)

  • Monitoring center, three-dimensional monitoring, implementation of machine, process, interface, log, user level multidimensional monitoring, early detection of problems

  • Call chain tracking system, graphical, quantitative display request in the system call path, early positioning problems

An important principle

As mentioned above, capturing the “commonality” and “common pain points” is one of the most common principles in the implementation of microservices architectures. Here is a brief summary with 58 home as an example. Housekeeping, beauty, express each business has its own account system, order system, payment system, so the cost is obviously higher, complexity cost will continue to increase. For such generic services, the passport service should be abstracted to solve the Single sign-on (SSO) problem. Abstract order center service to solve the problem of centralized storage and display of orders; Abstract the payment center service to solve the unified docking of wechat and Alipay, unified settlement of accounts reconciliation and other problems.

remarks

It is more important to focus on the business than on architecture, and any architecture design that deviates from the business is a fraud. Finding and addressing pain points is more important than thinking big. Architecture is an evolution, not a design. A few personal shallow view, mutual encouragement.

Thanks to Xu Chuan for correcting this article.

To contribute or translate InfoQ Chinese, please email [email protected]. You are also welcome to follow us on Sina Weibo (@InfoQ, @Ding Xiaoyun) and wechat (wechat id: InfoQChina).