Introduction to the

The architecture of microservices has been around for a long, long time. Microservices architecture is a way to transform a single application into a set of small services, each running in its own process and communicating using a lightweight interaction such as HTTP.

Services are partitioned on a business-specific basis and can be deployed independently through a fully automated deployment mechanism. While there is a lot of talk about microservices, when to use them and what to do with them is still a vague concept for many people. In this article, we will explore some of the issues related to microservices.

Microservices and monolithic services

In the original programming system, it was usually a single service. For a single service, all services are in the same process. Enterprise applications are typically built from three main parts: a client-side user interface (which consists of HTML pages and JavaScript running in a browser on the user’s machine), a database (which consists of a system of many tables plugged into a common, often relational database management), and a server-side application.

The server-side application processes the HTTP request, executes the domain logic, retrieves and updates data from the database, and selects and populates the HTML view to send to the browser. The server-side application is a whole, that is, a single process. Any changes to the system require a rebuild and deployment of the latest version of the server-side application.

For monolithic services, where all processing request logic runs in a single process, it is common to use the basic functionality of a programming language to divide the application into classes, functions, namespaces, and so on for the purposes of structure and coding conventions.

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

As the saying goes, you cannot put your eggs in one basket.

Therefore, splitting the huge single service into a single micro service is the current system architecture craze.

The micro-service architecture is to split a single application into services that can be deployed and extended independently, with strong module boundaries, and interact with each other primarily 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,t ext_aHR0cDovL3d3dy5mbHlkZWFuLmNvbQ==,size_25,color_8F8F8F,t_70″ style=”zoom:50%;” />

Characteristics of microservices

What are the characteristics of microservices? What kind of service is a microservice?

Society is very complicated, simple is the person. Practical engineering problems are not as well defined as what you might learn from a book. In fact, outside of school, things in the world are not black and white.

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

Because micro-services are a kind of architecture that has been summed up and groped through practice. Although different people have different meanings of microservices, they should all have the following characteristics in common.

Component servitization

Since the software becomes complex, in order to better carry on the software development and the subsequent extension, the software gradually begins to componentize. A component is a component that can be replaced and upgraded independently.

There are many things that can be called components in modern programs, such as dependent JARs in Java, dependent packages in Python, and so on.

These libs can be linked into programs at run time to run as in-memory functions.

With a 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 they are independently deployable. If your application consists of multiple libraries in a single process, a change to any single component will cause the entire application to have to be redeployed.

However, if the application is decomposed into multiple services, changes to the service simply require redeployment of the service. Although this is not absolute, because the change of some services will lead to the change of the corresponding calling interface, so the corresponding service is also needed to modify and adapt. But the goal of a good microservice architecture is to minimize these variations through cohesive service boundaries and evolution mechanisms in service contracts.

Another benefit of using services as components is a more explicit component interface. Most languages do not have a good mechanism for defining explicit publishing interfaces, resulting in too tight coupling between components. By using an explicit remote invocation mechanism, services can be more easily defined.

The use of services also has its disadvantages, because services are called remotely, which is more expensive than in-process calls, so calls between services are usually more coarse-grained calls, so we need to define services with clear responsibilities.

Division of organization

According to Conway’s Law: how an organization communicates determines the design of the system.

In general, for large systems, there are UI teams, service logic teams, and database teams. But such an organization would result in changes in one team that would require other teams to make changes.

Therefore, in microservices, organizations should install specific business divisions to ensure organizational flexibility.

Communication between services

For a single service, the dependent lib is implemented by calling internal functions, which has the advantage of fast speed. However, if a single service is converted into a micro-service, the inter-invocation of services needs to be considered.

What are some common ways of invoking services?

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

If it’s cross-language, you usually use an RPC remote call protocol like Thrift, which has the advantage that it’s faster than HTTP calls, but it’s more complicated to call. A specific client needs to be built.

If it is asynchronous, you can also use MQ mechanism. The function of MQ is to clipper peak and decouple it.

Decentralized governance

For microservices, it is not required that all microservices operate in the same language and in the same architectural way. In general, to ensure the maintainability of the system and code, generally all services are required to use the same programming language and architecture.

But for special parts, such as particularly 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 the external services and interfaces.

Decentralized data management

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

But the result of such multiple databases is the consistency of the data in each database. In a single application, this problem can be solved by database transactions. But distributed transactions are not feasible or expensive for microservices. In general, for microservices, we need to ensure the ultimate consistency of the data.

The data is verified and repaired by means of compensation mechanism.

Automated deployment

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

Response to exceptions

As a result of using services as components, applications need to be designed to tolerate service failure. Any service invocation can fail because it is not available for network or other reasons, so you must respond to it as gracefully as possible.

This can be seen as a drawback to microservices because it introduces additional complexity to process compared to monolithic services. The development team needs to do as much exception testing as possible to ensure that the program is correct in extreme environments.

Because the service can fail at any time, it is important to be able to quickly detect the failure and automatically restore the service if possible. Microservice applications place great emphasis on real-time monitoring of the application, examining architectural elements (how many requests the database receives per second) and business-related metrics (such as how many orders are received per minute). Semantic monitoring can provide an early warning system for the development team to follow up and investigate. Monitoring is critical to quickly identifying bad emergency behavior and fixing it.

We would like to see complex monitoring and logging Settings for each individual service, such as dashboards showing the start/shut status and various operational and business related metrics, as well as detailed information about circuit breaker status, current throughput, and latency.

conclusion

After talking about so many characteristics of micro-service, although micro-service has its advantages of flexibility, how to divide the boundary of micro-service and the monitoring of micro-service is a very complex problem, so whether to use micro-service or not is left to readers to think.

Finally, I would like to ask you a question. In real projects, many people hope to split the existing single services into micro services, but each micro service still shares the same database, which means there is data crossover between these micro services. So is this microservice really a 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, many you do not know the tips to wait for you to discover!

Welcome to pay attention to my public number: “procedures those things”, understand technology, more understand you!