Shulou(Shulou.com)06/02 Report--

This article mainly introduces "what is Eureka service governance". In daily operation, I believe that many people have doubts about what is Eureka service governance. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts of "what is Eureka service governance"! Next, please follow the editor to study!

1. What is service governance

1. Service governance is the core module of micro-service architecture, which realizes the automatic registration and service discovery mechanism of each service. So why do you need service governance?

If there are only An and B services in the project, A service needs to call B service, and if this invocation method is written in the code (for example, calling through HTTP request, writing the request path of B service in the code of service A calling B service), then once the request path of B service needs to be sent to change, you must modify the code in A service at the same time, which is very troublesome.

And what is more complicated is that, in order to ensure the high availability of services, service B and An are usually deployed with multiple instances, so it is impossible to maintain a list of service B in each A. moreover, it is necessary to manually implement the load balancing of service B. both the later maintenance and the implementation of the code are very complex. What is even more frightening is that in reality, a project may have dozens or hundreds of services, each service may have multiple invocation relationships, and each service will have multiple deployment instances and load balancers. It is impossible to imagine how horrible it would be to rely on human resources for service governance.

Therefore, there must be an automated service governance mechanism to reduce workload and improve code maintainability.

2. To put it simply, service governance is service registration and service discovery. The simple principles are as follows:

(1) Service registration: in the service governance framework, a registry is built and maintained, and each service registers itself here. For example, a series of data such as service name, ip address and port number, and communication protocol are stored in the registry. The registry is classified according to the service name to form a service list.

For example, service A deploys three instances (192.168.10.01) 80192.168.10.01 (8081192.168.10.01), and service B deploys three instances (192.168.10.02) 80192.168.10.02 (8081192.168.10.02), when these services are started and registered with the service center. Then the registry of the service center maintains a data table similar to the following table. At the same time, the registry must regularly do a heartbeat test to each service to determine whether the service under a certain address in the list is available or not. If it is not available, it also needs to be removed to achieve the effect of troubleshooting services.

Service name request address A192.168.10.01:8080192.168.10.01:8081192.168.10.01:8082B192.168.10.02:8080192.168.10.02:8081192.168.10.02:8082

(2) Service discovery: with the service governance framework, the invocation between services does not need to specify a specific path to call, but through the service name to achieve the invocation, the service caller does not know the specific location of the invocation instance, so you need to obtain the list of all instances corresponding to the service name through the service registry. For example, if the above A wants to call B, you must first obtain the instance address of B (192.168.10.02) from the service center (192.168.10.02), and then choose one of these addresses to make the service call (this part involves load balancing).

To improve performance, there may be a caching mechanism that caches a list of service instance addresses provided by the service registry locally, so that you do not have to request the service center to obtain the list every time another service is called. But there is another problem: what if an instance service fails and is removed from the registry, but still exists in the list of service instances in the local cache? If you call it, there is bound to be an error, resulting in an entire functional exception, which will be discussed later.

For the same service, no matter how many instances are deployed, they must be guaranteed to have the same service name, which is the guarantee of service discovery.

2. Eureka implements service governance

1. In SpringCloud, service governance (service registration and discovery) is realized through Eureka. Eureka is divided into server and client components. The server is the service instance list data center, which maintains and stores all service information, while the client is integrated into each service. Through this client, the service registers with the Eureka server and invokes other services. Both the server and the client are written in Java, so Eureka is suitable for micro-service systems developed by Java, but not only for Java, because Eureka is a service call realized through HTTP requests, so for other languages, you only need to develop a set of clients to use.

two。 For the service side of Eureka, that is, the service registry, we can achieve highly available configuration deployment, that is, cluster deployment, which ensures that even if one service registry fails, other service registries can still provide services.

3. Eureka implements a simple implementation of service governance:

(1) first of all, build a service registry, that is, the server of Eureka.

Create a new Springboot project and introduce Eureka-related jar package dependencies. Look directly at the configuration code

First, add a @ EnableEurekaServer annotation to the startup class of the SpringBoot project

@ EnableEurekaServer@SpringBootApplicationpublic class EurekaServerDemoApplication {public static void main (String [] args) {SpringApplication.run (EurekaServerDemoApplication.class, args);}}

Then make a detailed configuration in application.properties. An example of a quick answer is as follows

Server.port=8081eureka.client.register-with-eureka=falseeureka.client.fetch-registry=falseeureka.client.serviceUrl.defaultZone= http://localhost:8081/eureka/

