Introduction of micro services, one article will take you to check the technical points in “micro services”

With the rapid development of the Internet, more and more companies begin to shift from individual architecture to micro-service architecture. Therefore, the learning of micro-service needs to be mastered by us strivers. Before learning micro-service, it is necessary for us to take stock of what the so-called micro-service is, what it contains and what kind of business scenarios it solves.

This article is the introduction before learning micro-service, and a series of articles will be written for the knowledge points of micro-service architecture in the future. Welcome to pay attention to it. If you have any questions, feel free to communicate with me.

  • 1, the background

  • 2. SpringCloud, a microservices framework

  • 3. Service governance

    • 3.1 had been
    • 3.2 a Zookeeper

  • 4. Service load and invocation

  • 5. Service circuit breaker and downgrade

  • 6. Service gateway

  • 7. Distributed service configuration

  • 8. Distributed link tracking

  • 9,

1, the background

In the early days of IT Internet, most software architectures adopted monomer architectures, which meant that all business modules in Application were packaged in one file for deployment. This architecture made communication between different systems extremely difficult.

As the business becomes more and more complex, the single architecture coupling all the business modules together has become very bloated, making the development, maintenance, and extension of the code dramatically reduced. In general, the problems faced by a single architecture are as follows:

(1) Code redundancy

There is a lot of code that duplicates the same business logic

(2) Poor reliability

A bug in a single module in a single architecture can cause an entire application to crash

(3) Low development efficiency

  • Multiple people maintain a single application, frequently merge code, and resolve code conflicts frequently, which takes a lot of time and costs
  • Every time it goes online, it has to merge with the latest code and re-conduct regression test of full function, which is time-consuming
  • It’s difficult to coordinate with each other, and you can have people going live multiple times, merging code multiple times, resolving conflicts, doing full regression testing, doing things multiple times

(4) It is difficult to upgrade the technical architecture

Do not upgrade the technical architecture arbitrarily, because the technology may affect the code developed by other teams

(5) Overstaffed applications

The coupling of all business modules is too high, and projects with too high coupling and large volume are bound to bring challenges to all technical links. The more advanced the project is, the more difficult it is. As long as there are changes, the whole application needs to be retested and deployed, which not only greatly limits the flexibility of development, but also has huge hidden dangers, which can easily lead to the collapse of the project.

.

The architecture of individual applications is shown below:

Monomer architecture

In order to solve the problems caused by the monolithic architecture, the microservices architecture was developed, in short. Microservice is an architecture mode that separates a single application into several small services to cooperatively complete system functions. It decouples a complex problem into several simple problems (such as common service separation) at the system architecture level.

The advantage of this is that for each simple problem, the difficulty of development, maintenance and deployment is reduced a lot, can realize autonomy, can independently choose the most appropriate technical framework, improve the flexibility of project development.

At the same time, the microservices architecture is not simply split, but the microservices must communicate with each other after the split, otherwise they cannot collaborate to fulfill requirements. Different microservices can communicate with each other through a certain protocol, call each other and cooperate to complete functions, and all the services only need to develop a unified protocol, as for the technical framework used to achieve each microservice, it does not need to care.

This loose coupling makes development and deployment more flexible, and the system is easier to expand, reducing the difficulty of development, operation and maintenance. The architecture of a single application after splitting is shown in the following figure.

Microservices Architecture

In the microservices architecture, services are independent of each other and only need to focus on their own business.

Therefore, the first task of the split microservice is to realize service governance, including service registration and service discovery. In addition, load balancing between microservices, service fault tolerance, distributed configuration, gateways, and service monitoring need to be considered.

2. SpringCloud, a microservices framework

There are many frameworks to realize microservices, such as SpringCloud, which is known to us. SpringCloud is developed based on SpringBoot, which can quickly build distributed applications based on microservices.

The relationship between SpringCloud and SpringBoot can be shown in the following figure

SpringCloud and SpringBoot

SpringBoot is used to build a basic system quickly, and SpringCloud implements common components in distributed system on this basis, such as service registration, service discovery, configuration management, fuse, and service invocation based on REST API.

Below is the SpringCloud architecture diagram from the official website

SpringCloud architecture

Below, we’ll detail the capabilities of each component in SpringCloud.

3. Service governance

In the traditional RPC framework, it is complicated to manage the dependencies between each service. Therefore, it is necessary to adopt a certain mode to manage the dependencies between services, and this mode is called service governance. Service governance mainly includes service discovery and service registration

Here’s an example:

When a single service is split into microservices, if there is invocation dependency between microservices, the service address of the target service needs to be obtained, which is also the service discovery in microservice governance. To complete service discovery, service information needs to be stored in a carrier, the carrier itself is the service registry in microservice governance, and the action stored in the carrier is service registration.

Common service registration discovery components include Eureka, Zookeeper, Consul

3.1 had been

Eureka is a component responsible for service registration and discovery in SpringCloud. It is divided into Eureka server and Eureka client. Eureka Server serves as the registration and discovery center for services. Eureka Client can act as both a service producer and a service consumer. The specific structure is shown as follows:

Eureka service registration and discovery

(1) Eureka Server

The Eureka Server provides the function of service registration. After each micro-service node is configured and started, it registers with the Eureka Server. Therefore, the service registry in Eureka Server will store information about all available service nodes.

(2) Eureka Client

The Eureka Client is used to interact with the Eureka Server and has a built-in load balancer that uses a polling load balancing algorithm. After the application is started, the heartbeat is sent to the Eureka Server (default interval is 30 seconds). If Eureka Server does not receive a heartbeat from a node within multiple heartbeat cycles, the Eureka Server will remove the service node from the service registry.

3.2 a Zookeeper

As a distributed coordination service, ZooKeeper has many application scenarios, such as distributed lock, configuration center, and service registration and discovery.

Using Zookeeper to realize service registration and discovery, the main application is Zookeeper’s Znode data model and Watch mechanism.

The data model of Zookeeper is a “tree structure”. The tree is composed of nodes, and each node in the tree is a Znode.

The Watch mechanism can be understood as a listener bound to Znode. When the Znode changes, the listener will asynchronously send notification to the client requesting Watch after listening to these write operations.

In general, the Zookeeper service registration and discovery process is as follows:

The ZooKeeper service was registered. Procedure

(1) Service discovery

When a service consumer starts, it obtains the registered service information from the Zookeeper server and sets Watch based on the service information it depends on. After obtaining the registered service information, the service provider information is cached locally. When invoking the service, the service is invoked based on the service registration information obtained from the Zookeeper registry.

(2) Service notice

When the service producer breaks down or does not provide services for some reason, the corresponding service node in the Zookeeper service registry will be deleted, because the service consumer sets Watch on the corresponding node when obtaining service information, so the corresponding Watcher will be triggered after the deletion of the node. The Zookeeper registry asynchronously sends notification of node deletion to all service consumers associated with the service. Service consumers update the cached service list based on the notification.

There are many other components used for service registry discovery, such as Consul, Nacos, etc., which we will not cover in this article and which will be compared in a series of subsequent articles.

4. Service load and invocation

Service load and invocation are divided into load balancing and service invocation. Service invocation is probably well known as the remote invocation made by the consumer after obtaining the address of the provider in the registry.

Load balancing is a technology that must be used in microservice architecture. Simply speaking, load balancing is to allocate users’ requests to different servers according to certain policies, so as to achieve high availability of the system. Common load balancing tools include NGINx and LVS.

Load balancing

The user’s request first reaches the load balancer, which forwards it to the microservice based on the load balancing algorithm.

Common load balancing algorithms include polling, random, hash, etc.

Ok, so with all that foreshadowing behind us, here’s our focus: Ribbon and OpenFeign.

SpringCloud Ribbon is the full name of SpringCloud Ribbon. Its main function is to provide load balancing algorithm for client software. It provides a series of perfect configurations to help you call remote services.

OpenFeign is a lightweight Restful Http client in the SpringCloud component. In particular, OpenFeign has the Ribbon built in, so it can also do load balancing for clients.

Let’s sort it out in detail:

When we only introduce the Ribbon in our project, we can use the restTemplate to make service calls as follows:

Ribbon

For comparison purposes, let’s take a look at the implementation process for introducing OpenFeign:

OpenFeign

It can be obtained from the comparison of the two figures:

Compared with the Ribbon, OpenFeign has an extra layer of interface on the client side. When the Ribbon was used before, the client only had the Controller layer. The Controller layer of the server was requested by restTemplate.

OpenFeign needs to create a service layer on the client side and create a Service interface (using the @FeignClient annotation) whose methods correspond to the methods in the controller on the server side. The controller on the client side then calls this interface. The introduction of OpenFeign directly cuts down the restTemplate. The client controller does not need to pay attention to the request mode, address and whether it is forObject or forEntity when calling the server. It is completely interface oriented and has a clearer hierarchy. OpenFeign integrates the Ribbon itself, so polling load balancing is enabled by default.

Alternatively, OpenFeign can combine with Hystrix to write a class that implements the Service interface, where the body of the implemented method is the degraded or fusing Fallback method (which needs to be specified in the interface). The structure is clearer and the coupling is lower.

5. Service circuit breaker and downgrade

All systems, especially distributed ones, experience failures. Therefore, how to build applications to handle such failures is a must for every software developer.

Most of the strategies used are to avoid the collapse of upper-level calls in the event of errors or poor performance of remote services, resulting in rapid failure, rather than spreading the effects of this poor performance throughout the system.

To solve these problems, common technical means are client load balancing, service circuit breaker, service degradation and service traffic limiting.

Troubleshooting Process

