众多项目研发过程中为了调试观察应用运行时表现，修改常量配置的场景下往往需要频繁地对应用代码及配置项做打包发布进行应用版本更新甚至回滚代码。基于该场景，任何的应用配置项变更都需要将整个应用重新打包发布，整个过程非常繁琐，且容易出错。
世界最大混合云的总架构师，4年前，开始作为双11阿里云技术负责人，负责搭建全球最大的混合云结构，把 “双11”的电商业务和技术场景在阿里云上实现，并保障这个混合云在双11当天能够满足全球客户的购物需求。
正文：
众多项目研发过程中为了调试观察应用运行时表现，修改常量配置的场景下往往需要频繁地对应用代码及配置项做打包发布进行应用版本更新甚至回滚代码。基于该场景，任何的应用配置项变更都需要将整个应用重新打包发布，整个过程非常繁琐，且容易出错。非常典型且具有代表性的是:Redis连接串配置，应用业务功能切换开关，应用的安全限流配置，数据库访问配置等等一系列。
在此引申一个切实场景：一批早期的数据库实例所在服务器都即将过保进行替换，新数据库实例的端口及用户名密码保持不变并且持续与老库保持数据同步，一个非常棘手的问题来了，若一个应用需要同时访问其中多个db实例，在切换的时候如何能做到快速的切到对应db的新实例上？尽可能缩短因切换全过程时间消耗而引起的业务系统不可用时长。
对于此，业界普遍解决方案是引入独立于应用之外的配置类服务系统，那么这类配置中心服务到底是如何应对这个棘手问题呢，同时具备哪些关键要素呢？
1.运行时动态调整配置项，业务代码感知配置变化并做出响应。
针对上述场景问题，对症下药。通过依托于配置中心服务，动态修改配置项并且业务代码及时感知到变化值，jdbc驱动能根据新的数据库连接串的变化并对新数据源发起连接请求操作，完美地解决数据库切换过程耗时长的问题，同理也能做到数据源的快速回切，比如发现待切换目标主库存在其他问题必须切回。
2.配置集中式管理，避免游离，杜绝配置项无对应owner。
作为应用owner，务必十分清楚自身应用需要哪些配置，分别是做什么用途的，配置的存在形态是什么。将这些原本存在于代码或静态properties配置文件的，梳理出来统一管理，这样做的好处是业务代码与配置项解耦，做到动配置而无需修改代码又避免发生遗漏。
3.配置层面的权限管理，特别是关键配置项不能谁都可以改动。
配置数据的安全性对应用至关重要，倘若是涉及到业务开关或是全局功能的配置，权限策略需要严格把控，比如淘宝大秒杀系统的时间，商品，库存等信息，是万万不可随意改动的。阿里云ACM配置中心服务结合RAM访问控制系统构建权限管理。
4.配置服务自身的容灾切换，高可用性等。
仔细剖析ACM的架构，这是一套分三层自下而上的高可用性和稳定性保障。首先从底层数据库存储主备容灾，再到ACM的主要服务层分布式集群可靠性，最后再是ACM客户端即应用侧的本地配置数据容灾。简单地说就是ACM的DB及应用服务都挂了，也不会立即影响到客户正在运行的应用系统，容灾发挥了重要作用。
那么从业务使用需求角度我该如何选型配置服务？
几款主流相似产品简介：
1.ZooKeeper 是一个分布式应用程序协调服务，是 Google Chubby 的开源实现。它是一个为分布式应用提供一致性服务的软件，提供的功能包括配置维护、域名服务、分布式同步、组服务等。在 Hadoop 集群等场景下，ZooKeeper 同时充当应用配置管理的角色。但是由于它是 CP（Consistency，Partition Tolerance） 类应用，因此在可用性和性能上都会受到一定影响。
2.ETCD和 ZooKeeper 类似，ETCD 是一个高可用的键值存储系统，主要用于配置共享和服务发现。ETCD 是由 CoreOS 开发并维护的，灵感来自于 ZooKeeper 和 Doozer。它使用 Go 语言编写，并通过 Raft 一致性算法处理日志复制以保证强一致性。etcd 和 ZooKeeper 类似，同样可以用来做应用管理配置。但是由于它是强一致的管理类应用，因此其可用性和性能在某些场景会受到一定影响。
3.Spring Cloud Config Server和 ACM 类似，Spring Cloud Config Server 为服务端和客户端提供了分布式系统的外部配置支持。配置服务器为各应用的所有环境提供了一个中心化的外部配置。与 ACM 不同的是，Spring Cloud 配置服务器默认采用 Git 来存储配置信息，其配置存储、版本管理、发布 等功能都基于 Git 或其他外围系统来实现。除此之外，在配置功能方面，ACM 和 Spring Cloud Config 也有很大不同。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
