[TOC]
服务注册与发现之ETCD
咱们一起来回顾一下上次的分享：
- 通道是什么，通道的品种
- 无缓冲，有缓冲，单向通道具体对应什么
- 对于通道的具体实际
- 分享了对于通道的异常情况整顿
- 简略分享了sync包的应用
要是对上述 GO 的通道 和 sync 包有点趣味的话，欢送查看文章 GO通道和 sync 包的分享
明天咱们来看看服务注册与发现
什么是服务注册和发现？
服务注册和发现的基本原理如下：
服务注册
指服务实例启动的时候将本身的信息注册到服务注册与发现核心，并在运行的时候通过心跳的形式向服务注册发现核心汇报本身服务状态
服务发现
指服务实例向服务注册与发现核心获取的其余服务实例信息，用于进行后续的近程调用。
服务注册和发现的作用？
依据网络资源和 GO 相干的书籍介绍，简略梳理了如下 3 个点：
- 治理实例信息
治理以后注册到服务注册与发现核心的微服务实例元数据信息，这些信息包含服务实例的服务名，IP地址，端口号，服务状态和服务形容等等信息
- 健康检查
服务注册与发现核心会与曾经注册 ok 的微服务实例维持心跳，定期检查注册表中的服务是否失常在线，并且会在过程中剔除掉有效的服务实例信息
- 提供服务发现的作用
如一个人服务须要调用服务注册与发现核心中的微服务实例，能够通过服务注册与发现核心获取到其具体的服务实例信息
对于服务注册和发现，不得不说的一个定理是 CAP 定理
CAP原理是个啥？
是形容分布式系统下节点数据同步的根本定理
有如下 3 个个性：
- 一致性
指数据的一致性。
零碎的数据信息，这里包含备份的数据信息，在同一时刻下都是统一的。
在咱们当初的分布式系统中，同一份数据可能存在多个实例当中，在这个个性的要求下，每一个实例若批改了其中一份数据，都必须同步到他所有的备份当中
- 可用性
指服务的可用性
这里是要求服务实例，在接管到客户端的申请后，都可能给出相应的响应
这里是考量零碎的可用性 ，例如在零碎中某个节点宕机了，客户端申请服务的时候，服务端依然能够做出对应的响应
- 分区容忍性
这个个性是这样了解的
当初咱们分布式的零碎环境中，每一个节点之间都是通过网络通信连接起来的，
可是，咱们要晓得，基于网络通信，还是会存在不牢靠的中央，处在不同的网络环境，该环境下的服务节点是会有可能呈现连贯不上，通信失败的。
对于以上这个问题，若零碎能够容忍，那么这个零碎就满足了 分区容忍性
服务注册和发现都有哪些组件？
罕用的服务注册和发现框架有如下一些，我这里列举几个：
- ETCD
基于HTTP 协定的分布式 key/value 存储组件
- Consul
基于 Raft 算法的开箱即用的服务发现组件
- Zookeeper
重量级一致性服务组件
- Eureka
基于集群配置的组件
咱们明天来看看这些服务注册和发现组件中的 ETCD ，也是因为他比较简单，易于应用，并且是 GO 开发的
ETCD 是个啥？
ETCD 一个开源的、高可用的分布式key-value存储系统，能够用于配置共享和服务的注册和发现
那么 ETCD 本身有啥特点？
整顿梳理了一下，有如下几个特点：
- 高可用性
ETCD 可用于防止硬件的单点故障或网络问题
- 一致性
每次读取 ETCD 上的数据，都会返回跨多主机的最新写入的数据
- 简略
能够简略的定义良好、面向用户的API（此处说的API 指的是 gRPC 的接口）
- 平安
ETCD 外面还实现了带有可选的客户端证书身份验证 TLS
- 疾速
材料上示意，每秒 10000次 写入的基准速度
- 可靠性
应用 Raft算法 实现了强统一、高可用的服务存储目录
- 齐全复制
集群中的每个节点都能够应用残缺的存档数据
依据以上个性，有没有发现这些个性都是围绕 CAP定理 来的
来咱们比照一下为什么抉择 ETCD 而不是 Zookeeper？
还是方才说到的 ETCD ，用起来很简略，且还有如下特点：
- 反对HTTP/JSON API ， 应用简略；应用 通用的 Raft 算法保障强一致性这让用户更加容易了解一些
- ETCD 默认数据一更新，就会进行长久化，这一点很香
- ETCD 还反对 SSL 客户端平安认证，可能做到既简略，又平安
来说一说为啥不必Zookeeper呢？
- Zookeeper 部署和保护起来，绝对简单，并且 Zookeeper 应用的强一致性算法 是 Paxos 算法，绝对艰涩难懂
- 官网提供的接口外面没有 Go 的，这就很难堪了，只有JAVA 和 C 的
GO 如何 用 ETCD
咱们在应用 ETCD 的时候 ，咱们就间接把 ETCD 当做是一个配置核心即可 ，零碎内的所有服务的配置都会在ETCD上进行治理
有小伙伴会有疑难，那么 注册的服务理论配置信息扭转了怎么办呢？
ETCD 都给你想好了，咱们是这样应用 ETCD 的
咱们服务启动的时候，会被动从 ETCD 上获取一次配置信息
并且在 ETCD 节点上注册一个 Watcher 并期待
那么当前本身服务配置信息扭转的时候，ETCD 就会晓得某个服务配置扭转了，且会将该变动的状况告诉到这个服务的订阅者
这样子就达到了其余服务获取最新配置的目标了
ETCD 的分布式锁
下面有说到 服务注册与发现，会遵循 CAP 定理
ETCD 的强一致性，得益于 Raft 算法，在 ETCD 外面，对ETCD 的操作，存储到集群中，肯定是全局惟一的，依据 ETCD 的这一个个性， 咱们就能够用来实现 分布式锁了
ETCD 的锁服务有 2 种形式：
- 放弃独占锁
同一个时刻，全局只有一个服务能够拿到锁
- 管制好客户端申请的时序
取得锁的程序也是全局惟一的，若小A取得了锁，那么在 ETCD 外面，会有相应的key value 来标识 这一个客户端
总结
- 分享了服务注册和发现是什么
- CAP 定理是什么
- ETCD 是什么，以及ETCD 和 Zookeeper的比照
- ETCD 的分布式锁实现的简略原理
对于 GO 编码中 ETCD 的利用案例，下一次咱们能够关注一下
欢送点赞，关注，珍藏
敌人们，你的反对和激励，是我保持分享，提高质量的能源
好了，本次就到这里，下一次 GO 中 ETCD 的编码案例分享
技术是凋谢的，咱们的心态，更应是凋谢的。拥抱变动，背阴而生，致力向前行。
我是小魔童哪吒，欢送点赞关注珍藏，下次见~