Introduction to the

The architecture of microservices has been around for a 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 lightweight interactions such as HTTP.

Services are segmented on a business basis and can be deployed independently through a fully automated deployment mechanism. Despite all the talk about microservices, when to use them and what to look out for when to use them is still a vague concept for many people. This article will discuss some issues related to micro-services with you.

Microservices and unit services

In the initial programming architecture, it is usually a single service. For individual services, all services are in one process. Enterprise applications are typically built from three main parts: the client-side user interface (made up of HTML pages and javascript running in a browser on the user’s machine), the database (a system made up of many tables inserted into a common, often relational, database management), and the server-side application.

The server-side application will process HTTP requests, perform domain logic, retrieve and update data from the database, and select and populate HTML views 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 singleton services, all of the request processing logic runs in a single process, and for structuring and coding specifications, applications are typically divided into classes, functions, namespaces, and so on, using the basic functionality of a programming language.

While a single service can scale horizontally with multiple instances running behind the load balancer, as the server-side business becomes more complex, every small change to the service can lead to the rebuilding and deployment of the entire service. And over time, it’s often difficult to maintain a good modular structure and extend existing architectures. 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 is not good.

As the saying goes, you can’t put all your eggs in one basket.

So breaking up huge individual services into microservices is the current system architecture craze.

Microservices architecture is the breaking down of a single application into services that can be deployed and extended independently, with solid modular boundaries between services, which interact primarily over HTTP. Because there is no internal coupling between services, we can even use different programming languages to implement different services. Improved program flexibility.

Characteristics of microservices

What are some of the characteristics of microservices? What kind of services can be called microservices?

Society is very complicated, simple people. Practical engineering problems are not as well defined as book learning. 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, it clearly tells us what a circle is. For microservices, there is no such definition.

Because micro-service is a kind of architecture that is summarized and groped out in continuous practice. Although different people have different ideas about microservices, they all have the following characteristics in common.

Component servitization

Since software becomes complex, software gradually begins to be componentized for better software development and subsequent extension. Components are parts that can be replaced and upgraded independently.

Modern programs have many things that can be called components, such as dependency jars in Java, dependency packages in Python, and so on.

These LiBs can be linked to programs at run time and run as in-memory functions.

Given the linked lib, why do we need to servize these components to run as separate processes?

One of the main reasons to use 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 result in the entire application having to be redeployed.

However, if the application is decomposed into multiple services, then changes to the service simply require redeployment of the service. Although this is not absolute, some service changes will lead to changes in the corresponding calling interface, so the corresponding service is also needed for modification and adaptation. But the goal of a good microservice architecture is to minimize these changes 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, leading to tight coupling between components. By using the explicit remote invocation mechanism, services can be more easily defined.

The use of services also has its drawbacks. Because services are called remotely, which is more expensive than in-process calls, calls between services are usually coarse-grained, so we need to have clear responsibilities when defining services.

Division of organization

According to Conway’s law: organizational communication determines system design.

Generally speaking, for large systems, there are UI teams, service logic teams, and database teams. But this way of organizing can result in changes made by one team requiring changes made by other teams.

Therefore, in microservices, the organization should be divided into specific businesses to ensure the flexibility of the organization.

Communication between services

For singleton services, dependent libs are implemented through calls to internal functions, which has the advantage of being fast, but if singleton services are converted into microservices, mutual calls between services need to be taken into account.

What are the common ways to invoke services?

The most common method is HTTP/HTTPS. This method has the advantages of simple and universal protocols and low cost of compatibility.

If you are cross-language, you usually use RPC remote call protocols like Thrift, which have the advantage of being faster than HTTP calls, but are more complex to call. Specific clients need to be built.

The above calls are synchronous, but if asynchronous, you can also use MQ, which is used for peak peaking and decoupling.

Decentralized governance

For microservices, it is not required that all microservices adopt the same language and the same architecture. Generally speaking, maintaining system and code maintainability generally requires that all services use the same programming language and architecture.

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

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

Decentralized data management

For individual applications, all data is stored in a single database. If microservices are decentralized, then the corresponding database belongs to each microservice group, so in theory microservice data should also be decentralized deployment.

But the result of such multiple databases is the consistency of data in each database. In a singleton application, this problem can be solved through database transactions. But distributed transactions are not feasible, or too costly, for microservices. For microservices in general, we need to ensure that the data is ultimately consistent.

Data checksum is repaired by compensation mechanism.

Automated deployment

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

Response to an exception

As a result of using services as components, applications need to be designed to tolerate service failures. Any service invocation can fail due to network or other reasons of unavailability, so you must respond to this as gracefully as possible.

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

Because a service can fail at any time, it is important to be able to quickly detect failures and automatically restore services if possible. Microservice applications place great emphasis on real-time monitoring of applications, 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 errors that development teams can follow up on and investigate. Monitoring is critical to quickly detect and fix bad emergent behavior.

We expect to see complex monitoring and logging Settings for each individual service, such as dashboards showing startup/shutdown status and various operational and business related metrics, as well as detailed information on circuit breaker status, current throughput, and latency.

conclusion

So much about the characteristics of micro-services, although micro-services have its advantages of flexibility, but how to divide the boundaries of micro-services and the monitoring of micro-services is a very complex issue, so whether to use micro-services is left to the readers to think.

Finally, I would like to ask you a question. In real projects, many people hope to split the existing individual services into micro-services, but each micro-service still shares the same database, that is to say, there is data crossover among these micro-services. So are these microservices really microservices?

This article is available at www.flydean.com/09-microser…

The most popular interpretation, the most profound dry goods, the most concise tutorial, many tips you didn’t know waiting for you to discover!

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