Why use a registry
Have you ever used IP: port address to call services directly? This painful experience omits 500 words here, Disadvantages of this method:
- You need to manually maintain all service access IP address lists.
- A single service needs to be built by itself to realize load balancing, such as using nginx load balancing strategy, or deploying a single service based on container multiple instances to balance the load between instances.
- Service provider: provide IP: port and other information for service access to the registry according to the service name.
- Registry: stores the corresponding IP: port and other information according to the service name.
- Service consumer: obtain the IP: port and other related information set of the calling service from the registry according to the service name, and then obtain the final server IP: port access address according to the load balancing policy.
When using spring cloud, Eureka and Nacos are commonly used as registration centers. How to choose? (nacos#eureka project case fhadmin. CN)
Actively register with the registry, renew the contract, go offline and obtain the registry. After the service is registered successfully, the heartbeat will be sent to the registration center regularly to ensure that the service will not be rejected.
Store service instances, regularly scan the registry and eliminate expired service instances. High availability is achieved through synchronous replication. First obtain the registry, and then register yourself with other registries. It belongs to AP mode. In actual projects, different registry clusters will be configured according to the environment, such as dev, test and prod. if different projects use a unified registry, they can only be distinguished according to the service name.
Focus on Eureka’s self-protection mechanism. If a large number of service instances are deleted after expiration, the registry will enter the self-protection mode, and the information in the registry will no longer be deleted in order to improve the availability of Eureka. By default, whether the heartbeat failure rate is lower than 85% within 15 minutes is counted. If it is lower than 85%, Eureka server will protect these instances so that they will not expire.
Describe a painful online experience. The error description is as follows:
At that time, the service was deployed successfully. The Eureka registration center has shown that the service has been registered successfully. However, when the front-end request is forwarded to the service through the gateway, there has been no response, and the service call has been unsuccessful. Nginx forwarding and gateway forwarding are confirming where the problem is. After several torments, the gateway forwards it directly to the online service through the IP address to quickly solve the problem.
Follow up, resumption, should Eureka’s self-protection mechanism lead to problems. The service registered in the registry is an unavailable service. However, due to the self-protection mechanism, Eureka server does not eliminate invalid services.
The subsequent solution is to set
enableSelfPreservation=falseTurn off the self-protection mechanism and reduce the renewalpercentthreshold ratio. On the Eureka server side, if there is an invalid service, it will be eliminated.
Nacos is an extension of spring cloud. The registry function inherits discoveryclient through nacosdiscoveryclient. In spring cloud, it can switch with Eureka without intrusion. The registry can manually eliminate service instances and notify the client to update the cached instance information through messages
Nacos mainly needs to understand its domain model. The key of Nacos data model is uniquely determined by triples, namespace, grouping group and service. For details, please refer to the official website Nacos architecture.
Nacos has the following advantages over Eureka:
- Nacos automatically or manually logs off the service, uses the message mechanism to notify the client, and the modification of the service instance responds quickly; Eureka can only eliminate invalid services through task timing.
- Nacos can be grouped according to namespace, dataid and group to distinguish the configurations of different environments (DEV, test, prod) and different projects.