👇 Click on the card, follow, and pin the official account 👇
Technical dry goods, timely delivery!
Spring Cloud Eureka is the registration center, responsible for the registration and discovery of microservices, playing a role in the up-and-down, in the microservice architecture equivalent to the human brain, very important, Nacos is Alibaba, the function is similar to Eureka.
Nacos is deployed differently than Spring Cloud Eureka, which needs to create a Spring Boot project, then load the Euraka server in a dependent way, and then deploy the project. Nacos downloads the jar package directly from the official website of Alibaba Nacos and launches the service.
Eureka Servers synchronize data by means of replication, and Eureka also provides a client-side caching mechanism that allows clients to consume APIs for other services using the information in the cache even if all Eureka Servers are hung up. In summary, Eureka ensures high availability, flexibility, and scalability of the system through mechanisms such as heartbeat checking and client-side caching.
Service registration: The Eureka Client registers its service with the Eureka Server by sending a REST request. When you register, you provide your own metadata, such as IP address, port, health metrics, home page address, and more. When Eureka Server receives the registration request, it stores this metadata information in a two-tier map. When to register? When starting the microservice.
Renew: After the service is registered, the Eureka Client maintains a heartbeat to continuously notify the Eureka Server that the service is always available to prevent it from being rejected. By default, every 30 seconds eureka.instance.lease-renewal-interval-in-seconds sends a heartbeat for service renewal.
Get registry: When the Eureka Client starts, it sends a REST request to the Eureka Server, gets the registry’s list of services, and caches it locally on the client. At the same time, for performance and security reasons, Eureka Server updates the list of services in the cache every 30 seconds.
Service call: After the service consumer obtains the service list, he can find the address of the service according to the service information in the list and access it (remote call).
Service downline (cancel): When Eureka Client needs to be shut down or restarted, it does not want any more requests to come in during this time period, so it is necessary to send a REST request to Eureka Server in advance to tell Eureka Server that it is going offline, and Eureka Server will set the service status as offline (DOWN) after receiving the request, and spread the offline event.
Fail-reject (evict): A service instance may not be able to provide services due to network failures, etc., and the instance does not send a request to Eureka Server to take the service offline. Therefore, there is also a need for a service culling mechanism. Eureka Server creates a scheduled task at startup that removes services with no timeout (default 90 seconds) from the current service manifest for services that have not been renewed (default 90 seconds eureka.instance.lease-expiration-duration-inseconds).
Service management: Implement service CRUD, domain name CRUD, service health status check, service weight management and other functions
Consistency protocol: Solve different data, different consistency requirements in the case, different consistency mechanism
OpenAPI: Exposes the standard Rest style HTTP interface, which is simple to use and convenient for multi-language integration
Console: Easy-to-use console for service management, configuration management, and other operations
There are two types of service instances at Nacos:
Temporary instance: If the instance is down for more than a certain period of time, it is excluded from the service list, the default type.
Non-temporary instance: If an instance goes down, it is not excluded from the service list, or it can be called a permanent instance.
To configure a service instance as a permanent instance:
Nacos and Eureka are similar in overall structure, with service registration, service pull, and heartbeat waiting, but there are some differences.
Both support service registration and service pull
Both support service providers to do health testing in a heartbeat manner
Nacos supports active detection of provider status on the server side: temporary instances use heartbeat mode, and non-temporary instances use active detection mode
Temporary instances with abnormal heartbeat are rejected, and non-temporary instances are not rejected
Nacos supports the message push mode of service list changes, and the service list is updated more timely
The Nacos cluster adopts the AP mode by default, and when there are non-temporary instances in the cluster, the CP mode is adopted. Eureka uses the AP method
1. The scope is different.
Nacos’ thresholds are for a specific service, not for all services; But Eureka’s self-protection threshold is for all services. Nacos supports both CP and AP; Eureka only supports APs. Nacos uses Netty, which is a long connection; Eureka is a short connection, sent at regular intervals
2. The protection method is different.
Eureka protection method: When in a short period of time, the proportion of renewal failures is counted, if a certain threshold is reached, it will trigger the self-protection mechanism, under which Eureka Server will not eliminate any microservices, wait until normal, and then exit the self-protection mechanism. Self-protection switch (eureka.server.enable-self-preservation: false).
Nacos protection method: When the proportion of a healthy instance of a domain name to the total number of service instances is less than the threshold, the instance is returned to the client regardless of whether the instance is healthy or not. Although this loses some traffic, it ensures that the remaining healthy instances of the cluster can work normally.
3. The connection method is different.
Nacos supports dynamic refresh, add @RefreshScope annotations to the controller (Controller), using Netty connections, which are long connections; Eureka itself does not support dynamic refresh, and needs to complete the dynamic refresh with MQ, and it is a short connection and is sent timed.
Nacos supports switching between AP and CP modes, which means that Nacos supports both consistency protocols. In this way, Nacos can manage these ecosystem services in a single registry. However, in Nacos, the specific meaning of AP mode and CP mode needs to be explained.
AP mode makes consistency less consistent for the sake of service possibilities, so only temporary instances are supported in AP mode. AP mode is the ability to register instances under network partitions. Non-instance-level data such as the service’s metadata cannot be edited in AP mode, but a service configured by default is allowed. At the same time, there is no need to create a service before registering the instance, because in this mode, the service is actually downgraded to a simple character creation identity, no longer stores any attributes, and will be automatically created when the instance is registered.
In CP mode, persistent instances are registered, but in this case, the Raft protocol is used as the cluster running mode, so you cannot register instances under network partitions, and under normal network conditions, you can edit the configuration of other servers. In this mode, you must register the service before registering the instance, and if the service does not exist, an error is returned.
The MIXED pattern can be a confusing pattern that is set up primarily to support the registration of both temporary and persistent instances. In this mode, the service must be created before the instance is registered, and the temporary instance can be registered with a network partition if the service already exists.
PS: The article is accompanied by a picture, there is a blind lane in the middle of the crosswalk, and the blogger immediately photographed it when he saw it, because it is really rare, and I hope that such a temperature crosswalk can be more.
PS: If the article is helpful, please like, read, and forward it!
If the content published in the public account “Logical Magic Code” indicates the source, the copyright belongs to the original source (those that cannot verify the copyright or do not indicate the source are from the network, it is reprinted, the purpose of reprinting is to convey more information, and the copyright belongs to the original author. If there is infringement, please contact, the author will delete it as soon as possible!