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 ~