The original address: microservices. IO/patterns/se…

background

Clients accessing a service use client-side service discovery or server-side service discovery to locate a service instance and send requests to that instance to invoke the desired service.

The problem

In client service discovery, how does the client know where the available instances of the service are? In server-side discovery instances, how does the load balancer know where the available instances of the service are?

consideration

  • Each instance may expose remote apis (such as HTTP/REST, or Thrift) on specific hosts and ports
  • The number of service instances and their locations change dynamically. Virtual machines and containers are usually assigned a dynamic IP address. For example, the AWS EC2 automatic expansion group adjusts the number of instances based on LOAD.

The solution

Implement a service registry, a database that holds instance information and location of all services. A service instance is registered with a service registry when it is started and unregistered when it is closed. The client and/or load balancer of a service queries the service registry to find available instances of the service, and the service registry may invoke the health check API of the service instance to verify that it can handle requests.

For example,

Let’s use an example of an application discovered by a client service. Written in Scala, using SpringBoot and SpringCloud as microservice frameworks, with Netflix Eureka service registry.

The Eureka server is a small SpringBoot application:

@SpringBootApplication @EnableEurekaServer public class EurekaServer { public static void main(String[] args) { new SpringApplicationBuilder(EurekaServer.class).web(true).run(args); }}Copy the code

Deploying with Docker:

eureka:
  image: java:openjdk-8u91-jdk
  working_dir: /app
  volumes:
    - ./eureka-server/build/libs:/app
  command: java -jar /app/eureka-server.jar --server.port=8761
  ports:
    - "8761:8761"
Copy the code

Other examples of service registries (or technologies commonly used as service registries) include:

Some systems, such as Kubernetes, Marathon, and AWS ELB have an implicit service registry logic.

Results analysis

The benefits of this design pattern for the registry include:

  • A service client or load balancer can dynamically discover the location of a service instance.

At the same time, there are some disadvantages:

  • Unless a service registry is built into the infrastructure, there is another set of infrastructure components that need to be maintained. In addition, the service registry is a key system component. Although the client should cache the data provided by the service registry, if the service registry fails, the data will eventually become obsolete. Therefore, the registry must be highly available.

You need to choose how to register service instances with the registry. There are two options:

  • Self-registration mode: Service instances register themselves.
  • Third party registry mode: a third party registers service instances with a service registry.

The client of the service registry needs to know the location of the registry instance. Registry instances must be deployed on fixed public network addresses and configured on the client side.

For example, Netflix Eureka service instances are typically deployed using elastic IP addresses. The available elastic IP address pools are configured using properties files or DNS. When the Eureka instance starts, it determines which elastic IP address is available based on the configuration. The Eureka client also configures the elastic IP address pool.

Related patterns

  • The client discovers services, and the server discovers services
  • Self-registration and third-party registration are two ways to register services
  • Health check API: The service registry invokes the health check API of the service instance to verify that it can handle the request