周一至周五早 8 点半! 精品技术文章准时送上!
精品学习资料获取通道, 参见文末
目录
1, 再回顾: 什么是服务注册中心?
2,Consul 服务注册中心的整体架构
3,Consul 如何通过 Raft 协议实现强一致性?
4,Consul 如何通过 Agent 实现分布式健康检查?
" 上一篇文章: 尴尬了! Spring Cloud 微服务注册中心 Eureka 2.x 停止维护了咋办?, 我们给大家说了一下 Spring Cloud 服务注册中心的一些问题.
如果用 Eureka 作为其注册中心的话, 很多同学都觉得心里没底, 所以现在很多公司都开始使用 Consul 作为其注册中心.
那么这篇文章我们就来给大家说说: Consul 这种服务注册中心的架构是如何设计的?
1, 再回顾: 什么是服务注册中心?
先回顾一下什么叫做服务注册中心?
顾名思义, 假设你有一个分布式系统, 里面包含了多个服务, 部署在不同的机器上, 然后这些不同机器上的服务之间要互相调用.
举个现实点的例子吧, 比如电商系统里的订单服务需要调用库存服务, 如下图所示.
现在的问题在于, 订单服务在 192.168.31.154 这台机器上, 库存服务在 192.137.1.33 这台机器上.
现在订单服务是想要调用库存服务, 但是他并不知道库存服务在哪台机器上啊! 毕竟人家都是在不同机器上的.
所以这个时候就需要服务注册中心出场了, 这个时候你的系统架构中需要引入独立部署在一台机器上的服务注册中心, 如下图所示.
然后订单服务, 库存服务之类的兄弟, 都需要配置上服务注册中心部署在哪台机器上, 比如 192.168.31.45 这台机器.
接着订单服务, 库存服务他们自己启动的时候, 就得发送请求到到服务注册中心上去进行服务注册.
也就是说, 得告诉服务注册中心, 自己是哪个服务, 然后自己部署在哪台机器上.
然后服务注册中心会把大家注册上来的信息放在注册表里, 如下图.
接着订单服务假如想要调用库存服务, 那么就找服务注册中心问问: 能不能告诉我库存服务部署在哪台机器上?
服务注册中心是知道这个信息的, 所以就会告诉订单服务: 库存服务部署在 192.1371.133 这台机器上, 你就给这台机器发送请求吧.
然后, 订单服务就可以往库存服务的那台机器发送请求了, 完成了服务间的调用.
整个过程, 如下图所示:
上述就是服务注册中心的作用, 地位以及意义, 现在大家应该知道服务注册中心的作用了吧.
好! 接着我们就来看看 Consul 作为服务注册中心, 他的架构设计原理是什么?
2,Consul 服务注册中心的整体架构
如果要基于 Consul 作为服务注册中心, 那么首先必须在每个服务所在的机器上部署一个 Consul Agent, 作为一个服务所在机器的代理.
然后还得在多台机器上部署 Consul Server, 这就是核心的服务注册中心.
这个 Consul Agent 可以用来收集你的服务信息然后发送给 Consul Server, 还会对你的服务不停的发送请求检查他是否健康.
然后你要发现别的服务的时候, Consul Agent 也会帮你转发请求给 Consul Server, 查询其他服务所在机器.
Consul Server 一般要求部署 3~5 台机器, 以保证高可用以及数据一致性.
他们之间会自动实现数据同步, 而且 Consul Server 集群会自动选举出一台机器作为 leader, 其他的 Consul Server 就是 follower.
咱们看下面的图, 先感受一下这个 Consul 他整体的架构.
3,Consul 如何通过 Raft 协议实现强一致性?
首先上篇文章: 尴尬了! Spring Cloud 微服务注册中心 Eureka 2.x 停止维护了咋办? 已经说了, Eureka 服务注册中心是不保证数据一致性的.
这样的话, 很可能你注册的服务, 其他人是发现不了的, 或者很迟才能发现.
OK, 那么这里就来讨论一下 Consul 是如何实现数据一致性的.
首先, 大家知道 Consul Server 是部署集群的, 而且他会选举出来一台 Server 作为 Leader.
接下来各个服务发送的注册请求都会落地给 Leader, 由 Leader 同步给其他 Follower.
所以首先第一点, Leader Server 是绝对有最新的服务注册信息的, 是不是?
比如库存服务发起注册了, 那么 Leader Server 上一定有库存服务的注册信息.
接着如果比如订单服务要发现库存服务的话, 这个查询请求会发送给 Leader Server.
这样服务注册和发现, 都是通过一台 Leader Server 来进行的, 就可以保证服务注册数据的强一致性了, 大家看下图.
接着大家想, 假如说库存服务在注册的时候数据刚写到 Leader Server, 结果 Leader Server 就宕机了, 这时候怎么办?
那么此时这条注册数据就丢失了, 订单服务就没法发现那个库存服务了. 没关系, 这里 Consul 会基于 Raft 协议来解决这个问题.
首先, 库存服务注册到 Leader Server 的时候, 会采取 Raft 协议, 要求必须让 Leader Server 把这条注册数据复制给大部分的 Follower Server 才算成功.
这就保证了, 如果你认为自己注册成功了, 那么必然是多台 Consul Server 都有这条注册数据了.
如果你刚发送给 Leader Server 他自己就宕机了, 那么这次注册会认为失败.
此时, Consul Server 集群会重新选举一个 Leader Server 出来, 你需要再次重新注册.
这样就可以保证你注册成功的数据绝对不会丢, 然后别人发现服务的时候一定可以从 Leader Server 上获取到最新的强一致的注册数据.
整个过程, 如下图所示:
上面的图就可以看到, 只要你注册的时候基于 Raft 协议强制同步到大多数 Server, 哪怕是 Leader 挂了, 也会选举新的 Leader.
这样就可以让别人从新的 Leader Server 来发现你这个服务, 所以数据是绝对强一致的.
4,Consul 如何通过 Agent 实现分布式健康检查?
最后说说 Consul 是如何通过各个服务机器上部署 Agent 来实现分布式健康检查的.
集中式的心跳机制, 比如传统的 Eureka, 是让各个服务都必须每隔一定时间发送心跳到 Eureka Server.
如果一段时间没收到心跳, 那么就认为这个服务宕机了.
但是这种集中式的心跳机制会对 Eureka Server 造成较大的心跳请求压力, 实际上平时 Eureka Server 接收最多的请求之一就是成千上万服务发送过来的心跳请求.
所以 Consul 在这块进行了架构优化, 引入了 Agent 概念.
每个机器上的 Consul Agent 会不断的发送请求检查服务是否健康, 是否宕机. 如果服务宕机了, 那么就会通知 Consul Server.
怎么样? 是不是发现各个服务自己不用再发送心跳请求去 Server 了? 减小了 Server 这部分的压力吧?
没错, 这就是 Consul 基于 Agent 实现的分布式健康检查机制, 可以大幅度的减小 Server 端的压力.
这样一来, 哪怕你就部署个三五台机器, 可以轻松支持成千上万个服务.
咱们再来一张图, 一起来看看:
- End
- (封面图源网络, 侵权删除)
扫描下方二维码, 备注:"资料", 获取更多 "秘制" 精品学习资料
如有收获, 请帮忙转发, 您的鼓励是作者最大的动力, 谢谢!
一大波微服务, 分布式, 高并发, 高可用的原创系列文章正在路上
欢迎扫描下方二维码, 持续关注:
石杉的架构笔记 (id:shishan100)
十余年 BAT 架构经验倾囊相授
来源: https://juejin.im/post/5c76bc785188252d564283b9