Eureka.client.register-with-eureka=false: because the current project project is the service registry, you do not need to register yourself with yourself and set it to false.

Eureka.client.fetch-registry=false: the registry is responsible for maintaining service instances, so there is no need to retrieve the service, and it is also set to false.

These two configuration parameters are used to register with the service center. For the service (Eureka client), it cannot be configured as false, but the service registry can be configured as false. The above two configurations are configured as false because the current service registry is single, not cluster deployment, and does not have high availability, so it is set to false. Once you need high availability for cluster deployment service registry The above two parameters are not set to false, but the default is true.

For the eureka.client.serviceUrl.defaultZone= http://localhost:8081/eureka/ line configuration, in fact, at the beginning, individuals do not think it is necessary, because the current service registry does not need to register with other service registries, so it is not configured and can be started and running normally, but the current service registry will always report errors after startup. The cause of the problem can be found in https://www.jianshu.com/p/788745f7dc7d.

After the configuration is completed, start the project, and the browser can visit http://localhost:8081/ to see the visual management interface of Eureka.

(2) create a service project and register the service provider:

Create a SpringBoot project project and annotate the SpringBoot startup class with @ EnableDiscoveryClient

@ EnableDiscoveryClient@SpringBootApplicationpublic class EurekaClientDemoApplication {public static void main (String [] args) {SpringApplication.run (EurekaClientDemoApplication.class, args);}}

Write a simple Controller class as the service provided and respond to a string

@ RestControllerpublic class HelloController {@ RequestMapping ("/ hello") public String sayHello () {return "hello";}}

Then there is the configuration file, the address of the main configuration service registry, and the service name of the current service

Server.port=8082spring.application.name=hello-serviceeureka.client.serviceUrl.defaultZone= http://localhost:8081/eureka/

At this point, the current service can register with the Eureka service registry, start two projects, open the Eureka visual management interface, and you can see the registered hello-service service in the Instances column.

The registration of the service has now been completed.

3. Eureka to achieve high availability

1. Eureka to achieve high availability, the Eureka service registry, that is, the server side of Eureka, can adopt the cluster deployment mode. The cluster deployment of Eureka actually registers itself with other service registries as a service, forming a group of service registries that register with each other, thus realizing the synchronization of service listings between service registries and achieving the effect of high availability. Even if a service registry node dies, there will still be other service registry nodes to replace.

2. Eureka service registry cluster configuration:

(1) in the above single-node service registry, two lines of configuration are added because there is no need to register with other nodes.

Eureka.client.register-with-eureka=falseeureka.client.fetch-registry=false

But now that we want to build the cluster mode, the configuration of these two lines will have to be cancelled. Then create two service registry project projects peer1 and peer2 respectively, the main configuration of which is as follows

/ / the main configuration in application.properties of peer1 the main configuration of server.port=8085spring.application.name=eureka-servereureka.client.serviceUrl.defaultZone= http://localhost:8084/eureka in application.properties of server.port=8084spring.application.name=eureka-servereureka.client.serviceUrl.defaultZone= http://localhost:8085/eureka//peer2

(2) start the two projects and open the Eureka visual interface in the browser to see the mutually registered services. In the Instances currently registered column, you can see that there are two instances of Eureka-server services.

(3) above, there are two service registries registering with each other. If there are dozens of service registries, the main configuration is eureka.client.serviceUrl.defaultZone. If you want to register to multiple service registries, use commas to separate the paths of each service registry center.

(4) if the service registry cluster is built, then after configuring the service registration, in the service provider project, the main configuration is eureka.client.serviceUrl.defaultZone. To register to multiple service registries, use commas to separate the paths of each service ancestral center. For example, the hello-service service project created above should be configured as

Server.port=8082spring.application.name=hello-serviceeureka.client.serviceUrl.defaultZone= http://localhost:8084/eureka/,http://localhost:8085/eureka/

In fact, only write the path address of a service registry in the cluster, and the rest of the nodes in the service registry cluster can also perceive the registered services, because the cluster nodes will always do a registered service list data synchronization.

But the reason why the service has to register with all the service registry nodes is that it is worried that if the service center node B registered by the service A dies, the rest of the service registry nodes in the cluster can still keep service An in the service list and detect its heartbeat state, and the service can also keep the service list data synchronized with the service center cluster, otherwise, if the service center registered by the service fails Then the service will no longer be able to synchronize the service inventory data with the service registry cluster, and there will be no guarantee of service discovery.

At this point, the study on "what is Eureka service governance" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.