动态监听之 Pull Or Push (Nacos篇)
Nacos
Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。
Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。
以上摘自nacos官网之官方介绍
详细请上官网查看，附链接：https://nacos.io/zh-cn/index.html
概念&分析
我们都知道 Nacos Config Server 是Nacos实现统一配置管理的核心服务，那么当服务上的配置发生变化时，需要让相关的应用程序感知配置的变化进而实现应用的变化，这就需要客户端针对感兴趣的配置实现监听，从而做出相应的更改。那么Nacos客户端是如何实现配置变更的实时更新呢？
一般来说，客户端和服务端之间的数据交互无非两种方式：Pull 和 Push。
- Pull 表示客户端从服务端主动拉取数据。
- Push 表示服务端主动把数据推送给客户端。
这两种方式没有什么优劣之分，只是看哪种方式更适合于当前的场景。大多数会支持 Push 和 Pull 两种模式，用户可以在不同的特定场景下选择不同的方式来获取数据。
对于 Push 模式来说，服务端需要维持与客户端的长连接，如果客户端的数量比较多，那么服务端需要耗费大量的内存资源来保存每个连接，并且为了检测长连接的有效性，还需要心跳机制来维持每个连接的状态。
在 Pull 模式下，客户端需要定时从服务端拉取一次数据，由于定时任务会存在一定的时间间隔，所以不能保证数据的实时性。并且在服务端配置长时间不更新的情况下，客户端的定时任务会做一些无效的 Pull。
当然，如果你的应用本身就需要实时通信或者本身需要长连接（一直保持连接，如 socket 连接）来支撑业务，那么 Push 无疑是最优选的模式。但如果仅部分功能或者业务需要实现实时更新就没必要为这来建立长连接实现，对此小编建议采用 Nacos 的这种方式即使用 Pull 模式来实现此需求。
Nacos 下的方式
Nacos 采用的是 Pull 模式，但并不是简单的 Pull，而是一种长轮训机制，它结合 Push 和 Pull 两者的优势。客户端采用长轮训的方式定时发起 Pull 请求，去检查服务端配置信息是否发生了变更，如果发生了变更，则客户端会根据变更的数据获得最新的配置。所谓的长轮训，是客户端发起轮训请求之后，服务端如果有配置发生变更，就直接返回，如图所示。
参考文档
如果客户端发起 Pull 请求后，发现服务端的配置和客户端的配置是保持一致的，那么服务端会先 “Hold” 住这个请求，也就是服务端拿到这个连接之后在指定的时间段内一直不返回结果，直到这段时间内配置发生变化，服务端会把原来 “Hold” 住的请求进行返回。Nacos 服务端收到请求之后，先检查配置是否发生了变更，如果没有，则设置一个定时任务，延期 29.5s 执行，并且把当前的客户端长轮训加入 allSubs 队列。这个时候有两种方式触发该链接结果的返回：
- 第一种是在等待 29.5s 后触发自动检查机制，这个时候不管配置有没有发生变化，都会把结果返回客户端。而 29.5s 就是这个长连接保持的时间。
- 第二种是在 29.5s 内任意一个时刻，通过 Nacos Dashboard 或者 API 的方式对配置进行了修改，这会触发一个事件机制，监听该事件的任务会遍历 allSubs 队列，找到发生变更的配置项对应的 ClientLongPolling 任务，将变更的数据通过该任务的连接进行返回，就完成一次 “推送” 操作。
这样既能够保证客户端实时感知配置的变化，也降低了服务端的压力。其中，这个长连接的回话超时时间默认是 30s。
总结
我们在自己的项目中不乏会遇到类似的应用场景，当我们在 Pull 和 Push 之间难以抉择时，不妨使用 Nacos 的设计方式来实现，既能实现我们所需要的功能需求，又能降低客户端和服务端的压力，同时该方式实现起来也没有什么技术难度，开发简单，何乐而不用呢。
小编推荐在相同的应用场景下使用此方式，不推荐使用复杂度较高的长连接通信，这样做对于项目来说其实是得不偿失。
欢迎评论
TopSkyhua
