Service registration is to register a service instance to the service registry, and the service provider informs the service registry of its own service information (such as service name, IP address, etc.).

Service discovery means that when a service consumer needs to consume another service, the service registry can inform the service consumer of the instance information (such as service name, IP address, etc.) of the service it wants to consume. Typically, a service is both a service provider and a service consumer.

A service consumer invokes a cluster of multiple service providers. First, the service consumer needs to maintain the request address for each node of the service provider cluster in a local configuration file. Secondly, if a node in the service provider cluster goes offline or goes down, the local configuration of the service consumer needs to delete the request address of this node synchronously to prevent the request from being sent to the node that has gone down. To solve these problems, we need to introduce a service registry, which has the following functions:

  • Service address management.
  • Service registration.
  • Service dynamic awareness.

There are many components that can implement this function, such as ZooKeeper, Eureka, Consul, And Nacos.

Commonly used contrast registry: (photo developer.aliyun.com/article/698…).

Eureka profile

Like Consul and Zookeeper, Eureka is a component for service registration and discovery. Eureka is divided into Eureka Server and Eureka Client. Eureka Server is the Eureka service registry, and Eureka Client is the Eureka Client. Eureka 2.X version is not maintained. Currently, the latest official version is V1.10.11, which can still be used, but in the latest version of Spring Cloud, the official recommendation has been replaced with other service registration components.

The basic architecture of Eureka includes the following three roles.

  • Register Service: A Service registry, which is a Eureka Server that provides Service registration and discovery functions.
  • Provider Service: The Service Provider, which is a Eureka Client, provides services.
  • Consumer Service is a Eureka Cient Consumer Service.

The basic process of service consumption is as follows: The service provider Eureka Client registers with the Service registry Eureka Server. Submit your information (such as the service name and IP address of the service) to the Eureka Server in the form of REST APIS. Similarly, the service consumer Eureka Client registers with the service registry Eureka Server, and at the same time, the service consumer obtains information about a service registry list that contains information about all services registered with the service registry Eureka Server. After obtaining the service registry information, the service consumer knows the IP address of the service provider and can consume the service provider’s services via Http remote scheduling.

Basic concepts of Eureka

Register — Service registration

When the Eureka Client registers with the Eureka Server, the Eureka Client provides its own metadata, such as IP address, port, Url of health indicator, home page address, and other information.

Renew — Service renewal

By default, the Eureka Client sends a heartbeat every 30 seconds to renew the service. Service renewal is used to inform the Eureka Server that the Eureka Client is still available and not faulty. Normally, if the Eureka Server does not receive a heartbeat from the Eureka Client within 90 seconds, the Eureka Server will remove the Eureka Client instance from the registered list. Note: the website recommends not to change the service renewal interval.

Fetch Registries — Fetch service registration list information

The Eureka Client obtains service registry information from the Eureka Server and caches it locally. The Eureka Client uses the service registry information to look up information about other services to make remote calls. The registration list information is updated periodically (every 30 seconds). The returned information may be different from the information cached by the Eureka Client. The Eureka Client processes the information itself. If for some reason the registry information does not match in time, Eureka Client retrieves the entire registry information. Eureka Server caches all the service registry information and compresses the entire registry and the information for each application. The compressed content is identical to the uncompressed content. The Eureka Client and Eureka Server can communicate using JSON and XML data formats. By default, the Eureka Client uses JSON format to retrieve the service registry information.

Cancel — Service offline

The Eureka Client can send an offline request to the Eureka Server when the program is closed. After sending the request, the instance information of the client will be removed from the Service registry of Eureka Server. This offline request does not complete automatically and requires the following code to be called when the program is closed:

DiscoveryManager.getInstance().shutdownComponent()
Copy the code

Eviction — Service cull

By default, if the Eureka Client does not send a service renewal (heartbeat) message to the Eureka Server for 90 consecutive seconds, the Eureka Server will delete the service instance from the service registry.

Eureka’s highly available architecture

There are two roles in this Eureka architecture, namely Eureka Server and Eureka Client.

