Consul学习

引言

微服务架构下, 服务间调用复杂度提升. 因为我们的某一个服务可能并非一个实例, 这会导致一系列问题产生.

服务如何发现?

在微服务架构中, 通常我们会使用容器管理服务, 以便其动态扩\缩容. 而这样的状态下,服务的套接字是变化的. 假设我们有两个微服务ServiceA和ServiceB, A将无法明确知道ServiceB的地址.

如何知道服务是否健康?

如果B服务的一个实例崩溃了, A服务却浑然不知, 还在向其发送请求, 会影响系统的可用性

配置如何统一管理?

每个微服务都有自己的配置, 比如数据库连接、超时时间, 如果这些配置修改了, 需要逐个重启服务, 这在生产环境风险极大

Consul给出的解决方案

服务发现

1. 当服务启动时, 主动向Consul注册自己(服务名(如: user-service)、IP、端口号)
2. 其他服务通过Consul查询user-service,获取可用的实例列表
3. 其他服务选择其中一个健康的实例发送请求

注: 经典的遇事不决加一层

健康检查

1. 服务注册时, 定义健康检查规则(比如每10秒调用一次服务的/health接口)
2. 如果检查到实例不健康, 自动将其从可用列表中移除

动态配置管理

1. 使用Consul的KVStore, 存储配置(如condig/redis键, 存储redis连接字符串)
2. 每个服务启动时从Consul读取该配置
3. 修改Redis地址时, 服务通过监听或轮询机制重新获取值

轮询获取新值

服务定期调用Consul的KV Store API, 检查配置键的最后修改时间, 若发生变化, 则获取新值. 这种方案优缺点明显, 简单但有延迟, 且浪费资源.

监听

服务订阅某个键的变更事件. 当键值变化时, 通过回调函数去拉取新配置.(如consul-api库)