一、背景
困了，今天想划水。
网关的高可用好理解，就是启动多台网关服务
- 通过控制台的http长轮训或者WebSocket两种通信方式更新网关数据
- 依赖 ZooKeeper 或者 Nacos 注册中心更新网关数据
负责手动配置和接收应用服务注册的控制台的高可用，应该就是启动多台控制台
- 如果是微服务架构下，多台控制台也是一个服务也有服务名，注册到注册中心上（目前还不行，得自己改动，感觉控制台是游离在微服务体系外得网关管理后台）
- 或者脱离注册中心，前面挂上 Nginx （要做 session 的会话保持，因为客户端有定时任务在检测链接是否存活）
我们看下网关服务获取更新数据得配置
从这份配置其实可以看出来，http长轮训和WebSocket方式相当于有依赖关系，需要制定控制台地址和端口（或者负载的），而使用zk和nacos注册中心相当于在控制台和网关加了一层，使得它俩结偶。其实这里大胆想一下，使用消息引擎替换注册中心也可以做到。
还是控制台也注册到注册中心靠谱，因为网关总是和注册中心成对出现。Soul也正在规划自己的注册中心，希望将来Soul有自己的控制台和注册中心，这样就可以做更多的服务治理，让网关比较轻薄。专心做流量转发和流量加工。
二、猜想
、尝试在 Spring Cloud 生态中，使用 Soul 网关，其实也就是替换 Zuul 和 Spring Cloud Gateway。
- 启动Eureka
- 修改控制台和网关服务接入 Eureka 配置和端口好，启动两台控制台和三台网关服务
也就是这个猜想是让控制台也注册到 Eureka 上，控制台和网关作为两个服务进行http长轮训通信。
除了 WebSocket 方式因为客户端要主动探活，要做会话保持。http长轮训都是单通道短链接无状态，不需要会话保持。注册中心的方式也不存在多节点问题，相当于生产者和消费者模型。
