Micro service actual combat (four): service discovery feasible program and practice case
This is the fourth article on using the micro service architecture to create an application series. The first article introduces the microarchitecture model and discusses the advantages and disadvantages of using the micro service architecture. The second and third sections describe the communication mechanisms within the micro service architecture. In this article, we will explore issues related to service discovery.
Why use service discovery?
Imagine that we are writing code using a service that provides a REST API or Thrift API. To complete a service request, the code needs to know the network location (IP address and port) of the service instance. Traditional applications are running on the physical hardware, the service instance of the network location is relatively fixed. For example, the code can read the network location from a frequently changing profile.
- How to use AWS and Rancher to build a flexible application stack
- Rancher Labs and EVRY become strategic partners to accelerate DevOps in the Nordic market
- How to create a private Docker Registry with password protection
- Introduction to container ecosystems
- Docker Ecosystem Series III: Service Discovery and Distributed Configuration Storage
- How to expose service access in Kubernetes
And for a modern, cloud-based micro-service applications, this is a very troublesome problem. Its architecture as shown:
The service instances of the service instances are dynamically allocated, and because of the needs of extensions, failures, and upgrades, service instances often change dynamically, so client code requires a more complex service discovery mechanism.
There are two major categories of service discovery modes: client discovery and server discovery .
Let's talk about client discovery first.
Client discovery mode
When using client discovery mode , the client is responsible for determining the network location of the corresponding service instance and implementing load balancing for the request. The client queries from a service registration service, which is the library for all available service instances. The client uses the load balancing algorithm to select one from multiple service instances and then issue the request.
The following figure shows the schema of this model:
The network location of the service instance is registered to the service registry at startup and is removed from the registry when the service terminates. Service instance registration information is generally used to refresh the heartbeat mechanism.
Netflix OSS provides a great client discovery pattern. Netflix Eureka is a service registry that provides a REST API interface for service instance registration management and querying available instances. Netflix Ribbon is an IPC client that works with Eureka to achieve load balancing on requests. We will discuss Eureka in detail later.
Client discovery mode is also the advantages and disadvantages. This model is relatively straightforward, and in addition to the service registry, there are no other factors to change. In addition, because the client knows the available service registry information, the client can become smarter and more efficient load balancing by using hashing consistently.
One of the biggest drawbacks of this model is the need to register different services for different programming languages, and the client needs to develop different service discovery logic for each language.
We analyzed the client found, and then look at the server to find.
Server-side discovery mode
Another mode of service discovery is the server-side discovery pattern, which shows the schema of this model:
The client makes a request to a service through the load balancer, which sends a request to the service registry and forwards each request to an available service instance. As with the client discovery, the service instance is registered or logged out in the service registry.
AWS Elastic Load Balancer (ELB) is an example of a server-side discovery route. ELBs are typically used to balance traffic from the network, or to use ELBs to balance VPC internal traffic. The client uses DNS to issue a request (HTTP or TCP) via the ELB. The ELB load balancer is responsible for balancing the load between the registered EC2 instance or the ECS container, and there is no separate service registry, and the EC2 instance and the ECS instance are also registered with the ELB.
HTTP services and load balancers similar to NGINX and NGINX Plus can be used as server-side discovery equalizers. For example, this blog post describes how to use the Consul Template to dynamically configure the NGINX reverse proxy. Consul Template is a tool that periodically resets configuration files from the configuration in the Consul Template registry . When the file changes, a command is run. In the above blog, Consul Template generated a nginx.conf file for configuring the reverse proxy, and then run a command to tell NGINX to re-import the configuration file. More complex examples can be dynamically reconfigured with HTTP API or DNS NGINX Plus.
Some deployment environments, such as Kubernetes and Marathon , run a proxy on each node of the cluster, which finds the load balancer as a server. In order to issue a request to the service, the client uses the host IP address and the assigned port to route the request through the proxy. The proxy forwards the request again transparently to the service instance available in the cluster.
Server-side discovery mode also has advantages and disadvantages. The biggest advantage is that the client does not need to focus on the details of the discovery, the client only need to simply send a request to the load balancer, in fact, reduce the programming language framework needs to complete the discovery logic. Moreover, as mentioned above, some of the deployment environment free of charge to provide the above functions.
This mode is also flawed, unless the deployment environment to provide load balancer, otherwise the load balancer is another need to configure the management of high availability system functions.
The service registry is a very important part of the service discovery, which is the database that contains the service instance's network address. The service registry needs to be highly available and updated at any time. The client can cache the network address obtained from the service registry. However, this information will eventually become obsolete, the client can not find the service instance. Therefore, the service registry consists of several servers that use the replication protocol to keep the synchronization.
As mentioned earlier, Netflix Eureka is a good example of a service registry that provides REST API registration and request service instances. The service instance uses the POST request to register the network address. The registry must be updated every 30 seconds using the PUT method, using an HTTP DELETE request or an instance timeout to log out. It is conceivable that the client can use the HTTP GET request to accept the registration service instance information.
Netflix achieves high availability by running one or more Eureka services in each AWS EC2 domain, and each Eureka server runs on an EC2 instance with a flexible IP address . The DNS TEXT record is used to store the Eureka cluster configuration, which holds a list of addresses from the available domain to a series of Eureka server networks. When the Eureka service starts, accept the Eureka cluster configuration to the DNS request, confirm the companion location, assign itself an unused flexible IP address.
Eureka Client – Service and Service Client – Requests DNS requests to find the network address of the Eureka service, where clients prefer to use services within the same domain. However, if no service is available, the client will use another available domain for the Eureka service.
Examples of other service registries include:
- Etcd – is a highly available, distributed, consistent, key-value table for shared configuration and service discovery. Two famous cases include Kubernetes and Cloud Foundry.
- Consul – is a service for discovering and configuring. An API is provided to allow clients to register and discover services. Consul can be used for health checks to determine service availability.
- Apache ZooKeeper – is a widely used service that provides high-performance integration for distributed applications. Apache ZooKeeper was originally a sub-project of Hadoop and has now become a top-level project.
In addition, the front emphasis, some systems, such as Kubernetes, Marathon and AWS do not have a separate service registry, for them, the service registry is just a built-in feature.
Now let's take a look at the concept of the service registry to see how the service instance is registered in the registry.
Service registration option
As mentioned earlier, the service instance must be registered and logged out of the registry, and how to register and log out there are some different ways. One way is to register the service instance itself, also called self-registration pattern; another way is to provide service instance management for other systems, also called third party registration pattern. Let's take a look at the self-registration model.
When using self-registration mode, the service instance is responsible for registering and logging out in the service registry. In addition, if necessary, a service instance also sends a heartbeat to ensure that the registration information is not obsolete. The following diagram describes this architecture:
A good example is the Netflix OSS Eureka client. The Eureka client handles the registration and logout of service instances. Spring Cloud project, which implements a variety of modes, including service discovery, makes it easier to register an Eureka service instance automatically. You can annotate Java configuration classes with @EnableEurekaClient.
Self-registration mode also has advantages and disadvantages. One advantage is that it is relatively simple and does not require other system functions. And a major drawback is that the service instance with the service registry link. The registration code must be implemented within each programming language and framework.
Another way, do not need to connect services and the registry, it is a third party registration mode.
Third party registration mode
When using the third party registration mode , the service instance is not responsible for registering the service registry, but by another system module, called the service manager, is responsible for registering. The service manager keeps track of changes to the running service by querying the deployment environment or subscription events. When the manager discovers a new available service, it registers the service with the registry. The service manager is also responsible for deregistering the terminated service instance. The following figure is the architecture of this model.
An example of a service manager is the open source project Registrator , which is responsible for automatically registering and unregistering service instances that are deployed as Docker containers. Reistrator supports multiple service managers, including etcd and Consul.
Another example of service manager is NetflixOSS Prana , which is primarily for non-JVM language development services, also known as sidecar applications, and Prana uses Netflix Eureka to register and log out service instances.
The service manager is a built-in module for the deployment environment. EC2 instances created with automatic expansion groups can be registered automatically from the ELB, the Kubernetes service is automatically registered and available for discovery services.
Third-party registration model is also the advantages and disadvantages are. The main advantage is that the service is separate from the service registry, and there is no need to complete the service registration logic for each programming language and architecture. Instead, the service instance is managed through a centrally managed service.
One drawback is that unless this service is built into the deployment environment, it is also necessary to configure a highly available system.
to sum up
In a micro service application, the service instance runtime environment is dynamically changing. The instance network address is also dynamically changed, so the client must use the service discovery mechanism in order to access the service.
The key part of the service discovery is the service registry , which is the database of available service instances. The service registry provides a registration management API and a request API. The service instance uses the registration management API to implement registration and logout.
The request API is used to discover available service instances, corresponding to two main service discovery modes: client discovery and server discovery .
In a system discovered using a client, the client initiates a request to the service registry, selects the available instance, and then issues a service request
In the use of the server to find the system, the client through the routing request, the router to the service registry to send a request to forward the request to an available instance.
There are two main ways to register and log out a service instance. One is the service instance is automatically registered to the service registry, that is, self-registration mode; the other is a system module is responsible for handling registration and cancellation, that is, third-party registration mode.
In some deployment environments, you need to configure your own service discovery architecture, such as Netflix Eureka , etcd, or Apache ZooKeeper . In other deployment environments, such features are used, such as Kubernetes and Marathon to handle the registration and cancellation of service instances. They also run agents on each cluster node to enable the server to discover the functionality of the router.
HTTP reverse proxy and load balancers (such as NGINX) can be used for service discovery load balancers. The service registry can push routing information to NGINX to activate a real-time configuration update; for example, you can use Consul Template. NGINX Plus supports additional dynamic reconfiguration mechanisms that can use DNS to pull service instance information from the registry and provide a remotely configured API.
In the future of the blog, we will also explore the micro-service in-depth features. You can register the NGINX mailing list to get the latest product update tips.
Please refer to the following address:
- Advantages and Disadvantages of Micro Service Architecture
- Use API Gateway
- Depth interoperability of micro services architecture
Source: Service Discovery in a Microservices Architecture (translation: Yang Feng proofreading: Song Yu)