define
The so-called service registry is to put forward a single service in the entire microservice architecture. This service does not complete any business functions of the system, but is only used to complete the service registration and service discovery of the entire microservice system, as well as the monitoring and management of service health status.
function
- You can store information about all microservices, such as the name, IP address, and port of the microservice.
- The service invocation can be made at the time of the service invocation by querying the list of available microservices and network addresses through service discovery (which has nothing to do with the invoked operation).
- All microservices can be heartbeat detected, and if an instance is found to be inaccessible for a long time, it is removed from the service registry.
Common registry
Spring Cloud supports multiple registries Eureka, Consul, Zookeeper, and Alibaba has launched Nacos components. These registries are essentially for managing the registration and discovery of services and checking the status of services.
Eureka, launched by Netflix in Spring Cloud, has been discontinued and Zookeeper is often used in Dubbo’s registry, so this article will only cover the Consul component that is popular in Spring Cloud. The Nacos component is explained in the Spring Cloud Alibaba series.
Differences between registries
1. The principle of CAP
CAP theorem, also known as CAP principle, refers to Consistency, Availability and Partition tolerance in a distributed system. The CAP principle is that, at best, these three elements can achieve two, not all at once.
Consistency (C) : Whether all data backups in a distributed system have the same value at the same time. (Equivalent to all nodes accessing the same latest copy of data)
Availability (A) : Whether the cluster can still respond to clients’ read/write requests after some nodes in the cluster fail. (High availability for data updates)
Partition tolerance (P) : High availability, where one node collapses without affecting the others. (100 nodes, several hung, no impact on service, the more machines the better)
2. Eureka features (AP)
Eureka does not use any data consistency algorithm to ensure data consistency between servers in different clusters, and only strives for the final consistency of registry data through data copy. Although giving up data consistency but in exchange for Server availability, reduce the cost of registration, improve the robustness of cluster operation.
3. Consul Characteristics (CP)
Consul provides highly consistent registry services based on Raft algorithms. However, as the Leader node undertakes all the processing work, it is bound to increase the cost of registration and discovery and reduce the availability of services. With the Gossip protocol, Consul can monitor Consul cluster operations and be notified of events. For example, the Leader selection occurs or the Server address changes.
4. Zookeeper Features (CP)
Based on the Zab protocol, Zookeeper can be used to build a service registration and discovery center with strong data consistency. In contrast, service availability is sacrificed and registration time is increased.
Zab protocol: Whenever the data of a node in a service cluster changes, the node will notify the Leader node, and the Leader node will send an atomic broadcast to inform all nodes in the cluster to modify the data. The node changes the data and responds to the Leader node. If the Leader does not receive a response from any node, the service cluster becomes unavailable.
Consul components
1. Introduction
Consul is a distributed service framework that provides service discovery, health check, multi-data center, and Key/Value storage capabilities for service discovery and configuration in distributed systems. Registration and discovery schemes with other distributed services are also simpler to use. Consul is implemented with Golang and is therefore naturally portable (Linux, Windows, and MacOS support). The installation package contains only one executable EXE file for easy deployment.
2. Enable Consul
- Go to www.consul.io/downloads.
- Decompress Consul to obtain the Consul file.
- Open CMD in the directory of Consul execution file.
- Enter CMD: consul agent-dev.
- Enter localhost:8500 in the browser.
3. Consul client development template
-
Consul dependency is introduced in porn.xml
<! -- Consul Client dependency --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-consul-discovery</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-consul-config</artifactId> </dependency> <! -- Consul provides heartbeat detection function component dependencies --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> Copy the code
-
Add start class annotations
@SpringBootApplication // Spring Cloud native annotations, enable service registration and discovery, optionally added @EnableDiscoveryClient public class ConsulClientApplication { public static void main(String[] args) { SpringApplication.run(ConsulClientApplication.class, args); }}Copy the code
-
The configuration application. Yml
spring: application: # app name name: consul-client cloud: consul: Host in # Consul registry host: localhost The port number of the # Consul registry port: 8500 discovery: # Whether registration is required register: true # specify the registered service name (default: application name) service-name: ${spring.application.name} # service port port: ${server.port} Whether to register with an IP address prefer-ip-address: true Service request IP ip-address: ${spring.cloud.client.ip-address} Configure the consul service health check (enabled by default) register-health-check: true If the url of the health check is not configured, the health check will fail health-check-path: /actuator/health Health check interval health-check-interval: 10s Copy the code