Overview of Microservice Architecture Blueprint in "JAVA Ecosystem Technology Summary"

First, the definition of microservices

1.1 Definition one

• Microservice is an architectural style that divides a single application into a set of small services, trying to conform to the principle of single responsibility, so that services can cooperate with each other to realize business functions;
• Each service runs in an independent process, virtual machine, container, and server, and a lightweight communication mechanism (HTTP/JSON) is used for cooperation between services;
• Each service is built around its own business capabilities, and can be deployed independently through an automated mechanism without deployment dependencies;
• Each service can be developed using a different technology stack;

1.2 Definition 2

Microservices are a loosely coupled service-oriented architecture based on bounded contexts.

Second, the advantages and disadvantages of microservices

2.1 Advantages

• Business modules are divided, with stronger business boundaries;
• Each microservice can be deployed independently without affecting each other;
• Allow for technological diversity;

2.2 Disadvantages

• Brings the complexity of distributed systems;
• Brings the problem of eventual consistency;
• Brings the complexity of operation and maintenance;
• Brings test complexity;

The applicability of microservices

In what scenarios are microservices suitable? When to use microservices?

3.1 Conway's Law

The organization of the designed microservice system, the resulting architectural design should be equivalent to the communication structure between the organizations.

This sentence means that the structure between the original organizations can best be mapped to the designed microservice system architecture. For example, a system includes functions such as orders, commodities, and users. In reality, it is developed and maintained by three teams A, B, and C. If it is to be split into a microservice architecture, it is best to split it into order services, commodities The three microservices of service and user service correspond to the three realistic group structures of A, B, and C.

3.2 Productivity

Microservices are not suitable for any stage. The best way is to gradually evolve to microservices as the project expands or the team expands. Because the monolithic application will gradually increase the internal friction as the scale expands, resulting in lower productivity. The goal of microservices is to maintain a stable level of productivity as the scale grows.

Productivity comparison of microservices and monoliths:

The inflection point at which the productivity of microservices exceeds the monolith, generally refers to when the size of the team reaches 100 people. Of course, this is not absolute, and the team leader needs to evaluate it according to the situation.

3.3 Architecture Evolution

If you design the microservice architecture at the beginning of the project, you will encounter great difficulties and risks along the way. For example, the division of business module boundaries, unpredictable business or technical complexity will consume more manpower and time, and even lead to project failure.

The suggested way is to evolve from a single unit. We can continue to explore and precipitate business and technical problems in the single phase. With the clearer understanding and the increasing complexity, we can consider gradual splitting. Some services come out and evolve towards a microservice architecture.

Architecture Evolution:

4. Service Layering

In the microservice architecture, services and services are different, and they should also be arranged in a hierarchical manner. Some services that are not related to the business naturally belong to the underlying basic services, and some services that are related to the business belong to the aggregation services that aggregate the basic services.

Service layering:

In the common overall architecture of company microservices, the general architecture performance is as follows:

The overall architecture of microservices:

With all levels of service, the concept and strategy of Zhongtai seems natural.

China-Taiwan strategy:

V. Service registration discovery

Service registration and discovery are the core functions for the operation of the microservice architecture. It does not provide any business functions, but is only used to discover and register services, and to monitor and manage the health status of services. Its core working principle:

• The registration center is responsible for maintaining the address information of all services, including service name, IP address, port, etc.;
• The service provider registers its information in the registry and maintains a heartbeat to indicate that it is always available;
• When the calling service party wants to call a service, it asks the registry for the address of the service, and then initiates the call in a load balancing manner;

Now there are more registration centers, the mainstream ones are Eureka, Consul, Zookeeper, Nacos, etc.

6. Microservice Gateway

The gateway is the only entrance to the entire system exposed to the outside world. It encapsulates all the microservices in the system. From the outside, others only know and can only interact with the system through the gateway. The gateway processes all requests for non-business functions, and then sends the requests to internally designated microservices for business processing. In general, the main functions of the gateway are as follows:

