我们一起来回顾一下上次的分享:
要是对上述 GO 的通道 和 sync 包有点兴趣的话,欢迎查看文章 GO通道和 sync 包的分享
今天我们来看看服务注册与发现
服务注册和发现的基本原理如下:
服务注册
指服务实例启动的时候将自身的信息注册到服务注册与发现中心,并在运行的时候通过心跳的方式向服务注册发现中心汇报自身服务状态
服务发现
指服务实例向服务注册与发现中心获取的其他服务实例信息,用于进行后续的远程调用。
根据网络资源和 GO 相关的书籍介绍,简单梳理了如下 3 个点:
管理当前注册到服务注册与发现中心的微服务实例元数据信息,这些信息包括服务实例的服务名,IP地址,端口号,服务状态和服务描述等等信息
服务注册与发现中心会与已经注册 ok 的微服务实例维持心跳,定期检查注册表中的服务是否正常在线,并且会在过程中剔除掉无效的服务实例信息
如一个人服务需要调用服务注册与发现中心中的微服务实例,可以通过服务注册与发现中心获取到其具体的服务实例信息
对于服务注册和发现,不得不说的一个定理是 CAP 定理
是描述分布式系统下节点数据同步的基本定理
有如下 3 个特性:
指数据的一致性。
系统的数据信息,这里包括备份的数据信息,在同一时刻下都是一致的。
在我们现在的分布式系统中,同一份数据可能存在多个实例当中,在这个特性的要求下,每一个实例若修改了其中一份数据,都必须同步到他所有的备份当中
指服务的可用性
这里是要求服务实例,在接收到客户端的请求后,都能够给出相应的响应
这里是考量系统的可用性 ,例如在系统中某个节点宕机了,客户端请求服务的时候,服务端仍然可以做出对应的响应
这个特性是这样理解的
现在我们分布式的系统环境中,每一个节点之间都是通过网络通信连接起来的,
可是,我们要知道,基于网络通信,还是会存在不可靠的地方,处在不同的网络环境,该环境下的服务节点是会有可能出现连接不上,通信失败的。
img
对于以上这个问题,若系统可以容忍,那么这个系统就满足了 分区容忍性
常用的服务注册和发现框架有如下一些,我这里列举几个:
基于HTTP 协议的分布式 key/value 存储组件
基于 Raft 算法的开箱即用的服务发现组件
重量级一致性服务组件
基于集群配置的组件
我们今天来看看这些服务注册和发现组件中的 ETCD ,也是因为他比较简单,易于使用,并且是 GO 开发的
ETCD 一个开源的、高可用的分布式key-value存储系统,可以用于配置共享和服务的注册和发现
那么 ETCD 自身有啥特点?
整理梳理了一下,有如下几个特点:
ETCD 可用于避免硬件的单点故障或网络问题
每次读取 ETCD 上的数据,都会返回跨多主机的最新写入的数据
可以简单的定义良好、面向用户的API(此处说的API 指的是 gRPC 的接口)
ETCD 里面还实现了带有可选的客户端证书身份验证 TLS
资料上表示,每秒 10000次 写入的基准速度
使用 Raft算法 实现了强一致、高可用的服务存储目录
集群中的每个节点都可以使用完整的存档数据
根据以上特性,有没有发现这些特性都是围绕 CAP定理 来的
还是刚才说到的 ETCD ,用起来很简单,且还有如下特点:
来说一说为啥不用Zookeeper呢?
我们在使用 ETCD 的时候 ,我们就直接把 ETCD 当做是一个配置中心即可 ,系统内的所有服务的配置都会在ETCD上进行管理
有小伙伴会有疑问,那么 注册的服务实际配置信息改变了怎么办呢?
ETCD 都给你想好了,我们是这样使用 ETCD 的
我们服务启动的时候,会主动从 ETCD 上获取一次配置信息
并且在 ETCD 节点上注册一个 Watcher 并等待
那么以后自身服务配置信息改变的时候,ETCD 就会知道某个服务配置改变了,且会将该变动的情况通知到这个服务的订阅者
这样子就达到了其他服务获取最新配置的目的了
上面有说到 服务注册与发现,会遵循 CAP 定理
ETCD 的强一致性,得益于 Raft 算法,在 ETCD 里面,对ETCD 的操作,存储到集群中,一定是全局唯一的,根据 ETCD 的这一个特性, 我们就可以用来实现 分布式锁了
ETCD 的锁服务有 2 种方式:
同一个时刻,全局只有一个服务可以拿到锁
获得锁的顺序也是全局唯一的,若小A获得了锁,那么在 ETCD 里面,会有相应的key value 来标识 这一个客户端
关于 GO 编码中 ETCD 的应用案例,下一次我们可以关注一下
朋友们,你的支持和鼓励,是我坚持分享,提高质量的动力
好了,本次就到这里,下一次 GO 中 ETCD 的编码案例分享
技术是开放的,我们的心态,更应是开放的。拥抱变化,向阳而生,努力向前行。
我是小魔童哪吒,欢迎点赞关注收藏,下次见~