Spring Cloud Config Server承载50万级配置项可行性及替代方案咨询

你们当前采用Spring Cloud Config Server + RabbitMQ的方案逻辑上符合Spring生态的配置管理规范，但原生SCCS并不适配50万级且持续扩容的配置体量：
SCCS默认会将全量配置加载到内存中处理，50万条结构化配置的序列化、反序列化会占用极高的内存资源，每次微服务启动拉取全量大体积配置 payload 时，服务端处理、网络传输、客户端解析的多层耗时会直接触发读取超时、启动超时问题。单纯的资源调优只能短期缓解，后续配置规模进一步增长后仍会出现性能瓶颈。
另外注意你提供的OurBean代码存在笔误，三个属性均命名为field1，会导致配置注入时丢失field2、field3的值，建议先修正该问题。

针对100+微服务共享配置、每周数次更新、需一次性全量刷新的场景，可选择以下方案：

• 方案1：改造现有SCCS架构实现分片加载
  按照你们配置的前缀规则（如we.list下的不同key分组、业务域划分）将配置拆分为多个分片，SCCS仅存储分片元数据，真实结构化配置存储在Redis等高性能KV数据库中。微服务启动时只拉取自身需要的分片配置，无需拉取全量数据；配置更新时通过RabbitMQ广播刷新事件，微服务收到事件后仅拉取变更的分片即可，可大幅降低传输和解析开销。
• 方案2：替换为原生支持大体量配置的开源配置中心
  直接切换到Nacos或Apollo，两款配置中心原生支持100万级以上的配置条目存储、1000+节点的批量广播推送，完全适配你们的配置规模和更新频率，且原生兼容Spring生态的@ConfigurationProperties、@RefreshScope注解，现有业务代码几乎无需修改，仅需替换配置中心依赖、修改接入地址即可，改造成本极低。
• 方案3：静态配置预打包+可变配置增量推送
  由于你们的配置更新频率极低（每周数次），可将稳定的基础配置预打包到微服务镜像中，仅将需要变更的动态配置托管到配置中心，进一步降低配置拉取的体积和耗时，更新时仅推送增量变更内容即可。

内容的提问来源于stack exchange，提问作者Tirlipirli