一、场景

        服务端在服务迁移或升级扩容等情况时，可能使得服务配置发生变化，这时通过重启服务等方式使服务生效，这一般是可以接受的。

        但是如果变更是业务功能相关的配置，比如某个功能项的开关，这时候通过重启服务来更新配置，就显得不合时宜。因此根据业务需要，一般会成立一个配置中心来下发推送客户端需要的配置。市场上也有许多成熟的产品：nacos、apollo等

二、推送方式

        服务端和客户端交换信息只有push和pull两种模式。

2.1 push

        客户端和服务端建立稳定tcp长连接。如果配置发生变化，则立刻告知客户端。

        好处：客户端能秒级感知配置的变化，及时做出调整。

        缺点：配置的变更不是频繁事件，长连接的方式很浪费资源

2.2 pull

        客户端定时发起请求，服务端通过比对当前配置的版本号与请求的版本是否相同来决定是否下发配置给客户端。

        常见的方法：轮询、长轮询

2.2.1 轮询

        客户端以每隔几秒的频率向服务端发送请求，服务端根据情况下发配置。

        这种方法一直有一些饱受诟病的问题：1.间隔时间太长更新不及时。在本次请求即将结束时，某项配置放生变化。服务端没能在这次请求下发。就得等一个间隔时间，再下次请求时客户端才能得到新的配置。2.如果间隔时间太短，导致众多客户端频繁发起更新配置的请求，给服务端造成访问压力。

2.2.2 长轮询

        长轮询是轮询方式的改良版。能客户轮询存在的问题。

实现方式：客户端以一定频率发起请求(比如30s、60s等)。服务端如果没有配置变更，则会hold住本次请求，等超时时间一到，则返回304状态码，表示"未变更"。如果配置发生变更。则马上返回200状态码，并将最新的配置返回。

客户端则是请求结束后，立马发起第二次请求。

设计要点：

        1.一定要设置超时时间，防止连接假死或者服务重启，导致请求不能及时关闭

        2.设计一个版本号，客户端每次请求都带上版本号。服务端可以根据版本号快速判断版本

        3.用304状态码表示配置为最新。节省客户端根据响应进行操作的判断。