Eureka Client is divided into Applicaton Service and Application Client, namely Service provider and Service consumer. Each zone has one Eureka cluster, and each zone has at least one Eureka Server to handle zone failures in case the Server crashes. The Eureka Client registers with the Eureka Server and submits its Client information to the Eureka Server. The Eureka Client then renew the service by sending a heartbeat to the Eureka Server every 30 seconds. If a client does not renew continuously, Eureka Server determines that the client is unavailable and the unavailable client will be removed from the Eureka Serve registry after approximately 90 seconds. Service registration list information and service renewal information are copied to each Eureka Serve node in the cluster. Eureka clients from any region can obtain the service registry information for the entire system. Based on this registry information, the Application Client can remotely invoke the Applicaton Service to consume the Service.

Why is it so slow for Eureka Client to get service instances

1. After the Eureka Client is started, it does not register with the Eureka Server immediately, but has a delay in registering with the Server. The default delay is 40 seconds

//DefaultEurekaClientConfig 类
public int getInitialInstanceInfoReplicationIntervalSeconds() {
	return this.configInstance.getIntProperty(this.namespace + "appinfo.initial.replicate.time", 40).get();
}
Copy the code

2. Had the response of the Server cache had been updated once every 30 seconds response cache maintained by the Server, can Eureka. By changing the configuration Server. ResponseCache UpdateIntervalMs to modify. So even newly registered instances do not immediately appear in the service registry.

3. Cache of the Eureka Client The Eureka Client retains the cache of registry information. This cache is updated every 30 seconds (as mentioned earlier). Therefore, it may take up to 30 seconds for the Eureka Client to flush the local cache and discover other newly registered instances.

The LoadBalancer of the Ribbon gets the service registry information from the local Eureka Client. The Ribbon also maintains caches to avoid the need to fetch a service registry from the Eureka Client for each request. This cache refresh every 30 seconds (can be made of ribbon. ServerListRefreshInterval configuration), so may need at least 30 seconds to use new registered instance.

In summary, a newly registered instance has a default delay of 40 seconds in registering with the service registry, so it cannot be immediately detected by Eureka Server. In addition, the newly registered Eureka Client cannot be immediately called by other services because the caller did not get the latest service registration list information in time due to various caches.

Eureka’s mode of self-protection

When a new Eureka Server appears, it tries to get all service instance registry information from adjacent Peer nodes. If the Eureka Server fails to obtain information from the neighboring Peer node, the Eureka Server tries to obtain information from other Peer nodes. If Eureka Serve successfully obtains information about all service instances, set the service renewal threshold based on the configuration information. If Eureka Serve receives less than the percentage of service renewal at any time (the default value is less than 85% within 15 minutes), the server starts the self-protection mode, that is, no longer removes the information from the registration list. In this way, if the Eureka Client fails to renew its contract due to network problems of the Eureka Server, the registration list of the Eureka Client is no longer deleted. In other words, the Eureka Client can be consumed by other services. By default, Eureka Server’s self-protection mode is enabled.

Eureka: server: enable-self-preservation: falseCopy the code

Alibaba Nacos

Nacos is dedicated to solving the problems of unified configuration, service registration and discovery in microservices. It provides an easy-to-use feature set to help developers quickly implement dynamic service discovery, service configuration, service metadata, and traffic management.

Basic architecture

  • Provider APP: indicates the service Provider.
  • Consumer APP: Serves consumers.
  • Name Server: Service routing of Nacos HA cluster is implemented through VIP (Vritual IP) or DNS.
  • Nacos Server: Nacos Service provider, which contains the Open API as the function access portal, and the Config Service and Naming Service as the configuration Service and name Service modules provided by Nacos. Consistency Protocol is a Consistency Protocol used for data synchronization of Nacos cluster nodes using Raft algorithm (Etcd, Redis Sentry election middleware using similar algorithms).
  • Nacos Console: Nacos Console. In general, service providers access Nacos Server ha cluster through VIP (Virtual IP) and complete service registration and service query based on Open API. Nacos Server itself can support the master/slave mode, so the underlying data consistency algorithm is used to complete the data synchronization of slave nodes. Service consumers do the same, querying the list of services from Nacos Server based on the Open API.

