This is the 14th day of my participation in Gwen Challenge

ETCD for service registration and discovery

Let’s take a look back at our last post:

  • What is a channel? What kind of channel
  • No buffered, buffered, one-way channel what exactly
  • Specific practices for channels
  • Shared exception tidup about channels
  • Simple sharing of the use of the Sync package

If you are interested in the GO channel and sync package mentioned above, please check out the GO channel and Sync package sharing article

Today we’ll look at service registration and discovery

What is service registration and discovery?

The rationale for service registration and discovery is as follows:

The service registry

When a service instance is started, it registers its information with the service registration and discovery center and reports its service status to the service registration and discovery center in heartbeat mode

Service discovery

Other service instance information that a service instance obtains from the Service Registration and Discovery Center for subsequent remote invocations.

What is the role of service registration and discovery?

According to network resources and GO related books, the following three points are briefly sorted out:

  • Managing Instance Information

Manage the microservice instance metadata information currently registered with the Service Registration and Discovery center. This information includes the service name, IP address, port number, service status and service description of the service instance

  • Health check

The Service Registration and Discovery Center maintains heartbeat with registered microservice instances, periodically checks whether the services in the registry are online, and removes invalid service instance information in the process

  • Provide the role of service discovery

If a service needs to invoke the microservice instance in the service registration and discovery center, the specific service instance information can be obtained through the service registration and discovery Center

One theorem that has to be said for service registration and discovery is the CAP theorem

What is the CAP principle?

Is a basic theorem describing node data synchronization in distributed systems

It has the following three features:

  • consistency

Consistency of index data.

System data, including backup data, is consistent at the same time.

In today’s distributed system, the same copy of data may exist in multiple instances, and this feature requires that every instance that modifies one copy of data must be synchronized to all its backups

  • availability

Refers to the availability of services

Here is the request service instance, after receiving the client request, can give the corresponding response

This is to consider the availability of the system. For example, when a node in the system breaks down, the server can still respond to the client’s request for service

  • Zonal tolerance

This property is understood this way

Now in our distributed system environment, each node is connected by network communication,

However, we need to know that based on network communication, there will still be unreliable places, in different network environments, the service node under the environment is likely to be disconnected, communication failure.

If the system can tolerate the above problem, then the system satisfies partition tolerance

What are the components of service registration and discovery?

Some commonly used frameworks for service registration and discovery are as follows. Here are a few:

  • ETCD

Distributed key/value storage component based on HTTP protocol

  • Consul

Out-of-the-box service discovery component based on Raft algorithm

  • Zookeeper

Heavyweight consistency service components

  • Eureka

Components based on cluster configuration

We are looking at ETCD in these service registration and discovery components today because it is relatively simple, easy to use, and was developed by GO

What is ETCD?

ETCD An open source, highly available distributed key-value storage system that can be used to configure the registration and discovery of shares and services

So what’s unique about ETCD itself?

After sorting it out, it has the following characteristics:

  • High availability

ETCD can be used to avoid single points of failure of hardware or network problems

  • consistency

Each time data is read on ETCD, the latest data written across multiple hosts is returned

  • simple

You can easily define a well-defined, user-facing API (by API I mean the gRPC interface)

  • security

ETCD also implements TLS with optional client certificate authentication

  • fast

The baseline speed of 10,000 writes per second

  • reliability

A strongly consistent and highly available service storage directory is implemented using Raft algorithm

  • Fully replicated

Complete archived data is available to each node in the cluster

According to the above characteristics, have you found that these characteristics are around the CAP theorem

Why did you choose ETCD over Zookeeper?

ETCD is very simple to use and has the following features:

  • Support HTTP/JSON API, easy to use; Using the generic Raft algorithm to ensure strong consistency makes it easier for users to understand
  • It is nice to know that ETCD is persisted whenever the default data is updated
  • ETCD also supports SSL client security authentication, which is both simple and secure

Why not use Zookeeper?

  • Zookeeper is relatively complex to deploy and maintain, and the strong consistency algorithm used by Zookeeper is the Paxos algorithm, which is relatively obscure
  • There is no official interface for Go, which is very embarrassing, only JAVA and C

How to use ETCD for GO

When we use ETCD, we can directly treat ETCD as a configuration center, and the configuration of all the services in the system will be managed on ETCD

If the actual configuration information of the registered service is changed, what should I do?

ETCD is all set for you. This is how we use ETCD

When we start the service, we will take the initiative to get the configuration information from ETCD once

And register a Watcher on the ETCD node and wait

When its own service configuration information changes, ETCD will know that a service configuration has changed and will notify the subscribers of the service of the change

This serves the purpose of getting the latest configuration for other services

Distributed lock for ETCD

It says that service registration and discovery follow the CAP theorem

The consistency of ETCD is greatly improved thanks to Raft algorithm. In ETCD, operations on ETCD are stored in the cluster and must be globally unique

ETCD provides lock services in two ways:

  • Hold exclusive lock

Only one service in the world can acquire the lock at any one time

  • Control the timing of client requests

The order in which A obtains the lock is also globally unique. If A obtains the lock, there will be A corresponding key value in ETCD to identify the client

conclusion

  • What is shared service registration and discovery
  • What is the CAP theorem
  • What is ETCD and how does it compare to Zookeeper
  • Simple principle of distributed lock implementation of ETCD

Next time we will look at ETCD in GO encoding

Welcome to like, follow and favorites

Friends, your support and encouragement, I insist on sharing, improve the quality of the power

Ok, this time here, the next GO ETCD coding case share

Technology is open, our mentality, should be more open. Embrace change, live in the sun, and strive to move forward.

I am Nezha, welcome to like, see you next time ~