配置中心调研：

1. 背景介绍

传统的静态配置方式要想修改某个配置只能修改之后重新发布应用，要实现动态性，可以选择使用数据库，通过定时轮询访问数据库来感知配置的变化。轮询频率低感知配置变化的延时就长，轮询频率高，感知配置变化的延时就短，但比较损耗性能，需要在实时性和性能之间做折中。配置中心专门针对这个业务场景，兼顾实时性和一致性来管理动态配置。配置的权限管控、灰度发布、版本管理、格式检验和安全配置等一系列的配置管理相关的特性也是传统采用配置文件方式难以解决的问题。

2. 想要需要满足的条件：

配置文件托管，
每次修改配置文件，无需重新打包成jar包，重启服务，能够实时读取最新配置文件。
尽量在原有项目上减少大幅度变动，考虑兼容性

3. 配置中心支持的功能

灰度发布：配置的灰度发布是配置中心比较重要的功能，当配置的变更影响比较大的时候，需要先在部分应用实例中验证配置的变更是否符合预期，然后再推送到所有应用实例。
权限管理：配置的变更和代码变更都是对应用运行逻辑的改变，重要的配置变更常常会带来核弹的效果，对于配置变更的权限管控和审计能力同样是配置中心重要的功能。
版本管理&回滚：当配置变更不符合预期的时候，需要根据配置的发布版本进行回滚。
配置格式校验：应用的配置数据存储在配置中心一般都会以一种配置格式存储，比如Properties、Json、Yaml等，如果配置格式错误，会导致客户端解析配置失败引起生产故障，配置中心对配置的格式校验能够有效防止人为错误操作的发生，是配置中心核心功能中的刚需。
监听查询：当排查问题或者进行统计的时候，需要知道一个配置被哪些应用实例使用到，以及一个实例使用到了哪些配置。
多环境：在实际生产中，配置中心常常需要涉及多环境或者多集群，业务在开发的时候可以将开发环境和生产环境分开，或者根据不同的业务线存在多个生产环境。如果各个环境之间的相互影响比较小（开发环境影响到生产环境稳定性），配置中心可以通过逻辑隔离的方式支持多环境。
多集群：当对稳定性要求比较高，不允许各个环境相互影响的时候，需要将多个环境通过多集群的方式进行物理隔离。

4. 开源配置中心基本介绍

目前市面上用的比较多的配置中心4种有：（按开源时间排序）

如果只要能作为分布式存储的服务都作为配置中心，Zookeeper和ETCD理论上也可以，但是一般不建议采用。

没有方便的UI管理工具，且缺乏权限、审核、灰度发布、审核机制等；
最重要的是，Zookeeper和ETCD通常定义为服务注册中心，统一配置中心的事情交给专业的工具去解决。

Disconf

百度开源，2014年7月开源，目前基本停止维护

Github开源地址：github.com/knightliao/…

官方文档：disconf.readthedocs.io/zh_CN/lates…

2014年7月百度开源的配置管理中心，同样具备配置的管理能力，不过目前已经基本不维护了，最近的一次发布版本是6年前的了。

Disconf总体架构

Disconf特性

支持配置（配置项+配置文件）的分布式化管理：
- 配置发布统一化
- 配置发布、更新统一化（云端存储、发布）：配置存储在云端系统，用户统一在平台上进行发布、更新配置。
- 配置更新自动化：用户在平台更新配置，使用该配置的系统会自动发现该情况，并应用新配置。特殊地，如果用户为此配置定义了回调函数类，则此函数类会被自动调用。
配置异构系统管理：
- 异构包部署统一化：这里的异构系统是指一个系统部署多个实例时，由于配置不同，从而需要多个部署包（jar或war）的情况（下同）。使用Disconf后，异构系统的部署只需要一个部署包，不同实例的配置会自动分配。特别地，在业界大量使用部署虚拟化（如JPAAS系统，SAE，BAE）的情况下，同一个系统使用同一个部署包的情景会越来越多，Disconf可以很自然地与他天然契合。异构主备自动切换：如果一个异构系统存在主备机，主机发生挂机时，备机可以自动获取主机配置从而变成主机。
- 异构主备机Context共享工具：异构系统下，主备机切换时可能需要共享Context。可以使用Context共享工具来共享主备的Context。
注解式编程，极简的使用方式：我们追求的是极简的、用户编程体验良好的编程方式。通过简单的标注+极简单的代码撰写，即可完成复杂的配置分布式化。
需要Spring编程环境。
可以托管任何类型的配置文件。
提供界面良好Web管理功能，可以非常方便的查看配置被哪些实例使用了。

Spring Cloud Config

Spring家族开源，2014年9月开源，持续维护

Github开源地址：github.com/spring-clou…

官方文档：spring.io/projects/sp…

Spring Cloud 生态组件，可以和Spring Cloud体系无缝整合，支持将配置文件通过git写入远程仓库进行读取配置文件

Spring Cloud Config架构

在这里插入图片描述

Apollo

携程开源框架，2016年5月开源，持续更新

