引言
微服务架构下, 服务间调用复杂度提升. 因为我们的某一个服务可能并非一个实例, 这会导致一系列问题产生.
服务如何发现?
在微服务架构中, 通常我们会使用容器管理服务, 以便其动态扩\缩容. 而这样的状态下,服务的套接字是变化的. 假设我们有两个微服务ServiceA和ServiceB, A将无法明确知道ServiceB的地址.
如何知道服务是否健康?
如果B服务的一个实例崩溃了, A服务却浑然不知, 还在向其发送请求, 会影响系统的可用性
配置如何统一管理?
每个微服务都有自己的配置, 比如数据库连接、超时时间, 如果这些配置修改了, 需要逐个重启服务, 这在生产环境风险极大
Consul给出的解决方案
服务发现
- 当服务启动时, 主动向Consul注册自己(服务名(如: user-service)、IP、端口号)
- 其他服务通过Consul查询user-service,获取可用的实例列表
- 其他服务选择其中一个健康的实例发送请求
注: 经典的遇事不决加一层
健康检查
- 服务注册时, 定义健康检查规则(比如每10秒调用一次服务的
/health接口) - 如果检查到实例不健康, 自动将其从可用列表中移除
动态配置管理
- 使用Consul的KVStore, 存储配置(如
condig/redis键, 存储redis连接字符串) - 每个服务启动时从Consul读取该配置
- 修改Redis地址时, 服务通过监听机制重新获取值
