之前设计过一个 百万级QPS的公共配置中心设计方案，主要是用于服务端配置，但是对于APP端，其实不太适用，因为我们想要实时触达APP端，目前业界主流的触达技术方案主要有以下几种方案：
- push推送：push消息当前已经成为实时推送营销信息、重要通知的最主要手段之一，push消息拥有较强的实时性，而实际的移动端的应用场景中，push消息多用于营销方案或重要信息的通知，很少使用此通道来作为研发配置信息的触达通道，其会产生UI交互的变化。另外push消息依赖于用户打开通知权限开关，而业内普遍打开通知开关权限的比例低于50%，因此大部分用户无法触达；
- netty 长连接：通过建立一条客户端到服务端之间的长连接通道，此方案可以在发生配置信息变更后实时的将信息传递至客户端，但是需要耗费较大的服务器资源，来维护一条长连接通道；
- C端轮询：客户端以一定的时间间隔向服务端发出请求，通过频繁请求的方式来保持客户端和服务器端的信息同步，这种同步方案的最大问题是当客户端以固定频率向服务器发起请求的时候，服务器端的数据可能并没有更新，这样会带来很多无效的网络传输。
总结：推送push消息方案存在触达比例低的问题，长链接存在耗费服务器资源的缺点，同时轮询的方案也存在很多无效的网络传输等弊端
实现方案
先搭建一个信息配置管理CMS平台，同时构建一个客户端获取配置信息的客户端组件，由用户在CMS配置信息，然后由CMS后台将配置信息的版本号信息同步至统一网关，所有客户端请求到达统一网关，并在返回的接口数据的header内都会携带最新的版本号至客户端，客户端对比发现新的版本号比缓存的版本大则请求配置信息拉取Switchquery配置接口，这样只要App打开就会存在接口携带变化标志返回，这样就会触发客户端主动发起请求更新配置信息，提高了实时性，不受push开关权限控制和影响，不需要额外打造长连接通道，具有低成本，实时性高等优点。
时序图
1、用户在CMS 后台配置相关信息，可支持配置布尔类型、整型、字符串等类型的配置信息，可以配置App版本生效区间，按设备号灰度比例，iOS或者安卓平台的设定，生效白名单等相关信息；
2、配置信息持久化到数据库；
3、配置后台完成信息配置后，后台会基于当前时间戳，生成一个新的配置信息版本号，同时将这些配置的静态数据写入到服务端内存缓存内；
4、CMS配置后台将配置信息数据写入和保存一份静态数据json到CDN（主动预热），防止接口降级或者失败以后可以降级从CDN拉取配置信息数据；
5、CMS后台配置信息并提交和保存完成后，由CMS配置后台将新的版本号写入到统一网关后台（所有客户端到服务端的http请求都会经过统一网关，所有服务端返回到客户的http请求响应都会经过统一网关），统一网关记录下数据版本号，客户端的所有接口请求的响应header增加一个字段x-switch-config，此字段会携带回配置信息的版本号至客户端；
6、 网关会将版本号下发至客户端网络组件，网络组件在接受到网络请求返回后，首先会解析网络请求的响应header，如果解析到关键字将其对应的value一起解析封装后发起一个全局通知；
7、终端组件在监听到通知后，与本地已经缓存的配置信息数据版本号进行比对，相同则不处理，大于本地版本号则发起配置信息拉取请求，这样即可获取到最新的开关配置信息并缓存在磁盘；
8、如果CDN节点上的配置信息过期或不存在时，从CMC 服务端拉取最新的配置信息
此种触达方式只要客户端打开即会触发请求至统一网关，随即就可以根据变化情况来决定是否更新最新的配置接口数据，无需push通知，无需建立长连接通道，成本低，实时性高。
流程架构设计
1、用户在CMS配置平台进行信息配置后，配置后台接口对配置信息进行对比，如果没发生变化，则结束；发生变化则判断此次变更距离上一次变更是否到了n秒，距离n秒内则不会触发配置信息变更同步，距离n秒外则触发配置信息同步，触发网关和后台服务端内存数据发生变化；也会同步写入一份json静态数据到CDN，这个是为了考虑静态数据走CDN加速和洪峰流量
2、CMS触发变化将新的版本号传递至统一网关，统一网关会做数据版本号的存储，同时会将统一网关的所有机器内存里都存储一份最新的版本号；
3、 客户端任意接口请求都会经过统一网关，所有请求的返回也会通过统一网关返回，在返回的响应header内新增一个x-terminal-config字段，其value是一段字符串，由下划线隔开，格式如：switch_namespace_version_randomtime，第一个字段switch=0/1，其中0表示此能力统一降级关闭，1表示此能力打开；第二个字段namespace表示命名空间，用于区分不同业务； 第三个字段version就是配置信息的数据版本号，按时间戳的形式标识版本号；第四个字段randomtime表示客户端获取到版本号变化差异后并非立刻请求，会延迟[0,randomtime]之间的一个随机时间后才发起请求，这个是为了降低瞬间尖峰流量的产生；
4、客户端网络框架在客户端会不间断随机广播全局通知， 开关客户端组件收到通知后，获取到统一网关的返回数据，解析网络接口返回的header部分，获取x-terminal-config字段，解析字段中的value，如果是降级，则结束，如果版本号没有发生变化，则结束，如果非限流同时 switch=1，并且本地的缓存的开关version小于解析后的version，则根据randomtime随机数发起客户端请求，获取到配置数据后更新本地缓存。
技术优化
在CMC 配置平台的设计开发中，从实时性，性能，成本，稳健等多维度进行了优化，具体的优化措施如下：
- 考虑到实时性与机器成本的平衡，我们在CMS配置端做了聚合n秒后才将配置变更同步至统一网关，主要为了防止多个用户在很近的时间内做了多个修改，会导致统一网关侧频繁的接收到不同的版本号，进而引起客户端频繁的发起请求，导致配置信息服务端的流量陡增，目前的经验值是n=5秒。
- 考虑性能与机器成本的平衡，客户端会根据randomtime来随机发起请求，是为了打散请求发起时机，实际经验我们发现5s会增日常2倍左右的QPS，10s会增加日常1.5倍左右，实际各个场景可以根据自身的服务器机器数量与成本来动态决定选择设置多长时间。
- 为了保障在大促或者特殊促销场景下的稳定性和健壮性，我们在配置信息产生后，首先写入数据到服务器的内存里，这样每次客户端的请求就直接读取内存性能很高，另外也会写入一份json数据到CDN，当服务端出问题后或在大促主动降级后可以通过CDN来兜底。