Key features of Nacos

Service discovery and service health monitoring

Nacos supports DNs-based and RPC-based service discovery. After a Service provider registers a Service using the native SDK, OpenAPI, or a separate AgentTODO, Service consumers can use DNS or HTTP&API to find and discover services. Nacos provides real-time health checks on services to prevent requests from being sent to unhealthy hosts or service instances. Nacos supports health checks at the transport layer (PING or TCP) and the application layer (e.g. HTTP, MySQL, user-defined). Nacos also provides a unified health check dashboard to help users manage service availability and traffic based on health status.

Dynamically configured service

Business services typically maintain a local configuration file and configure constants into this file. This approach can be problematic in some scenarios, such as redeploying the application when the configuration needs to change. Dynamic configuration services can manage application configuration and service configuration in all environments in a centralized, external and dynamic way, making configuration management more efficient and agile. Centralized configuration management makes it easier to implement stateless services and make it easier for services to scale flexibly on demand. In addition, Nacos provides a simple and easy-to-use UI (sample console Demo) to help users manage the configuration of all services and applications.

Dynamic DNS Service

The dynamic DNS service supports weighted routing, making it easier for developers to implement middle-layer load balancing, more flexible routing policies, traffic control, and simple DNS resolution services on the data center Intranet.

Services and their metadata management

Nacos enables developers to manage all services and metadata in the data center from a microservices platform construction perspective, including managing service descriptions, life cycles, static dependency analysis of services, health of services, traffic management of services, routing and security policies, SLA of services, and most importantly metrics statistics.

Implement registration and discovery of services

Nacos-spring-cloud-discovery-example For more configuration information, see the official configuration documentation

Add dependencies:

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    <version>${latest.version}</version>
</dependency>
Copy the code

Version 2.1.X. replication corresponds to Spring Boot 2.1.x. Release corresponds to Spring Boot 2.2. x, and 1.5.x. release corresponds to Spring Boot 1.5.x.

Service provider

1. Configure service providers so that they can register their services with Nacos Server through the service registry discovery feature of Nacos. Configure the address of Nacos Server in application.properties:

Server port = 8070 spring. Application. Name = service provider - spring. Cloud. Nacos. Discovery. The server - addr = 127.0.0.1:8848Copy the code

2. Enable the service registration discovery function through the Spring Cloud native annotation @enableDiscoveryClient:

@SpringBootApplication
@EnableDiscoveryClient
public class NacosProviderApplication {}
Copy the code

Service consumer

1. Configure the service consumer so that the service consumer can get the service it wants to invoke from Nacos Server through Nacos’s service registry discovery feature.

Nacos Server address configured in application.properties:

Server port = 8080 spring. Application. Name = service - consumer spring. Cloud. Nacos. Discovery. The server - addr = 127.0.0.1:8848Copy the code

2. Enable the service registration discovery function by using the Spring Cloud native annotation @enableDiscoveryClient. Add @loadBalanced to the RestTemplate instance to enable @loadBalanced integration with the Ribbon:

@SpringBootApplication @EnableDiscoveryClient public class NacosConsumerApplication { @LoadBalanced @Bean public RestTemplate restTemplate() { return new RestTemplate(); } public static void main(String[] args) { SpringApplication.run(NacosConsumerApplication.class, args); } finallyCopy the code

Finally, start two services.

Implementation principle of Nacos service registration and discovery

The Nacos client sends service registration requests through the Open API

When the Nacos server receives the request, it does three things:

  • Build a Service object and store it in the ConcurrentHashMap collection
  • This section describes how to set up a heartbeat detection mechanism for all instances of the current service using scheduled tasks
  • Service data synchronization based on data consistency protocol

reference

Nacos official website (nacos.io/ zh-CN /docs/…)