怎么借助配置中心ACM加速企业IT服务快速迭代，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
有了配置中心以后，用户或者管理员不需要再登录到配置中心或者配置中心下面的操作系统去修改文件。取而代之的是到配置中心的平台上去修改对应的配置，那么配置会对后面不同的应用监听到，当配置或者应用启动要去获得配置的时候，通过配置中心和应用的交互来完成任务的分发。通过这种方式极大的提高了修改配置的这种效率、简化了流程。
应用配置管理(Application Configuration Management，简称 ACM)，ACM是由阿里中间件配置中心工具Diamond延伸出来的，在阿里内部为被使用最广泛的中间件，于2017年10月正式成为阿里云产品。
ACM 来自于阿里配置中心管理工具Diamond，那么Diamond在阿里内部到底是什么情况呢？主要是几点，第一点Diamond可能是阿里内部应用最广泛的中间介，覆盖量大概是80%，主要是因为他使用场景是非常多的。作为一个配置中心工具，在阿里内部有极好的性能保证，对内承诺的SLA是保证在1秒以内，这个对很多上层的业务提供了能力的保证。当机房发生故障的时候，通过配置中心去推配置能保证很多的工作负载能在1秒钟之内就能完成迁移。还有很多其他各种各样的场景，比如说通过非常方便的运维能力能帮助集团的很多其他业务去做类似于限流降级。还有去做一些算法的场景，还有去做多环境管理，应用场景非常多，所以说这个是目前配置中心管理在阿里内部的一个使用现状。
在外部来看同时期配置中心在行业的走向的历史情况是什么样的，到今天配置中心已经完成了从原始的无工具到有工具，成为公有云上面一个正式产品的一个历史发展路径。从业界的发展历程来看，配置中心已经完成了从没有工具到有工具再到正式产品化的一个发展历程。
有了配置中心以后用户不需要登陆到机器上去改配置文件，取而代之的是他到配置的管理控制台上去发布一个配置，相应的配置会写到配置中心的服务器上，服务中心会把不同的配置推送到下面的应用上去。所以沉淀下来三个基本功能，第一个是发布配置，第二个是获取配置，第三个是动态配置的变化监听。
ACM的服务端主要由三部分组成，第一个是地址服务器，提供ACM (Diamond)服务发现功能，实现了集群扩容、下线等运维工作对于应用方的透明。第二个是ACM(diamond)-server组件，是ACM服务的核心。该组件通过Http协议向应用方提供配置的持久化管理、动态配置推送服务。实现上，ACM(diamond)-server组件是一个Web服务集群，集群节点间通过特定机制实现数据变更的增量同步，是无中心化的结构。第三个是Mysql存储，是ACM(Diamond)服务持久化配置管理的基础。在淘宝生产环境中，使用一主两备的部署方式保障数据的安全。
总结来说，ACM的设计，使用集群代替中心，做到无单点，以此提高系统的可靠性；使用Http无状态协议暴露服务，使系统实现逻辑简单，不易出错。
ACM (Diamond) 的持久化配置保存在mysql中，额外的服务端每个节点都以本地磁盘文件的形式保存了全量的配置数据作为cache。引入服务端配置数据的缓存文件后，一次配置数据的读取请求，其实就是一次静态文件的Http请求。借助0拷贝的优化，减少了配置数据在应用态和内核态之间无用的内存拷贝，大大提升了数据传输效率。
引入cache机制后，ACM (Diamond)在实现上可以被定为一个分布式的缓存系统。在CAP方面，ACM (Diamond)选择牺牲数据的强一致，提供了最终一致性；保证了系统的可用性和分区容忍性。通过实践也证明了，提供最终一致性的配置并发读写，可以满足几乎所有的配置中心应用场景。
配置监听需要达到的效果跟发布和获取有点不一样，一个配置发生变化了，怎么通过一个类似消息的方式把变化推送到客户端，客户端能及时知道变化了，同时内部采取一些相应的动作。我们做的是一种类似于长轮询的方式的方式去做，客户端会定期的在发起监听的这个配置的时候会发起一个30秒的长连接，这个长连接会带到他所需要配置，如果在这30秒里面没有配置发生变化的时候，那么30秒内就返回一个空值，在接下来的下一个30秒会再发起一个连接。那么在这30秒内如果是发现了任何的变化的时候，服务端会把发生变化的配置及时的通过长连接，然后连接会返回这个客户端，客户端就可以拿到这个变化值。这种推拉结合的策略，做到了在长连接和短连接之间的平衡，实现了让服务端不用太关注连接的管理，效果上又获得了类似TCP长连接的信息推送的实时性。
传统的配置文件无法很好的解决分布式系统的配置管理诉求，虽然ACM是个工具，但是具有大能量，因为能通过配置中心本身延伸出特别多的场景。对于配置安全管理、发布环境管理、程序包发布管理、业务场景动态推送、动态算法推送等方面ACM都可以很好的解决对应的需求。
在传统架构的应用发布过程中，修改一个应用配置就需要将整个应用重新打包发布，整个过程非常繁琐，且容易出错。在基于 ACM 的微服务场景下，应用的重要配置信息被发布到 ACM 中。新的配置发布并不依赖配置打包。在新版本的配置发布后，所有应用立即生效，如图所示。
采用 ACM 作为配置中心为微服务带来的好处是，所有配置中心化，在应用众多的情况下配置管理变得更加方便。所有配置不依赖版本发布，使得配置变更更加灵活。ACM 天生支持灰度发布和回滚，使得配置的变更发布在微服务架构下变得更加安全。
怎么防止因为性能过载而导致的雪崩效应，一定是要做些动态的流控的。传统方法是去改配置文件，有了配置中心以后可以把相应的配置的变更也是呈现在配置中心里，那么当流控发生变化的时候只需要在配置中心里面改流控的阈值，阈值会动态的推到下面所有订购阈值的客户端，那么这样就会做到一个相应的流控。
采用ACM为分布式架构下的服务治理带来的好处是，良好的性能，通过采用配置推送的方式来监听服务治理信息，对性能几乎无影响。相关的服务治理信息可以秒级推送到，响应时间迅速。当限流降级以后还可以通过秒级配置回滚来恢复状态。
现在的电商总会有一些的运营活动，比如说六一儿童节就会在相应的时间段推一些和小朋友相关的产品。最常规的方法大家马上会想到的可能是做一个新的发布，到那个时间点推一批应用上去，这样应用程序就会相应的变更。但是用了配置中心以后，这一过程会得到非常大的简化。具体的就是把对应的场景写到配置中心里，在服务端展示的业务代码里面，其实是订阅配置中心里一段的代码，代码如果需要根据场景发生变化的时候把这个代码在配置中心进行一个变更，所有的业务代码会及时的推送到服务器中，那么对应的场景就会发生变更。通过这种方式大大降低了发布的频次提高了业务的敏捷性。
这是业界做监控非常典型的一个例子，我们在做性能监控的时候，会有操作系统和应用的数据通过消息对进到流计算里做一些汇总。监控的时候实时报警怎么做？在做计算的时候分布式节点很多，当报警的阈值发生变更的时候是需要通知到所有的节点的。在这块阿里也是通过配置中心去做的，应用计算参数动态配置，动态生效，生效时间块，性能影响低。
在异地多活里面有很多场景会用到ACM，这里只讲一个简单的例子。在阿里巴巴内部，容灾多活架构的核心算法，ID分片和对应的的路由规则均采用ACM来动态推送。其中，相应的客户端和服务端，如RPC，MQ，DB都植入了路由路径。当容灾演练或者真实灾难发生时，管理员只需要动态的推送规则，相应的规则会影响到所有架构组件。使得基础架构和容灾逻辑解耦，具体的路由逻辑由容灾规则切换决定。生效快，理论上容灾的切换规则可以秒级推送到十万级别机器。
Demo
在对用户进行用户中心改造的时候发现用户有两点需求，第一点是从运维效率去考虑，将配置变更从之前的几个小时的级别变成几分钟到几秒的级别，带来了效率的极大提升，运维成本的大幅下降。第二点是安全的诉求。
为什么用了配置中心以后它的代码里面就不需要出现这些敏感信息了？
使用配置中心之后把这些业务的数据全部抽离出来，放到配置中心里，发布之后所有的这些镜像都是一样的，当需要配置变更的时候只需要到控制台去修改发布即可。
在ACM上把发布环节跳过的话，怎么保证配置能快速回滚，怎么能记录历史发布记录？
ACM在这方面做了一个历史版本的特性，当用户需要改错的时候，可以去查之前发布的历史版本，找到对应的版本点进去立即回滚就可以回到之前的版本。
关于怎么借助配置中心ACM加速企业IT服务快速迭代问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注亿速云行业资讯频道了解更多相关知识。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
