Architecture: talk about microservice architecture

Introduction

The microservice architecture has been around for a long, long time. The microservice architecture is a method of transforming a single application into a set of small services. Each small service runs in its own process and uses a lightweight interaction method ( Such as HTTP) to communicate.

The division of services is based on specific businesses and can be deployed independently through a fully automated deployment mechanism. Although everyone is talking about microservices, when should you use microservices and what issues you need to pay attention to when using microservices is still a vague concept for many people. This article will discuss some issues related to microservices with you.

Microservices and monolithic services

In the initial program system, it is usually a single service. For a single service, all services are in one process. Enterprise applications are usually built by three main parts: the client user interface (consisting of HTML pages and javascript running in the browser on the user's machine), the database (consisting of plugged into public, usually relational database management) Many tables make up the system) and server-side applications.

The server-side application will process the HTTP request, execute the domain logic, retrieve and update data from the database, and select and populate the HTML view to be sent to the browser. The server-side application is a whole, that is, a single process. Any changes to the system require rebuilding and deploying the latest version of the server-side application.

For a single service, all the processing request logic runs in a single process. In order to structure and code the standard, the basic functions of the programming language are usually used to divide the application into classes, functions, and namespaces.

Although a single service can also scale the application horizontally by running multiple instances behind the load balancer, as the server-side business becomes more and more complex, every small change to the service will lead to the reconstruction and deployment of the overall service . And over time, it is often difficult to maintain a good modular structure and expand the existing architecture. At the same time, because the single service runs in a process, if the process has runtime problems, all services will be unavailable and the stability will be insufficient.

As the saying goes, eggs cannot be put in a basket.

So splitting huge single services into individual microservices is the current boom in system architecture.

The microservice architecture is to split a single application into individual services. These services can be independently deployed and expanded, and there is a solid module boundary between the services, and the interaction between the services is mainly through the HTTP protocol. Because there is no internal coupling between services, we can even use different programming languages to implement different services. Improve the flexibility of the program.

<img src="https://img-blog.csdnimg.cn/20210602170040451.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_0,text_aHR0cDovL3d3dy5mbHlkZWFuLmNvbQ==,size_25,color_8F8F8F,t_70" style="zoom:50%;" />

Characteristics of microservices

What are the characteristics of microservices? What kind of service can be called a microservice?

The society is very complicated, and it is purely people. Problems in actual engineering will not have a clear definition like the knowledge learned in books. In fact, after leaving school, things in this world are no longer black and white.

For example, the definition of circle we learned when we were in school, it clearly tells us what a circle is. For microservices, there is no such definition.

Because microservices are an architecture that is summarized and explored in continuous practice. Although different people have different understandings of microservices, they should all have the following characteristics in common.

Component servitization

Since the software has become complicated, in order to better carry out software development and subsequent expansion, the software has gradually begun to be componentized. The so-called components are individual components that can be replaced and upgraded independently.

There are many things that can be called components in modern programs, such as dependent jar packages in java and dependent packages in python.

These libs can be linked into the program at runtime and run as functions in memory.

With the linked lib, why do we need to service these components and run them as separate processes?

One of the main reasons for using services as components (rather than libraries) is that services are independently deployable. If your application consists of multiple libraries in a single process, changes to any single component will cause the entire application to have to be redeployed.

However, if the application is decomposed into multiple services, then changes to the service only need to redeploy the service. Although this is not absolute, because some service changes will lead to changes in the corresponding calling interface, the corresponding services are also required to be modified and adapted. But the goal of a good microservice architecture is to minimize these changes through cohesive service boundaries and evolution mechanisms in the service contract.

Another benefit of using services as components is a more explicit component interface. Most languages do not define a good mechanism for explicitly publishing interfaces, which leads to tight coupling between components. By using an explicit remote call mechanism, services can be more easily defined.

The use of services also has its disadvantages, because services are called remotely, and remote calls are more expensive than in-process calls, so calls between services are usually more coarse-grained calls, so when we define services, we need to divide Clear assignment of responsibilities.

Organizational division

According to Conway's Law: The way of organization and communication determines the system design.

Generally speaking, large systems can be divided into UI team, service logic team and database team. However, such an organization will lead to changes in one team that require other teams to also make changes to cooperate.

Therefore, in microservices, the organization should install specific businesses to divide, so as to ensure the flexibility of the organization.

Communication between services

For the monolithic service, the dependent lib is realized through the call of internal functions. Its advantage is that it is fast. However, if the monolithic service is converted into a microservice, the issue of mutual invocation between services needs to be considered.

What are the common ways to call between services?

The most common is the call between HTTP/HTTPS protocols. The advantage of this method is that the protocol is simple and universal, and the cost of compatibility is low.

If it is cross-language, RPC remote call protocol such as Thrift is usually used. The advantage of this method is that it will be faster than HTTP call, but the call is more complicated. Need to build a specific client.

The above is a synchronous call. If it is asynchronous, the MQ mechanism can also be used. One of the functions of MQ is to cut peaks, and the other is to decouple.

Decentralized governance

For microservices, it is not required that all microservices adopt the same language and the same architecture. Generally speaking, the maintainability of the system and code is guaranteed. Generally speaking, all services are required to use the same programming language and architecture.

But for special parts, such as high performance requirements, you can try to consider a different programming language.

In general, each microservice team is responsible for their own services, and only needs to ensure the correctness of external services and interfaces.

Decentralized data management

For a single application, all data is stored in a database. If the microservices are managed in a decentralized manner, then the corresponding databases belong to each microservice group, so in theory, the data of the microservices should also be deployed in a decentralized manner.

But the consequence of such multiple databases is the consistency of the data in each database. In a monolithic application, this problem can be solved by database transactions. But for microservices, distributed transactions are not feasible, or too expensive. Generally speaking, for microservices, we need to ensure the final consistency of the data.

The data is checked and repaired through the compensation mechanism.

Automated deployment

The goal of automated deployment is continuous delivery. For microservices, the automation of multiple services is essential. Through automated compilation, automated testing, automated integration and automated deployment, the tasks of the development team and the operation and maintenance team can be greatly reduced. Improve development efficiency.

Response to exception

As a result of using services as components, applications need to be designed to tolerate service failures. Any service call may be unavailable and fail due to network or other reasons, so it must respond as gracefully as possible to this.

Compared with monolithic services, this requires additional complexity to deal with it, so it can be seen as a shortcoming of microservices. The development team needs to do as many abnormal tests as possible to ensure the correctness of the program in extreme environments.

Since the service may fail at any time, it is very important to be able to quickly detect the failure and automatically restore the service when possible. Microservice applications attach great importance to real-time monitoring of the application, checking architectural elements (how many requests the database receives per second) and business-related indicators (for example, how many orders are received per minute). Semantic monitoring can provide an early warning system for errors, allowing the development team to follow up and investigate. Surveillance is essential to quickly detect bad emergency behavior and fix it.

We would like to see complex monitoring and logging settings for each individual service, such as dashboards showing up/down status and various operational and business-related indicators, as well as detailed information about circuit breaker status, current throughput and latency Wait.

to sum up

Speaking of so many characteristics of microservices, although microservices have the advantage of flexibility, how to divide the boundaries of microservices and monitor the microservices is a very complicated issue, so whether or not to use microservices remains Give the readers their own thinking.

Finally, I would like to ask you a question. In real projects, many people want to split the existing single service into microservices, but each microservice still shares the same database, which means that there is still a lot of money between these microservices. There is data crossover. So is this kind of microservice considered a real microservice?

This article has been included in http://www.flydean.com/09-microservices-guide/

The most popular interpretation, the most profound dry goods, the most concise tutorial, and many tips you don't know are waiting for you to discover!

Welcome to pay attention to my official account: "Program those things", know technology, know you better!