传统应用配置的问题
- 采用本地文件静态配置
运行时无法动态修改
- 配置散乱格式不标准
有的是Xml,有的是Properties,有的是DB
- 易产生生成环境事故
将测试环境配置引入生产环境
- 配置修改麻烦,周期长
应用集群部署很多时,修改配置费时费力,且要经过不同的环境验证测试
- 缺少安全审计,权限管理, 版本控制
配置中心解决的办法
- 集中式配置管理,所有的配置都放在配置中心
- 配置中心统一管理格式,用户不必关系格式
- 各个环境配置隔离,不同环境不同配置, 配置错误可以立即修改,实时生效
- 配置中心修改一次,通知所有客户端
- 角色权限清晰,修改记录可追溯
现代配置的核心需求
1. 交付件和配置分离
传统做法应用在打包部署时,会为不同环境打出不同配置的包,例如为开发 / 测试 /UAT/ 生产环境分别制作发布包,每个包里头包含环境特定配置。
现代微服务提倡云原生 (Cloud Native) 和不可变基础设施(Immutable Infrastructure)的理念,推荐采用如容器镜像这种方式打包和交付微服务,应用镜像一般只打一份,可以部署到不同环境。这就要求交付件(比如容器镜像)和配置进行分离,交付件只制作一份,并且是不可变的,可以部署到任意环境,而配置由配置中心集中管理,所有环境的配置都可以在配置中心集中配,运行期应用根据自身环境到配置中心动态拉取相应的配置。
2. 抽象标准化
企业应该由框架或者中间件团队提供标准化的配置中心服务 (Configuration as a Service),封装屏蔽配置管理的细节和配置的不同格式,方便用户进行自助式的配置管理。一般用户只需要关注两个抽象和标准化的接口:
-
配置管理界面 UI,方便应用开发人员管理和发布配置。
-
封装好的客户端 API,方便应用集成和获取配置。
3. 多环境多集群
现代微服务应用大都采用多环境部署,一般标准化的环境有开发 / 测试 /UAT/ 生产等,有些应用还需要多集群部署,例如支持跨机房或者多版本部署。配置中心需要支持对多环境和多集群应用配置的集中式管理。
4. 高可用
配置中心必须保证高可用,不能随便挂,否则可能大面积影响微服务。在极端的情况下,如果配置中心不可用,客户端也需要有降级策略,保证应用可以不受影响。
5. 实时性
配置更新需要尽快通知到客户端,这个周期不能太长,理想应该是实时的。有些配置的实时性要求很高,比方说主备切换配置或者蓝绿部署配置,需要秒级切换配置的能力。
6. 治理
配置需要治理,具体包括:
-
配置审计,谁、在什么时间、修改了什么配置,需要详细的审计,方便出现问题时能够追溯。
-
配置版本控制,每次变更需要版本化,出现问题时候能够及时回滚到上一版本。
-
配置权限控制,配置变更发布需要认证授权,不是所有人都能修改和发布配置。
-
灰度发布,高级的配置治理支持灰度发布,配置发布时可以先让少数实例生效,确保没有问题再逐步放量。
配置的分类
-
静态配置
- 环境配置
数据库,Redis,MQ 连接服务的字符串
- 安全配置
用户名,口令,令牌,许可证相关配置
2. 动态配置
- 应用配置
连接超时,请求超时,线程池,队列,Cache, 数据库连接各种参数,日志级别,限流和熔断的阈值,黑白名单,开发或者运维会根据应用的实际运行情况调整这些配置
- 开关配置(Feature Flag/Switch)
在英文中也称 Feature Flag/Toggle/Switch,简单的只有真假两个值,复杂的可以是多值参数。功能开关是 DevOps 的一种最佳实践,在运维中有很多应用场景,比如蓝绿部署,灰度开关,降级开关,主备切换开关,数据库迁移开关等。功能开关在国外互联网公司用得比较多,国内还没有普及开.
蓝绿部署的传统做法是通过负载均衡器切流量来实现,如下图左边所示。这种做法一般研发人员无法自助操作,需要提交工单由运维介入操作,操作和反馈周期比较长,出了问题回退还需运维人员介入,所以回退也比较慢,总体风险比较高。
蓝绿部署也可以通过配置中心 + 功能开关的方式来实现,如上图右边所示。开发人员在上线新功能时先将新功能隐藏在动态开关后面,开关的值在配置中心里头配。刚上线时新功能暂不启用,走老功能逻辑,然后开发人员通过配置中心打开开关,这个时候新功能就启用了。一旦发现新功能有问题,可以随时把开关关掉切回老功能。这种做法开发人员可以全程自助实现蓝绿部署,不需要运维人员介入,反馈周期短效率高。
常见做法,我们一般会在应用的过滤器层或者是网关代理层添加限流降级逻辑,并且和配置中心配合,实现限流降级开关和参数的动态调整。如果促销出现流量洪峰,我们可以通过配置中心启动限流降级策略
- 业务配置
和业务相关的一些配置,例如促销规则,贷款额度,利率等业务参数,A/B 测试参数等。一般产品运营或开发人员会根据实际的业务需求,动态调整这些参数。