1、场景
常见的开关信息、访问地址信息，一般的分布式配置中心（比如disconf）就可以搞定，但是如果是一些value非常大的配置信息，比如value超过1M的活动文案信息，或者一些临时活动的配置信息，只在特定节假日使用一次，用完就可以删除，如果把这些信息都放在disconf上，那么disconf文件会越来越大，不但维护越来越困难，而且每次有变更，拉取这么大文件也费时间，所以我们需要开发适合自己项目的配置中心。
2、设计公共配置服务注意点
-
低成本：公共配置中心作为基础服务，假设单个节点支持30000PS，支持百万，需要300个节点才能支撑，成本能否hold住?
业务模块缓存公共配置，获取不到值才调用公共配置中心
-
高性能：业务模块通过http或rpc调用基础服务，如果网络抖动，高并发下很容易服务超时，影响业务?
同步调用弊端，同步换成异步，定时拉取
-
实时性：获取配置信息的实时性如何保障?
通过发布订阅通知变更
-
高可用：公共配置不能丢失，必须高可用，业务模块是否要缓存公共配置?
业务本地缓存公共配置
-
高并发：高并发下，基础服务不能挂?
限流，redis缓存，本地缓存
3、架构设计
3.1 方案设计:
业务模块集成sdk-->sdk定时拉取配置到本地缓存--->http请求远程的配置服务
3.2 公共配置服务架构图
image.png
3.3 SDK设计
- 1、定时拉取公共配置数据到本地缓存，业务需要获取配置，从本地缓存中读取
- 2、业务模块启动拉取远程数据，更新本地缓存
- 3、提供公共配置相关API(获取string、bean、List)
3.4 公共配置服务设计
- 1、通过多级缓存前置查询提升接口的OPS(缓存数据新增或修改、查询)
- 2、本地缓存、redis缓存、db一致性保障
- 3、限流保障接口可用
