服务端
客户端
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）
