阿里云ACM：云原生配置管理利器

摘要：在传统架构中，如果配置信息有变更，通常是登陆服务器手动修改配置来使配置生效。在微服务架构中，应用数和节点数由于微服务化数量激增，导致发布次数增加，配置变更难度加大，通常是将应用配置抽象出来放置在外部的配置中心里，从而实现配置变更的自动化，但这类原生方案会存在依赖严重、发布延时高的问题。

在传统架构中，如果配置信息有变更，通常是登陆服务器手动修改配置来使配置生效。在微服务架构中，应用数和节点数由于微服务化数量激增，导致发布次数增加，配置变更难度加大，通常是将应用配置抽象出来放置在外部的配置中心里，从而实现配置变更的自动化，但这类原生方案会存在依赖严重、发布延时高的问题。

Spring Cloud中的标准配置管理方法和存在的问题
以Spring Cloud为例，其提供了Spring Cloud Config组件来默认对配置进行管理。

关于Spring Cloud Config的工作原理，如下图所示：

和传统人肉到生产服务器上一台台手动修改配置的思路不同，在Spring Cloud中，当用户配置发生变化时，用户可以在Git中修改配置，再通过Spring Cloud Config Server动态下发配置，从而在各个机器上动态生效。其整个流程大概如下：

用户在Git中update和commit配置；
Spring Cloud Config Server通过回掉，获取更新配置；
用户在其中任一一台机器上执行配置刷新操作 (图中为 "post /bus/refresh")
目标机 (App A)在Config Server中拉取最新配置，并发送消息到消息总线中，通知其他机器配置被变更；
所有其他机器通过消息总线获知配置刷新后，在Config Server中拉取最新配置。
至此，配置修改完成。

Spring Cloud Config组件成功的以配置中心思路解决了静态配置繁琐的运维问题，但是Spring Cloud Config仍存在以下问题：

标准方案依赖Git。虽然提供其他存储支持，但是标准的Git方案饱受争议，毕竟Git运维在业界算是小众领域，在关键的生产环境中使用得并不多(开发测试环境除外)；
配置变更依赖Cloud Bus，架构复杂的同时，存在配置的一致性问题；
整个配置的时效性较低。由于发布路径长，中间存在多个异步操作，因此从发布到最后所有配置生效，延时可能会是分钟级别。
阿里云ACM为spring cloud带来的配置管理优化
阿里云应用配置管理服务ACM，作为Nacos的云上实现，可以将以上的配置管理问题进行优化，配置修改将变得异常简单和高效，如下图所示。

整个操作流程分为两步：

用户在ACM中修改配置内容;
ACM动态推送到所有应用中。
ACM全面兼容Spring框架接口，包括Spring Framework、Spring Boot和Spring Cloud，其为 Spring Cloud编写的应用配置管理，和Spring Cloud Config对比，由于极简的架构，带来了众多的好处：

配置变更推送性能高，根据阿里巴巴内部的性能统计来看，绝大多数情况下，配置推送0.5秒生效，99.9%场景下，3秒以内能推送到上千台机器；
运维简单，不需要额外的Git存储或Cloud Bus组件，单应用接口即可完成所有配置中心功能；
遵循开源精神，ACM作为Nacos的云上实现，用户无需额外付费即可使用全部功能。
Spring Cloud用户可以基于Spring Cloud Config提供的接口将Spring Cloud应用的配置管理无缝迁移到ACM上，大幅度提升基于Spring Cloud框架的微服务应用的配置管理敏捷性。此外，相比于Spring Cloud Config，ACM还拥有多项实用功能，例如，云上配置安全合规，配置灰度发布和回滚等。

如何快速部署ACM
使用Spring Cloud的用户在阿里云上如果要从Spring Cloud Config切换成ACM方案，在程序业务层代码无需任何改动，原生@Value标签直接有效。用户仅仅需要改动Spring Cloud应用的两个编译配置文件即可。

1、修改配置文件

在 bootstrap.properties中添加ACM的连接地址和认证信息，示例如下。其中，endpoint、namesspace、accessKey和secretKey等参数在ACM控制台上可以直接获取。