直接回答：配置中心的本质需求是“读多写极少、强触达、高可用”：模型上是 KV + 命名空间 + 版本；写入走控制台（权限、审批、灰度、审计）；客户端拿配置靠长轮询/watch（长连接推送实时性好但连接成本高，长轮询实现简单且天然带负载均衡）；客户端必须本地缓存落盘，配置中心全挂时用最后一份缓存照常启动——配置中心的可用性要求是比业务更高的“元服务”。
展开解析：关键设计决策：一致性取舍——配置变更不要求强一致，要求“最终收敛 + 可观测的版本”，每条配置带版本号，客户端上报自己生效的版本，控制台能看到“还有 3% 实例在旧版”；灰度发布——按实例 IP、标签、百分比分批生效，配自动回滚（关联错误率指标）；推拉结合——推（长连接触发）解决实时性，拉（定时全量比对版本）解决推送丢失，两者互补是工业界标准做法（Apollo、Nacos 皆然）。客户端细节：长轮询的 hold 时间（30~60s）与随机抖动防惊群；启动时阻塞拉取关键配置还是允许默认值先跑，按配置的关键性分级。安全：配置含密钥时加密存储 + 按应用授权读取 + 审计；变更操作双人与审批。规模化：百万级客户端时推送层是无状态连接集群（按一致性哈希分片管理订阅关系），写少读多让存储层简单——MySQL + 缓存足够，别为配置上分布式存储。
追问方向：配置推送风暴如何防抖？配置中心的容灾（多机房）怎么做？
（约 480 字）