开源地址：github.com/apolloconfi…

官方文档：www.apolloconfig.com/#/zh/README

Apollo（阿波罗）是一款可靠的分布式配置管理中心，诞生于携程框架研发部，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。

服务端基于Spring Boot和Spring Cloud开发，打包后可以直接运行，不需要额外安装Tomcat等应用容器。

Java客户端不依赖任何框架，能够运行于所有Java运行时环境，同时对Spring/Spring Boot环境也有较好的支持。

.Net客户端不依赖任何框架，能够运行于所有.Net运行时环境

preview

Apollo总体架构

Apollo的框架有点复杂，如果不考虑分布式微服务架构中的服务发现问题，Apollo的最简架构如下图所示：

这里面包含Apollo框架的4个核心模块：

ConfigService：提供配置获取接口，提供配置推送接口，服务于Apollo客户端。
AdminService：提供配置管理接口，提供配置修改发布接口，服务于管理界面Portal。
Client：为应用获取配置，支持实时更新，通过MetaServer获取ConfigService的服务列表，使用客户端软负载SLB方式调用ConfigService。
Portal：配置管理界面，通过MetaServer获取AdminService的服务列表，使用客户端软负载SLB方式调用AdminService。

Apollo调用流程

ConfigService是一个独立的微服务，服务于Client进行配置获取。
Client和ConfigService保持长连接，通过一种拖拉结合(push & pull)的模式，实现配置实时更新的同时，保证配置更新不丢失。
AdminService是一个独立的微服务，服务于Portal进行配置管理。Portal通过调用AdminService进行配置管理和发布。
ConfigService和AdminService共享ConfigDB，ConfigDB中存放项目在某个环境的配置信息。ConfigService/AdminService/ConfigDB三者在每个环境(DEV/FAT/UAT/PRO)中都要部署一份。
Protal有一个独立的PortalDB，存放用户权限、项目和配置的元数据信息。Protal只需部署一份，它可以管理多套环境。

加上分布式微服务架构中的服务发现，真正的Apollo框架如下：

如果你了解RPC和注册中心，这幅图其实不难理解：

Eureka用于注册中心，AP原则，所以Config Service和Admin Service的机器列表注册到Eureka中；
Client和Portal需要获取注册中心的机器列表，但是由于Eureka仅支持Java客户端，所以搞个Meta Server，将Eureka的服务发现接口以HTTP接口的形式暴露出来；
由于Meta Server是集群部署，需要搞个NginxLB去找Meta Server机器。

所以搞NginxLB + Meta Server，其实就是为了找Eureka中的机器列表配置，Client和Portal拿到这些机器配置，就可以发起调用了，最后就回到我们前面的简图，是不是So Easy!

我讲的已经够清楚了，如果还是不懂，就看这篇文章 《微服务架构~携程Apollo配置中心架构剖析》

Apollo特性

统一管理不同环境、不同集群的配置：
- Apollo提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。
- 同一份代码部署在不同的集群，可以有不同的配置，比如zk的地址等。
- 通过命名空间（namespace）可以很方便的支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖。
配置修改实时生效（热发布）：用户在Apollo修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序。
版本发布管理 + 灰度发布
权限管理、发布审核、操作审计：应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。所有的操作都有审计日志，可以方便的追踪问题。
客户端配置信息监控：可以在界面上方便地看到配置在被哪些实例使用。
提供Java和.Net原生客户端：
- 提供了Java和.Net的原生客户端，方便应用集成。
- 支持Spring Placeholder、Annotation和Spring Boot的ConfigurationProperties，方便应用使用。
- 提供了Http接口，非Java和.Net应用也可以方便的使用。
提供开放平台API：
- Apollo自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。
- Apollo出于通用性考虑，对配置的修改不会做过多限制，只要符合基本的格式就能够保存。
- 对于有些使用方，它们的配置可能会有比较复杂的格式，而且对输入的值也需要进行校验后方可保存，如检查数据库、用户名和密码是否匹配。对于这类应用，Apollo支持应用方通过开放接口在Apollo进行配置的修改和发布，并且具备完善的授权和权限控制。

Nacos

阿里开源，2018年7月开源，持续更新

开源地址：github.com/alibaba/nac…

官方文档：nacos.io/zh-cn/docs/…

Nacos 是阿里巴巴推出来的一个新开源项目，这是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。

Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施

Nacos架构

Naco支持的特性：

1）服务发现：支持 DNS 与 RPC 服务发现，也提供原生 SDK 、OpenAPI 等多种服务注册方式和 DNS、HTTP、与 API 等多种服务发现方式。

2）服务健康监测： Nacos 提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。

3）动态配置服务： Nacos 提供配置统一管理功能，能够帮助我们将配置以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。

4）动态 DNS 服务： Nacos 支持动态 DNS 服务权重路由，能够让我们很容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单 DNS 解析服务。

5）服务及其元数据管理： Nacos 支持从微服务平台建设的视角管理数据中心的所有服务及元数据，包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略、服务的 SLA 以及最首要的 metrics 统计数据。