服务调用-注册中心架构设计
2021-09-17 12:49:19 0 举报
为你推荐
查看更多
服务调用-注册中心架构设计
作者其他创作
大纲/内容
服务端
客户端
1. 服务端单点2.使用IP+PORT调用,指定调用指定的服务,不能实现高可用
1. 根据ServiceName通过LoadBalance负载均衡器从注册中心获取服务实例列表2. 根据不同的IRule算法,从服务实例列表中选取其中的一台,将ServiceName转换成IP+PORT,目标服务器地址3. 再根据HTTPClient采用V1.0的版本发起调用,获取响应结果
1. 根据ServiceName通过LoadBalance负载均衡器从注册中心获取服务实例列表 1.1 优先从本地缓存获取,获取不到再从注册中心拉取2. 根据不同的IRule算法,从服务实例列表中选取其中的一台,将ServiceName转换成IP+PORT,目标服务器地址3. 再根据HTTPClient采用V1.0的版本发起调用,获取响应结果
服务调用V2.2 版本
从注册中心拉取服务实例列表
仔细琢磨,整个架构,是否还有其他的问题?等等,好像还有,比如: 由于网络波动等因素,服务无法与注册中心通信,注册中心上服务实例的状态如何更新
多个服务进行注册,上报自己的IP + PORT
缓存从注册中心拉取的服务列表,避免了每次调用进行网络IO消耗
1.项目启动从注册中心拉取所有服务实例列表2. 在本地开启定时任务,定时从注册中心拉取数据
存在的问题:
服务调用V1.0 版本
注册中心
是否还可能存在问题呢? 比如:每次请求都从注册中心获取服务实例列表,都要进行一次网络IO,存在性能上的问题
服务调用V2.4 版本
通过HTTPClient 直接发送请求
服务调用V2.1 版本
服务端(tomcat容器)
健康检查任务
看似完美,其实还存在问题。比如: 本地缓存如何及时更新,与注册中心服务实例数据保存一致性
服务调用V2.3 版本
定时任务用于定时从注册中心拉取数据,保持数据一致性
与注册中心进行定时心跳通信,更新服务节点最后的心跳时间,这个心跳时间就是注册中心用来判断服务是否还”活着“的依赖
心跳定时任务
监听机制Listener,当serverList服务列表发生改变,触发监听,操作有两种:1. 通知客户端,从注册中心拉取数据2. 主动推送数据到客户端最终目的: 尽可能保证客户端服务实例数据的实时性
解决了版本V1.0的存在的不能实现高可用的问题,那么问题来了,客户端在获取到实例列表后,怎么操作?
项目启动从注册中心拉取所有服务实例列表
服务调用V2.0 版本
主要用来进行服务端和客户端进行服务列表数据共享,实现方式很多:1. ZK(watch机制)2. redis(发布 订阅机制)3. mysql4. nacos(监听机制)5.eureka
定时进行健康检查任务: 根据服务节点的最后更新时间,进行比较,然后更新服务节点的状态(UP DOWN WARN)
收藏
0 条评论
回复 删除
下一页