Role: Service Governance (Service registration and discovery)

Two concepts:

Service registration: Each service unit registers its services with the registry. The registered information includes host and port numbers, version numbers, communication protocols, and so on. The service center will maintain a service list and use heartbeat to check whether the services in the list are available. If they are not available, they need to be removed from the service list to achieve the effect of troubleshooting services.

Service discovery: Under the service governance framework of microservices, mutual invocation between services is not directly invoked through specific instance addresses, but through request invocation to service names. General logic is such, want to invoke A B, but A beginning don’t know where B, so an instance of A request for the service center by B address, service center to all instances of B address to A, A call to B when returning from service center B instance list through some polling strategy to obtain A position for service invocation, Thus the client load is implemented. The explanation here is just an idea. In fact, A will not go to the service center to search for B’s address every time, and different application scenarios will also have different implementation strategies on caching and service elimination mechanisms

Eureka’s service governance mechanism

The three core elements under the Eureka service governance infrastructure

  • Service Registry
  • Service provider
  • Service consumer

Many times, the client is both a service provider and a service consumer

Service provider

  • The service registry

Service providers register themselves with EurecaServer at startup by sending REST requests, along with their metadata information. After receiving the REST request, Eureca Server stores the metadata information in a two-tier Map, with the first key being the service name and the second key being the instance name of the specific service.

  • Renew service

After registering the service, the service provider maintains a heartbeat that tells Eureca Server, “I am a living healthy instance,” to prevent the Elimination task of Eureca Server from excluding the instance from the list of services. Lease -renewal-interval-in-seconds: specifies the call time of the heartbeat task. The default value is 30 seconds. Eureka. Aging time of service, default 90 seconds

Service consumer

  • Access to services

When the service consumer starts, it sends a REST request to the registry to get a list of registered services. For performance reasons, EurecaServer maintains a read-only list of services to return to the client, and the cache list is refreshed every 30 seconds. Eureka.client. fetch-registry: obtains the service. The default value is true. Eureka.client. registry-fetch-interval-seconds: updates the cache list

  • Call the service

After the consumer retrieves the list, it can obtain the instance name and metadata information of the server. The Ribbon uses polling by default to implement client load balancing

  • Referral service

A normal shutdown of a service instance triggers a REST request for the service to go offline to Eureca Server, the registry sets the service status to DOWN, and propagates the offline event.

Service Registry

  • Service synchronization

If two instances of a service are registered with different service center instances, service centers will forward registration request services to other service registries in the cluster, thus achieving service synchronization between service registries.

  • Failure to eliminate

Sometime, service instances are offline due to memory overflow and network faults. However, the service registry does not receive a “service offline” request. In order to solve this problem, Eureca Server will create a scheduled task when it starts up, by default, every 60 seconds from the current list of services that have not been renewed due to timeout (default 90 seconds).

  • To protect themselves

EurekaServer calculates whether the rate of heartbeat failures falls below 85% within 15 minutes. If the rate falls below 85%, EurekaServer protects these instances from expiration, but this allows clients to retrieve the service instances that have already died. This requires that the client must have fault tolerance mechanisms (request retries, circuit breakers, etc.) eureka.server.enable-self-preservation=false: disables the protection mechanism

Q&A

How does Eureka Server achieve high availability?

Mechanism: Register yourself as a registry with other service registries, thus forming a set of mutually registered service registries. Implementation: