世界最大混合云的总架构师，4年前，开始作为双11阿里云技术负责人，负责搭建全球最大的混合云结构，把 “双11”的电商业务和技术场景在阿里云上实现，并保障这个混合云在双11当天能够满足全球客户的购物需求。
正文：
众多项目研发过程中为了调试观察应用运行时表现，修改常量配置的场景下往往需要频繁地对应用代码及配置项做打包发布进行应用版本更新甚至回滚代码。基于该场景，任何的应用配置项变更都需要将整个应用重新打包发布，整个过程非常繁琐，且容易出错。非常典型且具有代表性的是:Redis连接串配置，应用业务功能切换开关，应用的安全限流配置，数据库访问配置等等一系列。
在此引申一个切实场景：一批早期的数据库实例所在服务器都即将过保进行替换，新数据库实例的端口及用户名密码保持不变并且持续与老库保持数据同步，一个非常棘手的问题来了，若一个应用需要同时访问其中多个db实例，在切换的时候如何能做到快速的切到对应db的新实例上？尽可能缩短因切换全过程时间消耗而引起的业务系统不可用时长。
对于此，业界普遍解决方案是引入独立于应用之外的配置类服务系统，那么这类配置中心服务到底是如何应对这个棘手问题呢，同时具备哪些关键要素呢？
1.运行时动态调整配置项，业务代码感知配置变化并做出响应。
针对上述场景问题，对症下药。通过依托于配置中心服务，动态修改配置项并且业务代码及时感知到变化值，jdbc驱动能根据新的数据库连接串的变化并对新数据源发起连接请求操作，完美地解决数据库切换过程耗时长的问题，同理也能做到数据源的快速回切，比如发现待切换目标主库存在其他问题必须切回。
2.配置集中式管理，避免游离，杜绝配置项无对应owner。
作为应用owner，务必十分清楚自身应用需要哪些配置，分别是做什么用途的，配置的存在形态是什么。将这些原本存在于代码或静态properties配置文件的，梳理出来统一管理，这样做的好处是业务代码与配置项解耦，做到动配置而无需修改代码又避免发生遗漏。