[TOC]

服务注册与发现之ETCD

image

我们一起来回顾一下上次的分享：

• 通道是什么，通道的种类
• 无缓冲，有缓冲，单向通道具体对应什么
• 对于通道的具体实践
• 分享了关于通道的异常情况整理
• 简单分享了sync包的使用

要是对上述 GO 的通道 和 sync 包有点兴趣的话，欢迎查看文章 GO通道和 sync 包的分享

今天我们来看看服务注册与发现

什么是服务注册和发现？

服务注册和发现的基本原理如下：

image

服务注册

指服务实例启动的时候将自身的信息注册到服务注册与发现中心，并在运行的时候通过心跳的方式向服务注册发现中心汇报自身服务状态

服务发现

指服务实例向服务注册与发现中心获取的其他服务实例信息，用于进行后续的远程调用。

服务注册和发现的作用？

根据网络资源和 GO 相关的书籍介绍，简单梳理了如下 3 个点：

image

• 管理实例信息

管理当前注册到服务注册与发现中心的微服务实例元数据信息，这些信息包括服务实例的服务名，IP地址，端口号，服务状态和服务描述等等信息

• 健康检查

服务注册与发现中心会与已经注册 ok 的微服务实例维持心跳，定期检查注册表中的服务是否正常在线，并且会在过程中剔除掉无效的服务实例信息

• 提供服务发现的作用

如一个人服务需要调用服务注册与发现中心中的微服务实例，可以通过服务注册与发现中心获取到其具体的服务实例信息

对于服务注册和发现，不得不说的一个定理是 CAP 定理

CAP原理是个啥？

是描述分布式系统下节点数据同步的基本定理

有如下 3 个特性：

• 一致性

指数据的一致性。

系统的数据信息，这里包括备份的数据信息，在同一时刻下都是一致的。

在我们现在的分布式系统中，同一份数据可能存在多个实例当中，在这个特性的要求下，每一个实例若修改了其中一份数据，都必须同步到他所有的备份当中

image

• 可用性

指服务的可用性

这里是要求服务实例，在接收到客户端的请求后，都能够给出相应的响应

这里是考量系统的可用性 ，例如在系统中某个节点宕机了，客户端请求服务的时候，服务端仍然可以做出对应的响应

• 分区容忍性

这个特性是这样理解的

现在我们分布式的系统环境中，每一个节点之间都是通过网络通信连接起来的，

可是，我们要知道，基于网络通信，还是会存在不可靠的地方，处在不同的网络环境，该环境下的服务节点是会有可能出现连接不上，通信失败的。

img

对于以上这个问题，若系统可以容忍，那么这个系统就满足了 分区容忍性

服务注册和发现都有哪些组件？

常用的服务注册和发现框架有如下一些，欧我这里列举几个：

• ETCD

基于HTTP 协议的分布式 key/value 存储组件

• Consul

基于 Raft 算法的开箱即用的服务发现组件

• Zookeeper

重量级一致性服务组件

image

• Eureka

基于集群配置的组件

我们今天来看看这些服务注册和发现组件中的 ETCD ，也是因为他比较简单，易于使用，并且是 GO 开发的

ETCD 是个啥？

ETCD 一个开源的、高可用的分布式key-value存储系统，可以用于配置共享和服务的注册和发现

那么 ETCD 自身有啥特点？

整理梳理了一下，有如下几个特点：

• 高可用性

ETCD 可用于避免硬件的单点故障或网络问题

• 一致性

每次读取 ETCD 上的数据，都会返回跨多主机的最新写入的数据

• 简单

可以简单的定义良好、面向用户的API（此处说的API 指的是 gRPC 的接口）

• 安全

ETCD 里面还实现了带有可选的客户端证书身份验证 TLS

• 快速

资料上表示，每秒 10000次 写入的基准速度

• 可靠性

使用 Raft算法 实现了强一致、高可用的服务存储目录

• 完全复制

集群中的每个节点都可以使用完整的存档数据

根据以上特性，有没有发现这些特性都是围绕 CAP定理 来的

image

来我们对比一下为什么选择 ETCD 而不是 Zookeeper？

还是刚才说到的 ETCD ，用起来很简单，且还有如下特点：

• 支持HTTP/JSON API ， 使用简单；使用 通用的 Raft 算法保证强一致性这让用户更加容易理解一些
• ETCD 默认数据一更新，就会进行持久化，这一点很香
• ETCD 还支持 SSL 客户端安全认证，能够做到既简单，又安全

来说一说为啥不用Zookeeper呢？

• Zookeeper 部署和维护起来，相对复杂，并且 Zookeeper 使用的强一致性算法 是 Paxos 算法，相对晦涩难懂
• 官方提供的接口里面没有 Go 的，这就很尴尬了，只有JAVA 和 C 的

image

GO 如何 用 ETCD

我们在使用 ETCD 的时候 ，我们就直接把 ETCD 当做是一个配置中心即可 ，系统内的所有服务的配置都会在ETCD上进行管理

有小伙伴会有疑问，那么 注册的服务实际配置信息改变了怎么办呢？

ETCD 都给你想好了，我们是这样使用 ETCD 的

我们服务启动的时候，会主动从 ETCD 上获取一次配置信息

并且在 ETCD 节点上注册一个 Watcher 并等待

那么以后自身服务配置信息改变的时候，ETCD 就会知道某个服务配置改变了，且会将该变动的情况通知到这个服务的订阅者

这样子就达到了其他服务获取最新配置的目的了

ETCD 的分布式锁

上面有说到 服务注册与发现，会遵循 CAP 定理

ETCD 的强一致性，得益于 Raft 算法，在 ETCD 里面，对ETCD 的操作，存储到集群中，一定是全局唯一的，根据 ETCD 的这一个特性， 我们就可以用来实现 分布式锁了

image

ETCD 的锁服务有 2 种方式：

• 保持独占锁

同一个时刻，全局只有一个服务可以拿到锁

• 控制好客户端请求的时序

获得锁的顺序也是全局唯一的，若小A获得了锁，那么在 ETCD 里面，会有相应的key value 来标识 这一个客户端

总结

• 分享了服务注册和发现是什么
• CAP 定理是什么
• ETCD 是什么，以及ETCD 和 Zookeeper的对比
• ETCD 的分布式锁实现的简单原理

关于 GO 编码中 ETCD 的应用案例，下一次我们可以关注一下

欢迎点赞，关注，收藏

朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力

image

好了，本次就到这里，下一次 GO 中 ETCD 的编码案例分享

技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。

我是小魔童哪吒，欢迎点赞关注收藏，下次见~