一、什么是配置
- 配置是独立于程序的只读变量
- 配置首先是独立于程序的，同一份程序在不同的配置下会有不同的行为。
- 其次，配置对于程序是只读的，程序通过读取配置来改变自己的行为，但是程序不应该去改变配置。
- 常见的配置有：DB Connection Str、Thread Pool Size、Buffer Size、Request Timeout、Feature Switch、Server Urls等。
- 配置伴随应用的整个生命周期
- 配置贯穿于应用的整个生命周期，应用在启动时通过读取配置来初始化，在运行时根据配置调整行为。
- 配置可以有多种加载方式
- 配置也有很多种加载方式，常见的有程序内部hard code，配置文件，环境变量，启动参数，基于数据库等
- 配置需要治理
- 权限控制
- 由于配置能改变程序的行为，不正确的配置甚至能引起灾难，所以对配置的修改必须有比较完善的权限控制
- 不同环境、集群配置管理
- 同一份程序在不同的环境（开发，测试，生产）、不同的集群（如不同的数据中心）经常需要有不同的配置，所以需要有完善的环境、集群配置管理
- 框架类组件配置管理
- 还有一类比较特殊的配置 - 框架类组件配置，比如CAT客户端的配置。
- 虽然这类框架类组件是由其他团队开发、维护，但是运行时是在业务实际应用内的，所以本质上可以认为框架类组件也是应用的一部分。
- 这类组件对应的配置也需要有比较完善的管理方式。
二、为什么需要配置中心（集中配置）
程序的发展，需要引入集中配置：
随着程序功能的日益复杂，程序的配置日益增多：各种功能的开关、参数的配置、服务器的地址……
并且对配置的期望也越来越高，配置修改后实时生效，灰度发布，分环境、分集群管理配置，完善的权限、审核机制……
并且随着采用分布式的开发模式，项目之间的相互引用随着服务的不断增多，相互之间的调用复杂度成指数升高，每次投产或者上线新的项目时苦不堪言，因此需要引用配置中心治理。
配置需要实时生效需求：统一维护、环境隔离、实时生效
三、主流的配置中心
1、百度Disconf
已经不维护
2、淘宝diamond
已经不维护
3、spring cloud config
2014年9月开源，Spring Cloud 生态组件，可以和Spring Cloud体系无缝整合。Spring Cloud Netfix生态常用
4、携程 apollo
2016年5月，携程开源的配置管理中心，具备规范的权限、流程治理等特性
5、spring cloud alibaba生态nacos
2018年6月，阿里开源的配置中心，也可以做DNS和RPC的注册中心与服务发现。Spring Cloud Alibaba生态常用
四、配置中心详述
4.1 Spring Cloud Config
1、依赖git仓库作配置存储
2、环境划分：git的分支、分支内创建不同目录，共2层环境划分。还可以利用分支内创建子文件再对环境进行细分
/{application}/{profile}[/{label}]
/{application}-{profile}.yml
/{label}/{application}-{profile}.yml
/{application}-{profile}.properties
/{label}/{application}-{profile}.properties3、自动刷新依赖于git的webhook或spring cloud消息总线，依赖较重且配置复杂
4、没有权限控制与审计
5、不支持灰度
6、没有统一的版本管理
7、没有友好界面，开源界面配置极其复杂
8、更适用于spring cloud 生态，不支持原生java客户端
9、利用git仓库根路径文件做common配置
10、回滚依赖git
4.2 Apollo
4.2.1 Apollo特性
1、统一管理不同环境、不同集群的配置
- Apollo提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。
- 同一份代码部署在不同的集群，可以有不同的配置，比如zk的地址等
- 通过命名空间（namespace）可以很方便的支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖
- 配置界面支持多语言（中文，English）
2、配置修改实时生效（热发布）
- 用户在Apollo修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序。
3、版本发布管理
- 所有的配置发布都有版本概念，从而可以方便的支持配置的回滚。
4、灰度发布
- 支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例。
5、权限管理、发布审核、操作审计
- 应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。
- 所有的操作都有审计日志，可以方便的追踪问题。
6、客户端配置信息监控
- 可以方便的看到配置在被哪些实例使用
7、提供Java和.Net原生客户端
- 提供了Java和.Net的原生客户端，方便应用集成
- 支持Spring Placeholder，Annotation和Spring Boot的ConfigurationProperties，方便应用使用（需要Spring 3.1.1+）
- 同时提供了Http接口，非Java和.Net应用也可以方便的使用
4.2.2、基础模型
如下即是Apollo的基础模型：
- 用户在配置中心对配置进行修改并发布
- 配置中心通知Apollo客户端有配置更新
- Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用
4.2.3、架构模块
下图是Apollo架构模块的概览，详细说明可以参考Apollo配置中心架构剖析。
上图简要描述了Apollo的总体设计，我们可以从下往上看：
- Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端
- Admin Service提供配置的修改、发布等功能，服务对象是Apollo Portal（管理界面）
- Config Service和Admin Service都是多实例、无状态部署，所以需要将自己注册到Eureka中并保持心跳
- 在Eureka之上我们架了一层Meta Server用于封装Eureka的服务发现接口
- Client通过域名访问Meta Server获取Config Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Client侧会做load balance、错误重试
- Portal通过域名访问Meta Server获取Admin Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Portal侧会做load balance、错误重试
- 为了简化部署，我们实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中
4.2.4、发布配置流程
- 用户在Portal操作配置发布
- Portal调用Admin Service的接口操作发布
- Admin Service发布配置后，发送ReleaseMessage（写入数据到mysql）给各个Config Service
- Config Service收到ReleaseMessage（单线程每秒扫描mysql）后，通知对应的客户端
4.2.5、客户端设计
- 客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。（通过Http Long Polling实现）
- 客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。
- 这是一个fallback机制，为了防止推送机制失效导致配置不更新
- 客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified
- 定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property:
apollo.refreshInterval来覆盖，单位为分钟。
- 客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中
- 客户端会把从服务端获取到的配置在本地文件系统缓存一份
- 在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置
- 应用程序可以从Apollo客户端获取最新的配置、订阅配置更新通知
4.2.6、权限管理
管理员权限：
- 可以管理项目的权限分配
- 可以创建集群
- 可以创建Namespace
编辑、发布权限：
编辑权限允许用户在Apollo界面上创建、修改、删除配置
- 配置修改后只在Apollo界面上变化，不会影响到应用实际使用的配置
发布权限允许用户在Apollo界面上发布、回滚配置
- 配置只有在发布、回滚动作后才会被应用实际使用到
- Apollo在用户操作发布、回滚动作后实时通知到应用，并使最新配置生效
项目创建完，默认没有分配配置的编辑和发布权限，需要项目管理员进行授权。
4.2.7、可用性考虑
| 场景 | 影响 | 降级 | 原因 |
|---|---|---|---|
| 某台Config Service下线 | 无影响 | Config Service无状态，客户端重连其它Config Service | |
| 所有Config Service下线 | 客户端无法读取最新配置，Portal无影响 | 客户端重启时，可以读取本地缓存配置文件。如果是新扩容的机器，可以从其它机器上获取已缓存的配置文件，具体信息可以参考Java客户端使用指南 - 1.2.3 本地缓存路径 | |
| 某台Admin Service下线 | 无影响 | Admin Service无状态，Portal重连其它Admin Service | |
| 所有Admin Service下线 | 客户端无影响，Portal无法更新配置 | ||
| 某台Portal下线 | 无影响 | Portal域名通过SLB绑定多台服务器，重试后指向可用的服务器 | |
| 全部Portal下线 | 客户端无影响，Portal无法更新配置 | ||
| 某个数据中心下线 | 无影响 | 多数据中心部署，数据完全同步，Meta Server/Portal域名通过SLB自动切换到其它存活的数据中心 | |
| 数据库宕机 | 客户端无影响，Portal无法更新配置 | Config Service开启配置缓存后，对配置的读取不受数据库宕机影响 |
4.2.8、模块说明
Config Service
- 提供配置获取接口
- 提供配置更新推送接口（基于Http long polling）
- 服务端使用Spring DeferredResult实现异步化，从而大大增加长连接数量
- 目前使用的tomcat embed默认配置是最多10000个连接（可以调整），使用了4C8G的虚拟机实测可以支撑10000个连接，所以满足需求（一个应用实例只会发起一个长连接）。
- 接口服务对象为Apollo客户端
Admin Service
- 提供配置管理接口
- 提供配置修改、发布等接口
- 接口服务对象为Portal
Meta Server
- Portal通过域名访问Meta Server获取Admin Service服务列表（IP+Port）
- Client通过域名访问Meta Server获取Config Service服务列表（IP+Port）
- Meta Server从Eureka获取Config Service和Admin Service的服务信息，相当于是一个Eureka Client
- 增设一个Meta Server的角色主要是为了封装服务发现的细节，对Portal和Client而言，永远通过一个Http接口获取Admin Service和Config Service的服务信息，而不需要关心背后实际的服务注册和发现组件
- Meta Server只是一个逻辑角色，在部署时和Config Service是在一个JVM进程中的，所以IP、端口和Config Service一致
Eureka
- 基于Eureka和Spring Cloud Netflix提供服务注册和发现
- Config Service和Admin Service会向Eureka注册服务，并保持心跳
- 为了简单起见，目前Eureka在部署时和Config Service是在一个JVM进程中的（通过Spring Cloud Netflix）
Portal
- 提供Web界面供用户管理配置
- 通过Meta Server获取Admin Service服务列表（IP+Port），通过IP+Port访问服务
- 在Portal侧做load balance、错误重试
Client
- Apollo提供的客户端程序，为应用提供配置获取、实时更新等功能
- 通过Meta Server获取Config Service服务列表（IP+Port），通过IP+Port访问服务
- 在Client侧做load balance、错误重试
4.3 Nacos
4.3.1、Nacos特性
1、依赖mysql作为存储层
2、配置修改实时生效（热发布）
3、支持本地配置快照缓存
4、拥有namespace、group、DataId公三层环境划分
5、提供openAPI，支持多语言
6、提供简洁的界面，操作人性化
7、可以控制用户对于namespace的基于 RBAC （角色访问控制）的权限控制（只读、只写、读写），不支持审计
8、支持回滚历史版本
9、通过扩展配置集或共享配置集支持公共配置
用户可以通过管理平台发布配置，通过 HTTP 调用将配置注册到服务端，服务端将之保存在 MySQL 等持久化存储引擎中；用户通过客户端 SDK 访问服务端的配置，同时建立 HTTP 的长轮询监听配置项变更，同时为了减轻服务端压力和保证容灾特性，配置项拉取到客户端之后会保存一份快照在本地文件中，SDK 优先读取文件里的内容。
4.3.2、配置管理
对配置的多维度管理。系统配置的编辑、存储、分发、变更管理、历史版本管理、变更审计等所有与配置相关的活动。
4.3.3、配置项
一个键值对 Key = Value。一个具体的可配置的参数与其值域（一个键值对），通常以 param-key=param-value 的形式存在。例如我们常配置系统的日志输出级别（logLevel=INFO|WARN|ERROR） 就是一个配置项。
4.3.4、配置集
多个键值对，一般指一个配置文件。一组相关或者不相关的配置项的集合称为配置集（多个键值对/一个配置文件）。在系统中，一个配置文件通常就是一个配置集，包含了系统各个方面的配置。例如，一个配置集可能包含了数据源、线程池、日志级别等配置项。
4.3.5、配置集 ID
给这个配置文件起一个全局唯一的 ID。Nacos 中的某个配置集的 ID。配置集 ID 是组织划分配置的维度之一。Data ID 通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集，每个配置集都可以被一个有意义的名称标识。Data ID 通常采用类 Java 包（如 com.taobao.tc.refund.log.level）的命名规则保证全局唯一性。此命名规则非强制。
4.3.6、配置分组
多个配置文件放在一起，形成组，一般用于区分项目。例如，某学校多应用之间的区分，教师应用 TEACHER_GROUP，学生应用 STUDENT_GROUP。Nacos 中的一组配置集，是组织配置的维度之一。通过一个有意义的字符串（如 Buy 或 Trade ）对配置集进行分组，从而区分 Data ID 相同的配置集。当您在 Nacos 上创建一个配置时，如果未填写配置分组的名称，则配置分组的名称默认采用 DEFAULT_GROUP 。配置分组的常见场景：不同的应用或组件使用了相同的配置类型，如 database_url 配置和 MQ_topic 配置。
4.3.7、配置快照
缓存配置信息。Nacos 的客户端 SDK 会在本地生成配置的快照。当客户端无法连接到 Nacos Server 时，可以使用配置快照显示系统的整体容灾能力。配置快照类似于 Git 中的本地 commit，也类似于缓存，会在适当的时机更新，但是并没有缓存过期（expiration）的概念。
4.3.8、命名空间
区分环境，比如：dev、test、prod 等等。用于进行租户粒度的配置隔离。不同的命名空间下，可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用场景之一是不同环境的配置的区分隔离，例如开发测试环境和生产环境的资源（如配置、服务）隔离等。
4.3.9、最佳实践
通常我们可以这样定义 Namespace，Group，DataId：
Namespace：代表不同的环境，如：开发、测试， 生产等；Group：代表某个项目，如：XX物流项目，XX教育项目；DataId：每个项目下往往有若干个应用，每个配置集(DataId)是一个应用的主配置文件
${prefix}-${spring.profile.active}.${file-extension}
prefix 默认为 spring.application.name 的值，也可以通过配置项 spring.cloud.nacos.config.prefix来配置。
spring.profile.active 即为当前环境对应的 profile。注意：当 spring.profile.active 为空时，对应的连接符 - 也将不存在，dataId 的拼接格式将变成 ${prefix}.${file-extension}
file-exetension 为配置内容的数据格式，可以通过配置项 spring.cloud.nacos.config.file-extension 来配置。目前只支持 properties 和 yaml 类型，默认为 properties。
DataId 可以理解为用户自定义的配置健，group 可以理解为配置分组名称，这个属于配置层级设计的概念。简单来说，配置中心会通过层次设计，来支持不同的分区，以此区分不同的环境、不同的分组、甚至不同的开发者，满足在开发过程中灰度发布、测试等需求。因此怎样设计都可以，只要有含义就好。
4.3.10、Namespace
Namespace用于隔离多个环境，而每个应用在不同环境的同一个配置（如数据库数据源）的值是不一样的。因此，我们针对企业项目实际研发流程和环境进行规划。如某软件公司拥有开发、测试、生产三套环境，那么我们应该建立三个 Namespace 进行区分。
4.3.11、Spring Cloud方式中的扩展配置集与共享配置集
扩展配置集
- 通过配置
spring.cloud.nacos.config.ext-config[n].data-id来支持多个配置集。- 通过配置
spring.cloud.nacos.config.ext-config[n].group来定制配置组。如果未指定，则使用默认组。- 通过配置
spring.cloud.nacos.config. config[n].refresh来控制该配置集是否支持配置的动态刷新。默认情况下不支持。
共享配置集
共享配置集与扩展配置集唯一的区别就是共享配置集无法设置组信息，只获取 DEFAULT_GROUP。
4.3.12、配置优先级
Spring Cloud Alibaba Nacos Config 提供了三种从 Nacos 拉取配置的功能：
- A：通过内部相关规则（应用名、配置内容的数据格式等）自动生成相关的 Data Id 配置；
- B：通过配置
spring.cloud.nacos.config.ext-config[n].data-id来支持多个配置集。同时配置多个配置集时，优先级关系根据n的值决定，值越大，优先级越高；- C：通过配置
spring.cloud.nacos.config.shared-dataids配置多个共享配置集；
当三种方式同时使用时，优先级关系为：A > B > C。
4.3.13、集群搭建
4.3.14、nacos客户端解析
获取配置的主要方法是 NacosConfigService 类的 getConfigInner 方法，通常情况下该方法直接从本地文件中取得配置的值，如果本地文件不存在或者内容为空，则再通过 HTTP GET 方法从远端拉取配置，并保存到本地快照中。
当通过 HTTP 获取远端配置时，Nacos 提供了两种熔断策略，一是超时时间，二是最大重试次数，默认重试三次。
五、选型对比
5.1、环境隔离
Spring Cloud Config可以使用Label和Profile来做逻辑隔离，Label指远程仓库的分支，{application}-{profile}.properties。另外还可以利用创建不同的文件夹来隔离，共2层逻辑隔离可以通过文件夹的子文件夹做N层逻辑隔离。
Apollo可以利用Env做1层物理隔离，利用Cluster、Namespace来做2层逻辑隔离。
Nacos可以用Namespace、Group、DataId做3层逻辑隔离
5.2、灰度发布
Spring Cloud Config支持通过/bus/refresh端点的destination参数来指定要更新配置的机器，不过整个流程不够自动化和体系化。
Apollo可以直接在控制台上点灰度发布指定发布机器的IP，接着再全量发布，做得比较体系化。
Nacos目前发布到1.4.0版本，暂不支持灰度发布。
5.3、权限管理
Spring Cloud Config依赖Git的权限管理能力，开源的GitHub权限控制可以分为Admin、Write和Read权限，权限管理比较完善。
Apollo通过项目的维度来对配置进行权限管理，一个项目的owner可以授权给其他用户配置的修改发布权限。同时可以将配置的编辑与发布权限独立。
Nacos针对Namespace可以通过配置角色管理。基于 RBAC （角色访问控制）的权限控制（只读、只写、读写）
5.4、审计
- Spring Cloud Config依赖于git
- Apollo利用配置发布日志来做审计
- Nacos暂不支持审计
5.5、版本管理&回滚
- Spring Cloud Config依赖于git做回滚
- Apollo利用发布历史记录在界面点击回滚
- Nacos利用发布历史记录在界面点击回滚
5.6、配置格式校验
- Spring Cloud Config不支持
- Apollo支持
- Nacos支持
5.7、监听查询
当排查问题或者进行统计的时候，需要知道一个配置被哪些应用实例使用到，以及一个实例使用到了哪些配置。
- Spring Cloud Config使用Spring Cloud Bus推送配置变更，Spring Cloud Bus兼容 RabbitMQ、Kafka等，支持查询订阅Topic和Consumer的订阅关系。
- Apollo可以查看在界面查看配置使用实例
- Nacos可以在界面查询配置监听实例
5.8、多集群
Spring Cloud Config可以通过搭建多套Config Server，Git使用同一个Git的多个仓库，来实现物理隔离。
Apollo可以搭建多套集群，Apollo的控制台和数据更新推送服务分开部署，控制台部署一套就可以管控多个集群。
Nacos控制台和后端配置服务是部署在一起的，可以通过不同的域名切换来支持多集群。
5.9、配置推送
Spring Cloud Config原生不支持配置的实时推送，需要依赖Git的WebHook、Spring Cloud Bus和客户端/bus/refresh端点，整体链路较长，比较复杂:
1、基于Git的WebHook，配置变更触发server端refresh
2、Server端接收到请求并发送给Spring Cloud Bus
3、Spring Cloud Bus接到消息并通知给客户端
4、客户端接收到通知，请求Config Server端获取最新配置
Apollo利用Long Polling + 本地定时查询
Nacos利用Long Polling
5.10、运维成本
Spring Cloud Config包含config-server、Git和Spring Cloud Bus三大组件：
1、config-server提供给客户端获取配置;
2、Git用于存储和修改配置;
3、Spring Cloud Bus通知客户端配置变更;
本地测试模式下，Spring Cloud Bus和config-server需要部署一个节点，Git使用GitHub就可以。
生产环境中，config-server需要部署至少两个节点。Spring Cloud Bus如果使用RabbitMQ，普通集群模式至少需要两个节点。
Git服务如果使用GitHub就不用考虑高可用问题，如果考虑到安全性要自建Git私有仓库，整体的成本比较高。Web服务可以部署多节点支持高可用，由于Git有数据的一致性问题，可以通过以下的方式来支持高可用：
1、Git+Keepalived冷备模式，当主Git挂了可以马上切到备Git;
2、Git多节点部署，存储使用网络文件系统或者通过DRBD实现多个Git节点的数据同步;
Apollo分为MySQL，Config Service，Admin Service，Portal四个模块：
1、MySQL存储Apollo元数据和用户配置数据;
2、Config Service提供配置的读取、推送等功能，客户端请求都是落到Config Service上;
3、Admin Service提供配置的修改、发布等功能，Portal操作的服务就是Admin Service;
4、Portal提供给用户配置管理界面;
本地测试Config Service，Admin Service，Portal三个模块可以合并一起部署，MySQL单独安装并创建需要的表结构。在生产环境使用Apollo，Portal可以两个节点单独部署，稳定性要求没那么高的话，Config Service和Admin Service可以部署在一起，数据库支持主备容灾。可以分环境部署多套，Apollo的服务均是无状态的。
Nacos部署需要Nacos Service和MySQL：
1、Nacos对外提供服务，支持配置管理和服务发现;
2、MySQL提供Nacos的数据持久化存储;
单机模式下，Nacos可以使用嵌入式数据库部署一个节点，就能启动。生产环境使用Nacos，Nacos服务需要至少部署三个节点，再加上MySQL主备。
Nacos的部署结构比较简单，运维成本较低。Apollo部署组件较多，运维成本比Nacos高。Spring Cloud Config生产高可用的成本最高。
5.11、多语言支持
Spring Cloud服务于Java生态，一开始只是针对Java微服务应用，对于非Java应用的微服务调用，可以使用Sidecar提供了HTTP API，但动态配置方面还不能很好的支持。不支持原生Java
Apollo已经支持了多种语言，并且提供了open API。其他不支持的语言，Apollo的接入成本相对较低。支持原生Java
Nacos支持主流的语言，例如Java、Go、Python、Nodejs、PHP等，也提供了open API。支持原生Java
5.12、迁移支持
国内主流的互联网公司仍是以Java为主，除了原生Java SDK，在对整个Java生态，比如Spring Boot和Spring Cloud的支持上，三个产品都是支持的。
Spring Cloud Config原生就支持Spring Boot和Spring Cloud。
Nacos通过Spring Cloud for Alibaba支持Spring Boot和Spring Cloud生态，符合Spring生态中的标准实现方式，可以无缝从Spring Cloud Conig迁移到Nacos。
Apollo支持Spring Boot和Spring Cloud项目，但是实现方式不同于标准，无法做无缝迁移，从Spring Cloud迁移到Apollo，存在代码改造和兼容性成本。
5.13、性能对比
硬件环境：Nacos和Apollo使用同样的数据库（32C128G），部署Server服务的机器使用的8C16G配置的容器，磁盘是100G SSD。
Spring Cloud Config使用2.0.0.M9版本，Apollo使用1.2.0 release版本，Nacos使用0.5版本。
- 单机读场景
客户端测试程序通过部署多台机器，每台机器开启多个线程从配置中心读取不同的配置（3000个）。
Nacos QPS可以达到15000
Apollo分为读内存缓存和从数据库中读两种方式，从数据库中读能达到7500，从内存读缓存性能可以达到9000QPS。
Spring Cloud Config使用jGit读写Git，由于有客户端限制，单机读能力被限制在7QPS。
- 3节点读场景
将配置中心的压测节点数都部署成3个节点。Nacos QPS可以达到45000 QPS
Apollo读内存缓存可以达到27000 QPS。Nacos和Apollo由于读场景各个节点是独立的，基本就是单机读场景的3倍关系。
Spring Cloud Config三个节点读能力可以到达21QPS。
- 单机写场景
同样的方式，多台机器同时在配置中心修改不同的配置。
Nacos QPS可以达到1800。
Apollo未使用默认的数据库连接池（10）QPS只能达到800 QPS（CPU未压满），调整连接池至100可以达到1100 QPS（CPU压满）。
Git在提交同一个项目的时候会加锁，单机Git写能在5QPS左右，Spring Cloud Config在使用的时候以一个项目作为数据源，写能力受到Git限制。
- 3节点写场景
同样的方式，将配置中心的压测节点数都部署成3个节点。
Nacos QPS可以达到6000
Apollo可以达到3300 QPS（CPU压满），此时MySQL数据库因为配置较高，未成为性能瓶颈。
Spring Cloud Config三个节点时候，Git也是一个节点，写QPS为5。
整体上来看，Nacos的读写性能最高，Apollo次之，Spring Cloud Config的依赖Git场景不适合开放的大规模自动化运维API。
nacos官方性能压测报告：https://nacos.io/zh-cn/docs/nacos-config-benchmark.html
5.14 对比报表
| 功能点 | Spring Cloud Config | Apollo | Nacos |
|---|---|---|---|
| 配置实时推送 | 支持(Spring Cloud Bus) | 支持(HTTP长轮询1s内) | 支持(HTTP长轮询1s内) |
| 版本管理 | 支持(Git) | 支持 | 支持 |
| 配置回滚 | 支持(Git) | 支持 | 支持 |
| 灰度发布 | 支持（调用机器接口） | 支持 | 支持（不太好用） |
| 权限管理 | 支持(依赖Git) | 支持 | 支持 |
| 审计 | 支持(依赖Git) | 支持 | 不支持 |
| 多集群 | 支持 | 支持 | 支持 |
| 多环境 | 支持 | 支持 | 支持 |
| client本地缓存 | 不支持 | 支持 | 支持 |
| 监听查询 | 支持（查询MQ订阅） | 支持 | 支持 |
| 运维成本 | 高 | 中等 | 较低 |
| 多语言 | 仅Java | 主流语言，提供了Open API | 主流语言，提供了Open API |
| 配置格式校验 | 不支持 | 支持 | 支持 |
| 单机读(QPS) | 7(限流所致) | 9000 | 15000 |
| 单击写(QPS) | 5(限流所致) | 1100 | 1800 |
| 3节点读(QPS) | 21(限流所致) | 27000 | 45000 |
| 3节点写(QPS) | 5限流所致() | 3300 | 5600 |
六、总结
总的来说，Apollo和Nacos相对于Spring Cloud Config的生态支持更广，在配置管理流程上做的更好。Apollo相对于Nacos在配置管理做的更加全面，不过使用起来也要麻烦一些。Nacos使用起来相对比较简洁，在对性能要求比较高的大规模场景更适合。
此外，Nacos除了提供配置中心的功能，还提供了动态服务发现、服务共享与管理的功能，降低了服务化改造过程中的难度。
672
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
