目录
一、传统服务配置面临的问题
1.1 本地静态配置
在传统应用配置中，往往基于本地xml、properties、远程DB存储、远程GIT存储等方式实现应用配置文件的配置和存储，一般都是采⽤本地静态配置的方式，导致运⾏时⽆法动态修改。
1.2 配置格式不统一
同一个公司不同部门开发的应用之间，使用的配置方式千差万别，往往依据个人习惯去选择配置方式，有的采用xml方式配置，有的采用properties方式配置，有的使用DB进行存储配置，有的使用GIT进行存储，配置方式不统一，难以管理。
1.3 生产事故
由于缺乏统一的应用配置管理，在生产部署中，容易将⾮⽣产配置带到⽣产环境，引发生产事故。
1.4 配置修改困难
缺乏统一配置中心进行配置管理，使用本地存储方式时（如本地xml，properties），往往需要到部署服务的节点去修改配置文件，部署多台节点时，修改配置费时费⼒，周期⻓。
1.5 缺少安全审计和版本控制能⼒
使用传统本地xml、properties的配置方式，哪怕使用DB存储，GIT存储方式，也只会存储最后修改的那一份，遇到问题无法及时回滚，且没有修改日志，出现问题，⽆法追溯责任⼈，⽆法得知修改内容，⽆法确定修改时间。
以上这些问题，在传统应用配置的方式下，都无法解决，应⽤配置中⼼应运⽽⽣。下面我们介绍一下应用配置的使用场景。
二、应用配置的使用场景
2.1 动态调整日志级别
在特定的场景下，您可以针对性地动态调整日志级别，以便输出更多的日志信息排查线上问题，或是减少日志打印带来的性能消耗。功能开关提供了在应用运行时动态修改日志级别的功能，在不同的应用场景下，您可以随时调整日志的级别，得到更有效的日志信息。
在开发Java程序时，我们经常会用到各种各样的日志框架。为了避免在程序正常运行时输出不必要的信息，我们在使用日志框架时会设置默认的日志级别。而程序在线上运行时，我们需要在特定的场景下针对性地动态调整日志级别。
2.2 配置项组合更新
可按不同场景批量更新组合配置项，所谓组合配置项指具有一组相互关联业务语义的配置项，如页面公告中时间、标题、内容等，商品特殊优惠配置中价格、优惠折扣等。
下图以'商品优惠配置'为例进行说明。
'商品优惠配置'在不同场景下优惠对象、优惠折扣及价格等各不相同，将'商品优惠配置'涉及的配置项组合，在不同场景下设置不同内容，可在不同场景下快速切换，同时省去繁琐校验过程，避免出错。
2.3 开关驱动开发
以开关方式控制代码执行逻辑，用于新功能快速验证，在出现问题时可及时回退。相比复杂的系统发布，投入成本较低，可结合DevOps机制进行实践。
如下图所示，当执行逻辑触发时访问对应的开关配置查看配置是否打开，从而决定是否执行新功能。
可用于A/B测试、环境隔离等场景。
2.4 金丝雀(灰度)发布
通过配置项控制应用接收流量，在灰度验证后，可及时回退或全线切流。
介绍完使用场景，我们来看下目前市面上支持的配置管理方案。
三、应用配置解决方案介绍
3.1 SpringCloud-Config
3.1.1 介绍
Spring Cloud Config 是Spring Cloud 微服务自带的应用配置解决方案，我们可以通过Spring Cloud Config实现配置的管理，不过Spring Cloud Config是基于文件的方式实现的配置管理。一般都是采用Git作为存储介质，或者采用DB作为存储介质实现。
3.1.2 优点
3.1.2.1 支持版本管理（基于Git）
目前仅支持基于Git存储介质方式实现配置文件的版本管理。
3.1.2.2 配置回滚（基于Git）
目前仅支持基于Git存储介质方式实现配置文件的配置回滚。
3.1.2.3 权限管理
依赖Git的权限体系实现权限管理，虽说粒度比较粗，但是起码具备
3.1.2.3 多集群、多环境支持
支持多集群、多环境配置
3.1.3 缺点
3.1.3.1 不能开箱即用，需要自己实现存储
3.1.3.1.1 基于GIT实现存储
3.1.3.1.1.1 Git的权限控制是个坑
Git的权限管理是说控制用户能不能Push或者Delete分支，或者能不能Push代码，而不是能不能访问某个目录的文件。对目录和文件的可读是Git的最基本要求，不可能做到针对目录级别的不可读。
因此如果直接使用，会出现这样一种情形
不同团队之间可以互看对方配置！
于是，可能会有如下情形发生
A团队同事A:"小B,这个地方不懂怎么配？"
A团队同事B:"去看看B团队的配置，直接贴过来。"
然后B团队就会发现自己的中间件里总是会多出一些莫名奇妙的数据！
当然，你可以禁止研发直接登陆Git改配置。然后呢，基于Git研发一套配置管理系统，在上面做权限控制，但是又有几个公司这么做呢？因为，这可能带来第二个问题。
3.1.3.1.1.2 粒度问题
将配置信息放在Git中，有一个致命问题:粒度太粗了！
你每次对一条配置发生crud的操作，其带来的影响是整个文件发生变动。如果将来我们需要对某条配置做灰度发布，基于Git来做是比较麻烦的。
3.1.3.1.2 基于数据库实现存储
那么，当时我们最理想的存储介质就是数据库，将配置信息放在数据库里有**两个好处**
- 基于数据库开发一套配置管理系统，显然比基于git来开发容易的多！
- 将配置放在数据库里，每条配置对应数据库的表中的一条记录。这么做粒度够细，针对某些重要的配置，做灰度发布，实现起来就容易很多。
因此，我们采用数据库作为存储介质。庆幸的是，这一点在Spring-Cloud-Config中是支持的。在该组件下，只需要设置
spring.profiles.active=jdbc
就能够激活jdbc模式。
3.1.3.1.2.1 刷新机制的坑
但是，我们又会发现一个更大的问题，**Spring-Cloud-Config的刷新机制是个坑！**
一个配置中心应该要能够做到，配置发生改动的时候，项目能够自动感知，自动更新配置才对。在Spring-Cloud-Config中，这套机制是借助一些代码仓库（SVN、Github等）提供的Webhook机制加上Spring-Cloud-Bus来实现的。
在Webhook中配置一个回调地址，刷新流程如下图所示：
OK，那么问题又来了！
(1) 配置数据放在数据库中，数据库里没有Webhook这种东西啊，怎么做到实时刷新？
(2) Spring-Cloud-Config的这套刷新机制依赖于消息总线，依赖于消息队列，存在延迟的情况!且依赖于消息队列的可用性，系统的复杂度大大增加。如果生产环境上消息队列出问题了，我们的刷新功能就会受到影响！
3.1.3.2 不支持多语言
目前只支持Java语言，多语言支持这块的功能欠缺。
3.1.3.3 不支持格式校验
配置文件格式校验功能欠缺。
3.1.3.4 单机并发读写能力不足
目前经过专业的测试进行压测，发现单机下读写文件能力并发为一千以内，并发读能力不强
3.1.4 总结
动态配置能力弱，调整配置需要重新部署，添加代码比较多；治理能力弱；安全审计能力弱；不算严格企业级，适用于小型项目（基本上就是没得选才会选它！）。
3.2 Togglz
3.2.1 介绍
Togglz 是 Java 的 Feature Toggles 模式的实现。功能切换非常有用。Feature Toggles 是持续部署和交互中非常普遍的敏捷开发实践。Togglz 可以切换用户正在执行的各种新特性，在应用运行时允许启用或者禁用某些特性，即使对于个人用户也是支持的。
官网地址：
Togglz - Features flag for Java
3.2.2 缺点
3.2.2.1 配置时效性
本身不具备，动态配置需要自行实现可靠消息推送。
3.2.2.2 简单配置（⽂本、开关）
场景支持度有限，仅可以当做bool类型的开关。不支持复杂类型的业务配置。
3.2.2.3 对微服务生态的支持
本身不支持，无开箱即用的功能支持，需要自己扩展。
3.2.2.4 代码入侵性
代码入侵性高，需要基于编码实现。
3.2.3 总结（不适合微服务场景）
配置时效性需要自身实现，且功能单一，只支持简单的bool类型开关配置，不支持复杂业务类型的配置，对微服务天生不友好，且代码入侵性高，总结起来就是比SpringCloud Config还不如，哈哈哈！
3.3 Apollo
3.3.1 介绍
Apollo（阿波罗）配置中心基于对携程框架部的分布式配置中心的二次开发，同步了AECORE规范的权限管理，实现了配置中心服务端的认证，从而能集中化的管理应用的各项配置，且配置修改后能够实时推送到应用端，适用于微服务配置管理场景。
官网地址：
产品介绍 | Apollo配置中心 (glodon.com)
3.3.2 优点
3.3.2.1 配置修改实时生效（热发布）
用户在Apollo修改完配置并发布后，基于HTTP长轮询机制，客户端能实时（1秒）接收到最新的配置，并通知到应用程序。
3.3.2.2 支持版本管理与回滚
版本发布管理，所有的配置发布都有版本概念，从而可以方便的支持配置的回滚。
3.3.2.3 完善的权限管理机制
应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。
3.3.2.4 配置灰度能⼒
支持全链路灰度发布配置能力
3.3.2.5 多集群、多环境支持
支持多集群、多环境配置
3.3.2.6 多语言支持
基本支持目前市面上主流的开发语言，并且提供了Open API
3.3.2.7 配置格式校验
支持对配置文件格式的校验
3.3.2.8 单机并发读写能力强
目前经过专业的测试进行压测，单机并发读在一万左右，单机并发写在两千以内，并发读写能力强
3.3.2.9 支持分布式集群部署
支持分布式集群部署，扩展能力强
3.3.3 缺点
3.3.3.1 不支持复杂业务类型配置
不支持对复杂业务类型规则的配置
3.3.3.2 代码侵入性方面
SDK ⽅式低侵⼊；Java Agent⽅式⽆侵⼊，但功能存在问题。
3.4 Nacos
3.4.1 介绍
Nacos 是 Dynamic Naming and Configuration Service的首字母简称，一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。
Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。
官网地址：
3.4.2 优点
3.4.2.1 多语言支持
基本支持目前市面上主流的开发语言，如Java、C++，Go，Python，NodeJs，C#等主流语言，并且提供了相关SDK集合和Open API支持
3.4.2.2 配置灰度能⼒
支持全链路灰度发布配置能力
3.4.2.3 多集群、多环境支持
基于Namespace、Group、ServerId/DataID的数据领域模型，实现多集群、多环境配置的支持
3.4.2.4 配置格式校验
支持对配置文件格式的校验
3.4.2.5 配置修改实时生效（热发布）
用户在Nacos控制台修改完配置并发布后，基于HTTP长轮询机制，客户端能实时（1秒）接收到最新的配置，并通知到应用程序（消息推送+HTTP长轮询机制）。
3.4.2.6 支持版本管理与回滚
版本发布管理，所有的配置发布都有版本概念，支持查看修改历史，从而可以方便的支持配置的回滚。
3.4.2.7 完善的权限管理机制
应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。且支持身份识别，访问控制，角色管理等功能。
3.4.2.8 日志审计功能
提供日志审计功能，方便问题追踪和溯源，且提供扩展接口方便与不同公司审计系统打通
3.4.2.9 单机并发读写能力强
目前经过专业的测试进行压测，单机并发读在一万五左右，单机并发写在两千以内，并发读写能力强
3.4.2.10 支持分布式集群部署
支持分布式集群部署，扩展能力强
3.4.3 和Apollo对比
3.4.3.1 发布时间上
Apollo 发布与 2016年5月，Nacos 发布于2018年6月，相比较而言，Apollo出现得更早些，所以在Nacos没出来之前，基本都是选用得Apollo。
3.4.3.2 生态支持上
Nacos 生态支持更好，特别是Alibaba 参与了Spring Cloud 微服务得开源后，Nacos 是Spring Cloud Alibaba 微服务开源的配置中心，负载微服务注册发现、配置管理、服务管理的职责，使用者越来越多。
Nacos 服务生态图：
3.4.3.3 功能上
Nacos除了充当配置中心外，还充当着服务注册中心，进行着服务的管理，它相当于是集成了配置中心、注册中心、服务管理中心等功能，功能比Apollo更丰富些。
总的来看，Nacos和Apollo相对于Spring Cloud Config的生态支持更广，在配置管理流程上做的更好。Nacos相比Apollo，在支持的功能上更丰富，面对的场景也更多，使用起来也相对比较简洁，在对性能要求比较高的大规模场景更适合。虽然Nacos起步晚，但是随着Spring Cloud Alibaba微服务方案的开源，相信未来会有越来越多的人使用Nacos。
3.5 PolarisMesh
3.5.1 介绍
北极星是腾讯开源的服务治理平台，致力于解决分布式和微服务架构中的服务管理、流量管理、配置管理、故障容错和可观测性问题，针对不同的技术栈和环境提供服务治理的标准方案和最佳实践。
官网地址：
3.5.2 优点
3.5.2.1 多语言支持
支持目前市场上主流的开发语言，如Java、C++，Go等主流语言，并提供了相关语言SDK集成包和相关Open API支持。
3.5.2.2 配置灰度能力
支持蓝绿发布，金丝雀发布，全链路灰度发布等
3.5.2.3 多集群、多环境支持
PolarisMesh 基于Namespace + FileGroup + File 的模式实现配置环境的隔离，很好的支持了多环境场景，且支持高可用的集群安装架构模型，支持多级的容灾架构，通过 Namespace 可以逻辑隔离环境、集群。
3.5.2.4 配置修改实时生效
用户在PolarisMesh控制台修改完配置并发布后，基于HTTP长轮询机制，客户端能实时（1秒）接收到最新的配置，并通知到应用程序（消息推送+HTTP长轮询机制）。
3.5.2.5 支持版本管理与回滚
版本发布管理，所有的配置发布都有版本概念，支持查看修改历史，从而可以方便的支持配置的回滚。
3.5.2.6 完善的权限管理机制
应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。且支持身份识别，访问控制，角色管理等功能。PolarisMesh基于命名空间和服务资源维度实现权限管控。
3.5.2.7 日志审计功能
提供日志审计功能，方便问题追踪和溯源
3.5.2.8 单机并发读写能力强
目前经过专业的测试进行压测，单机并发读在一万八左右，单机并发写在三千以内，并发读写能力强
3.5.2.9 支持分布式集群部署
持高可用的集群安装架构模型，支持多级的容灾架构。
3.5.3 和Nacos对比
3.5.3.1 性能对比上
3.5.3.1.1 Nacos 性能测试情况
更多测试详细，参考Nacos 性能测试报告：
3.5.3.1.2 PolarisMesh性能测试情况
更多测试详细，参考PolarisMesh 性能测试报告：
##### 3.5.3.1.2 总结
单纯从测试报告上看，PolarisMesh 似乎在性能表现上更好，但是PolarisMesh 依赖的组件更多，除了数据库，还依赖了Redis缓存，所以其实它性能表现好些，也说的过去。Nacos相对较简单些。
3.5.3.2 功能对比
3.5.3.2.1 Nacos 功能
Nacos 的核心功能是服务发现、服务管理、配置管理等
3.5.3.2.2 PolarisMesh 功能
PolarisMesh的核心功能是服务发现，服务管理、配置管理、流量管理和服务熔断等
3.5.3.2.3 总结
如果选型但看配置管理方面的功能的话，其实PolarisMesh 和 Nacos提供的服务支持是差不多一样的，在服务管理和服务注册发现方面，也都差不多，但是PolatisMesh 还集成了流量管理和服务熔断方面的内容，是一个一体化方案，而Nacos 还需要单独加上Sentinel才具备流量管理和服务熔断方面的内容。但是在流量管理和服务熔断方面，我觉得Sentinel更专业。
3.5.3.3 生态环境上
3.5.3.3.1 Nacos
Nacos 是阿里提供的微服务生态里面的控制面，主要提供微服务服务的注册、发现、服务管理、配置管理中心等功能，支持Spring 、SpringBoot 、SpringCloud、Dubbo等技术生态，而且得益于阿里开源的Spring Cloud Allibaba（加入了Apache），所以他的受众面更广。
3.5.3.3.2 PolarisMesh
PolarisMesh 是腾讯提供的微服务生态，主要提供微服务服务的注册、发现、服务管理、配置管理中心、流量管理中心、服务熔断等功能，支持Spring 、SpringBoot 、SpringCloud、Dubbo等技术生态，而且在国内，腾讯也开源了自己的微服务技术方案Spring Cloud Tencent，但是没有加入Apache孵化，相对受众面来说，只是国内。
在PolarisMesh 的官网上，也提供了和相关竞品的对比分析，有兴趣可以去看下，地址：
以上介绍的方案，都是基于开源组件实现的，如果你不想自己购买服务器搭建这些基础设施，且觉得后期维护麻烦，也可考虑商业产品，下面为大家介绍亚马逊AppConfig和阿里MSE两款商业化产品。
3.6 商业化产品
3.6.1 AWS AppConfig
3.6.1.1 介绍
AWS AppConfig功能标志和动态配置可帮助软件开发者快速安全地调整生产环境中的应用程序行为，而无需部署完整的代码。 AWS AppConfig加快软件发布频率，提高应用程序弹性，并帮助您更快地解决紧急问题。借助功能标志，您可以逐步向用户发布新功能并衡量这些更改的影响，然后再将新功能完全部署到所有用户。借助操作标志和动态配置，您可以更新阻止列表、允许列表、限制限制、记录详细程度以及执行其他操作调整，以快速响应生产环境中的问题。
附上官网地址，有兴趣的自己去看看吧！
中文官网：
什么是 AWS AppConfig？ - AWS AppConfig (amazon.com)
3.6.2 阿里 MSE
3.6.2.1 介绍
微服务引擎 ( Microservice Engine, 简称：MSE ) 是微服务注册中心和配置管理的全托管式平台，提供高可用且免运维的服务注册和配置管理集群，如 ZooKeeper、Nacos 和 Eureka 等，完全兼容开源产品标准接口，无需代码修改开箱即用，并为客户提供相应的监控和运维工具。
3.6.2.2 优点
3.6.2.2.1 无侵入性
应用通过Agent方式接入MSE，连接应用配置服务，无需对应用做任何改造，真正做到无侵入。
3.6.2.2.2 实时配置刷新
态配置，开箱即⽤，可靠推送，实时⽣效，登录控制台即可对应用配置进行管理，按需推送配置项，支持按节点推送与全局推送方式。
3.6.2.2.3 配置持久化
应用配置服务通过ACM组件持久化配置项，保障配置项高可靠性。应用在重启或扩容阶段可读取持久化配置。
3.6.2.2.4 复杂配置项支持
在复杂数据类型⽀持⽅⾯较为完善，⽆需遵守较为繁琐的配置项规则。
3.6.2.2.5 配置灰度能⼒
支持全链路灰度发布配置能力
3.6.2.2.6 可观测能⼒
⽩屏化观测能⼒，控制台可观测各接⼊节点的实时⽣效值和分布情况。
好了，本次分享就到这里，如果帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！
1409
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
