etcd
- The service discovery and balancing algorithm of etcd-client strongly depend on the version of grpc. In the following three version cycles, there are 3 different algorithms.
grpc-1.10:
- For a request, send connection establishment to three (app) service nodes a, b, and c at the same time, and return the fastest connection (assuming a). If a node request fails because of an error, it fails, and the request will not be retried but directly fail.
grpc-1.7:
- For a request, send to the three (app) service nodes a, b, and c at the same time to establish a connection, and return the fastest connection. A node has an error, there will be a retry mechanism. After retrying, it will mark a as unhealthy and maintain an unhealthy list (a is in it). During a renewal period, the damaged node will remain unused.
Above,
the failure retry strategy of the two versions has poor compatibility and many bugs when the grpc version is iterated. They launched grpc-1.23
grpc-1.23:
- For a request, three service nodes a, b, and c are added to establish a connection at the same time, and all three connections are returned. The request will randomly obtain a node to use in a round-robin mechanism. In a renewal cycle, if a is damaged, then he will remain damaged, and the request will not always fail. Because when a is damaged, he will go to b to try again. Until the next time a cannot be renewed and removed from the connection list.
At this point, when using etcd, you must clarify the version of gprc. It requires that the following packages are correct at the same time (because when using, the IDE is easy to automatically prompt different packages, if the two package versions are inconsistent, in case you use two package sources at the same time, just The egg hurts.):
- “Google.golang.org/grpc”
- “github.com/grpc/grpc-go”