Microservices architecture, which has been recognized for the last five years or so, is the future of software architecture. What you need to understand is why you need to servitize. For example, what value does the microservices architecture bring to the enterprise? What’s the downside?

Here is a brief introduction to the microservice architecture, mainly to understand Why: Why service?

I. Understanding of microservice architecture

1.1 Microservices Architecture

The micro service architecture is mainly a “micro”. Amazon has a rough definition: all of the development, testing, operation and maintenance of a microservices application project adds up to about six to eight people, and two pizzas are all it takes to dine.

Counterexample: Instead of an application project consisting of Service classes, publishing as a Service is a microservice. This is too small to understand microservices. A financial factory in Hangzhou, once divided very fine, resulting in huge operation and maintenance test costs. Began to break up, toss…

1.2 Why microservices?

The shift from SOA Architecture to microservice architecture is to understand why microservice architecture is widely mentioned and practiced. What problems does it solve and what value does it bring?

The software of traditional enterprises or many enterprises, mostly more than one set of systems, is the accumulation of various independent large systems. The overall problems are:

  • Expandability of

  • Low reliability

  • Maintenance costs are also high

  • Repeat a lot of wheels

The solutions to these problems are as follows:

  • componentization

  • As a service

Microservice architecture, which disperses components or modules into services, decouples the entire system. The most important thing that microservices architecture emphasizes is that business systems need to be fully componentized and servitized. What is componentization?

Componentization is the breaking up of a large system into independent components based on a particular business or technical dimension of concern. The purpose is to divide and conquer, to be reusable, to reduce coupling. For example, according to the technical dimension: search component, cache component; By service dimension: user center, payment center, etc

Does componentization mean a little middle stage? Alibaba put forward big in Taiwan, small reception; Is the componentization, plug-in, service solution to the extreme. Through the common business or technology sinking of the product line, a variety of technology or business intermediates are formed

(Photo from Cartoon programmer Xiao Grey)

2. Problems before servitization

2.1 The absence of servitization does not mean that it is not distributed or clustered

Distributed means that multiple instances provide the same service. For example, in multiple local bullet stations, multiple machines provide ticket collection services. In many places, such as Beijing and Shanghai, there are multiple computer rooms and multiple ticket fetching services together to form a cluster and a distributed service. So what is servitization?

Servitization, emphasizing “transformation”! The core is communication between different services. Is a service-oriented solution:

  • The service registry

  • Service release

  • The service call

  • Service monitoring

  • Service load balancing

  • , etc.

2.2 No servitization architecture issues

Before servitization, an example would be more graphic:

Assuming that a ticket picking service, ticket buying service and seat changing service all need to verify the user’s identity authenticity, there will be the following problems:

  • Ticket fetch service -> invoke user DB code -> user DB

  • Ticket service -> call user DB code -> user DB

  • Change seat service -> call user DB code -> user DB

The obvious question is:

  • Code duplication: The userDAO code logic for different services to access DB in the same way. And each piece of service code is maintained by a different person.

  • Low maintainability: different people maintain; Maintenance in different places; Every time the DB field is changed or the database is moved, all the services are changed

  • DB access coupling

Of course there is a solution: Lib. Maintain a user-DAo-lib 1.0.0 release package for each business party.

The problem was solved, new problems were introduced, and the lib upgrade was a huge and lengthy problem. For example, Xiao Li is the person who maintains user-DAo-lib and once wrote a hidden bug. User-lib was upgraded to 1.0.1 release, which took about a month and pushed dozens of business parties to complete the upgrade. Then the bug runs for a few days and appears, considering the huge cost of upgrading the fix or rolling back

Based on servitization, problems can be solved perfectly.

3. Benefits of servitization

As shown in figure Post article Service invocation Video services need to call each other through the uppermost level of services. Significant changes in servitization:

  • DB isolation: So that the underlying details of the design can be masked, followed by other storage caches and so on, unaware of the business caller.

  • Communication between services: specific protocols can be RPC/HTTP

Benefits of servitization:

  • Simple invocation: Instead of writing the same access user service code, just invoke a service

  • Code reuse: Unlike lib code reuse, servitization is handled by communication

  • Business isolation

  • Database decoupling

  • , etc.

There is no denying that microservice architecture or servitization brings new problems

1. Small systems and uncomplicated systems do not need microservices architecture. Microservice architecture will bring some complexity, which is a complete set of service governance scheme. 2. Multi-module database, distributed transaction is a challenge

Advantages must have disadvantages, specific scene specific choice

Five, the summary

This summary is not about how, but why. Only by understanding why can we do better. From why servitization? To why microservices architecture is so popular:

  • Microservices have high scalability

  • High reliability of microservices

  • Microservices have low maintenance costs

  • Microservices hardly repeat the wheel

  • Direct invocation of microservices is simple

  • Microservices business isolation

  • Microservice database decoupling

  • , etc.