• reverse routing;
• safety certificate;
• Current limiting fuse;
• log monitoring;

Common gateways now include Kong, Zuul, Spring Cloud Gateway, etc.;

Microservice Gateway:

In practical applications, a micro-service architecture system can have multiple gateways to deal with different usage scenarios, such as company intranet gateways, external network gateways, and gateways provided to third-party calls;

Use of multiple gateways:

7. Microservice Configuration Center

In the process of starting and running a microservice, it often needs to read some configuration information, which has the following characteristics:

• Read-only content independent of the program; the configuration should be separated from the program, and the application should only read the configuration, not modify the configuration;
• Accompanying the entire life cycle of the application; the configuration will be read by the program to control its own behavior logic; so the configuration can be changed;
• Has a variety of loading methods; can be loaded into the application through hard coding, configuration files, environment variables, startup parameters, database storage, etc.;
• The configuration content needs to be managed; in different environments, the configuration has different content, so the management of the configuration content is required;

The above characteristics and requirements have given birth to the emergence of the configuration center. Now the mainstream configuration centers include Spring Cloud Config, Nacos, Apollo, etc.;

Configuration Center:

8. Microservice Communication

RPC and REST:

9. Service monitoring

9.1 Monitoring system

Monitoring system:

9.2 Monitoring Architecture

Monitoring Architecture:

9.3 Full Link Monitoring

In the microservice architecture, a call request may run through multiple services, and these services may be developed by different teams using different technologies. If the call fails and needs to be checked, how can the call site be quickly reproduced? Finding out which service and which server the problem lies in becomes a problem that needs to be solved in full-link monitoring.

The basic principles of full link monitoring are as follows:

• Only one TraceID remains unchanged during the whole process of a request;
• Every time a service runs through, the SpanID is different, and a SpanID is marked at the same time;
• Report and display monitoring information according to time series;

Mainstream tools for full-link monitoring include CAT, Zipkin, Pinpoint, Skywalking, etc.;

10. Circuit breaker and flow control

In the microservice architecture system, calls between services are very frequent. Once some services fail or have high latency, it is likely to cause cascading failures. If the client keeps retrying, it will exacerbate the problem. Severity, and eventually lead to the complete collapse of the entire system.

The design and implementation of circuit breakers help prevent cascading failures among multiple services, allowing us to build a fault-tolerant and highly resilient microservice architecture system, providing service fuse and service degradation functions when some services are unavailable, ensuring that The rest of the system can still function normally.

The three states and meanings of circuit breakers are as follows:

• Closed; all calls can now access the current service. When the number of calls or the number of faults exceeds the set threshold, the circuit breaker becomes open;
• Open; no longer call the current service, but return the preset error message;
• Half-open; after opening for a certain period of time, the circuit breaker is switched to the half-open state, and a request is placed to call the current service to test whether the service is normal. If it is normal, it will be turned off; if it is still abnormal, it will be turned on again.

Mainstream common circuit breakers include Hystrix, Sentinel, etc.;

Eleven, DevOps (cloud native architecture series)

DevOps：

Blue-green release:

12. Container Cloud

If container technology is used, then container orchestration, release, and governance become unavoidable topics. The mainstream technologies are as follows:

• Docker, Docker Compose, Docker Swam Here I recommend the articles I wrote before , "Introduction to Docker Compose and Getting Started with Cloud Native Docker" and "Introduction to Cloud Native Docker Swarm Service Orchestration and Getting Started"
• K8s will be gradually launched later
• Mesos will be rolled out gradually

Major container cloud vendors basically use k8s-based container governance solutions, and k8s has become the de facto standard in this field.

The above is my own notes on learning "20 Lectures on the Core of Microservice Architecture" on the Geek Time App . This course can be completed in one day without the details of implementing microservices. Microservice architecture, recommended learning, here is what the teacher said .