From this diagram, we can see that load balancing, service circuit breaker, service degradation and service flow limiting can exist in both client and microservice, microservice and microservice.

We have already described the load-balancing pattern, which is that each time a consumer invokes a service instance, the load balancer uses a specific load-balancing algorithm to return a specific location from the pool of service instances it maintains.

Let’s talk about service fuses, service downgrades, and service traffic limiting.

(1) Service fuse

A service circuit breaker mimics the pattern of a circuit breaker that will step in and interrupt the call if it takes too long. If there are enough failed calls to a remote resource, the circuit breaker will trip, preventing further calls to the failed service. However, the circuit breaker will let a small number of requests invoke the service for a specified period of time, and if those calls are successful many times in a row, the circuit breaker will reset automatically.

(2) Service degradation

The server is busy, please try again later, do not let the client wait and return a friendly prompt immediately. Service degradation occurs as follows:

  • Abnormal program running
  • timeout
  • Service fuse fault triggers service degradation
  • A full thread pool/semaphore can also cause service degradation

(3) Service traffic limiting

Service limit flow occurs in the second kill or high concurrency scenario where incoming requests are queued, one by one.

Common technology components that use these strategies are Hystrix and Sentinel.

6. Service gateway

In the microservice architecture, different microservices can have different network addresses. Each microservice can call each other to complete user requests. The client may call N interfaces of microservices to complete a user request.

For example:

When a user purchases a product, it may contain basic commodity information, price information, comment information, discount information, inventory information, etc., and these information are obtained from different micro-services, such as user micro-service, order micro-service, inventory micro-service, commodity micro-service storage, etc.

Gatewayless microservices

The fact that a user has to invoke so many microservices to complete a single request adds complexity to the client. To solve this problem, you can put an intermediary between the client and microservices, the API gateway.

Microservices with gateways

An API gateway is a server that is the only gateway to the system. The API gateway encapsulates the internal architecture of the system and provides a custom API for each client. The core point of THE API gateway approach is that all clients and consumers access microservices through a unified gateway and handle all non-business functions at the gateway layer.

In fact, gateways are so powerful that they are often used in the following scenarios

  • The reverse proxy
  • authentication
  • fusing
  • Log monitoring
  • .

Common Gateway components include Zuul and Gateway.

7. Distributed service configuration

In a single application, there are more or less configuration files, such as application.xml and log4j.properties in Spring applications, which can be easily configured. However, in the micro-service architecture system, because there are many micro-services and there are mutual calls between services, how does the micro-service know the address of the called micro-service? What if the address of the called micro-service changes? How we can easily make changes and refresh automatically in real time without having to restart the application. In other words, configuration management of microservices needs to solve the following problems:

(1) Configure centralized management

Manage all microservices in the application in a unified manner

(2) Dynamic configuration

Adjust the configuration based on the system running status and dynamically configure the system without stopping services.

(3) Automatically refresh configurations

When the configuration is modified, it can be refreshed automatically

Therefore, a common distributed configuration management is essential for microservices architecture.

There are many commonly used configuration components, such as SpringCloud Config, Apollo, and Nacos, and this article gives a brief introduction to SpringCloud Config.

SpringCloud Config provides centralized external configuration support for microservices in the microservices architecture, and the configuration server provides a centralized external configuration for all environments of various microservices applications.

SpringCloud Config is divided into two parts: Server (Config Server) and Client (Config Client).

The server is a distributed configuration center, which is an independent microservice application that connects to the configuration server and provides configuration information to the client.

Client application is the configuration by specifying the center to manage the resources, as well as the contents of business related configuration, and when to start from the center and load configuration information, the default configuration information using the git server storage, thus help to version management of environment, and can through git client tool for convenient management and access configuration.

SpringCloud Config Distributed configuration

8. Distributed link tracking

Microservices architecture is the decomposition of individual pieces of software into smaller, more manageable parts that can be built and deployed independently.

Microservices Architecture

However, this flexibility comes at a cost. The distributed nature of microservices means that one or more transactions must be tracked across multiple services, physical machines, and different data stores, making it maddening to try to locate the problem when it happens to our program.

A distributed call chain is essentially a reduction of a distributed request to a call link. Explicitly view the invocation of a distributed request in the back end, such as the time spent on each node, which machine the request was directed to, the request status of each service node, and so on.

SpringCloud Sleuth provides a complete set of service tracking solutions that are compatible with Zipkin in distributed systems, simply by downloading the Zipkin JAR package.

9,

This article is the introduction of learning microservices. It only lists the technical components that need to be learned in microservices, and does not elaborate on the principle and use of technical components.

In the subsequent articles, we will make a detailed introduction to the specific knowledge points.

Shoulders of giants

[1] www.xiaochenboss.cn/article_det…

[2] blog.csdn.net/weixin_4282…

[3] B station video, Shang Silicon Valley Teacher Zhou Yang

[4] John CARnell. Spring micro service practice