3 细节剖析

3.1 服务生产端keepAlive

keepAlive是一个老生常谈的问题了，下到TCP/IP、HTTP连接，上到Redis集群、MySQL集群，都会有该机制，那么etcd的keepAlive是怎么搞的呢？

下面我们来看下：

etcd使用LeaseKeepAlive API调用创建的双向流来刷新租约。当客户端希望刷新租约时，它通过流发送一个leasekeepaliverrequest:

message LeaseKeepAliveRequest {
  int64 ID = 1;
}
  • ID ：keepAlive有效的租约ID。

LeaseKeepAliveResponse作为keepAlive的响应:

message LeaseKeepAliveResponse {
  ResponseHeader header = 1;
  int64 ID = 2;
  int64 TTL = 3;
}
  • ID ：用新的TTL刷新的租约。
  • TTL ：新的生存时间，以秒为单位，租约剩余的时间。

3.2 服务消费端watch机制

Watch API提供了一个基于事件的接口，用于异步监视服务key的更改。etcd3 watch通过持续观察给定的修订(当前的或历史的)来等待键的更改，并将键更新流回客户端。

对每个键的每次更改都用“Event”消息表示。Event消息提供了更新的数据和更新的类型:

message Event {
  enum EventType {
    PUT = 0;
    DELETE = 1;
  }
  EventType type = 1;
  KeyValue kv = 2;
  KeyValue prev_kv = 3;
}
  • type：PUT类型表示新数据的更新，DELETE表示key的删除。
  • kv：与事件相关的键值PUT事件包含kv。
  • prev_kv：事件发生前修改版本的密钥的键值对。为了节省带宽，它只在watch显式启用的情况下填写。

watch流:

watch是长时间运行的请求，并使用gRPC流来流化事件数据。watch流是双向的;客户端写入流来建立监视，读取流来接收监视事件。通过使用每个watch标识符来标记事件，单个watch流可以将多个不同的手表组合在一起。这种多路复用有助于减少核心etcd集群上的内存占用和连接开销。

4 总结

微服务是当今互联网领域的广泛概念，也是一种架构演进的结果，微服务的存在让架构设计更加的解耦合，让人员的分工更加明确，当然他的落地实现也并不止步与某一两种方式，在云原生领域的Kubernetes+etcd，互联网领域常用的Spring Cloud全家桶以及Dubbo等都是微服务的具体实现，而etcd也仅仅是微服务中服务注册中心组件角色的一个代表而已。

参考：

https://etcd.io/docs/v3.5/dev-guide/grpc_naming/

https://www.jianshu.com/p/217d0e3a8d0f

https://www.cnblogs.com/wujuntian/p/12838041.html

https://stackoverflow.com/questions/64815927/undefined-grpc-clientconninterface-when-compiling-grpc

https://blog.csdn.net/fly910905/article/details/103545120