Java面试要点:动态配置、灰度规则、版本回滚与开关治理
前言
配置中心和灰度发布是微服务生产治理的重要能力。面试常问:
- 配置修改后服务如何感知。
- 灰度发布怎么按用户或租户放量。
- 配置错误怎么回滚。
- 功能开关为什么不能乱用。
动态配置链路
sequenceDiagram
participant A as 管理后台
participant C as 配置中心
participant S as 业务服务
A->>C: 修改配置
C->>C: 保存版本
C-->>S: 推送变更
S->>S: 刷新本地缓存
配置类型
常见配置:
- 业务参数。
- 功能开关。
- 限流阈值。
- 白名单。
- 灰度规则。
- 第三方接口地址。
敏感配置要加密存储,权限单独控制。
推还是拉
| 方案 | 优点 | 缺点 |
|---|---|---|
| 客户端轮询拉取 | 简单 | 实时性差 |
| 服务端推送 | 实时 | 连接和可靠性复杂 |
| 推拉结合 | 稳定 | 实现成本中等 |
灰度规则
常见维度:
- 用户 ID。
- 租户 ID。
- 地区。
- 版本号。
- 设备类型。
- 百分比。
灰度发布步骤:
- 内部白名单。
- 小流量。
- 部分租户。
- 全量。
- 观察指标。
版本与回滚
配置必须有版本。
要求:
- 每次修改生成版本。
- 可查看差异。
- 可一键回滚。
- 有审批和审计。
功能开关治理
功能开关不能无限增长。
常见问题:
- 旧开关没人清理。
- 开关嵌套导致逻辑复杂。
- 生产配置被误改。
治理方式:
- 开关命名规范。
- 负责人。
- 过期时间。
- 清理机制。
高频面试题
配置中心为什么要有版本?
为了审计、回滚和定位问题。没有版本的动态配置很难在生产事故中快速恢复。
灰度发布为什么要按维度放量?
为了控制影响面,先让小范围用户验证,再逐步扩大。
配置实时推送失败怎么办?
客户端本地缓存兜底,定时拉取校验,异常时告警。
功能开关有什么风险?
开关过多会造成逻辑分叉和维护困难,需要生命周期治理。
总结
配置中心和灰度发布的重点是动态生效、版本管理、权限审计、灰度规则和快速回滚。它是生产稳定性的基础设施,不只是一个 key-value 管理页面。
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 Junly博客!
评论


