Labs 导读
随着程序功能的日益复杂，程序的配置日益增多。各种功能的开关、参数的配置、服务器的地址等，对程序的配置提出了更高的要求，比如，配置修改后实时生效，灰度发布，分环境、分集群管理配置，完善的权限、审核机制等。SpringBoot项目大多使用@Value注解或者@ConfigurationProperties注解读取配置信息，线上项目经常需要对某些配置进行调整。
Part 01、 为什么需要配置中心
- 配置实时生效
传统的静态配置方式要想修改某个配置，只能修改之后重新发布应用，要实现动态性，可以选择使用数据库，通过定时轮询访问数据库来感知配置的变化。轮询频率低感知配置变化的延时就长，轮询频率高，感知配置的变化延时就短，但比较损耗性能，需要在实时性和性能之间做折中。配置中心专门针对这个业务场景，兼顾实时性和一致性来管理动态配置。
- 配置管理流程
配置的权限管理、灰度发布、版本管理、格式校验和安全配置等一系列配置管理相关的特性也是配置中心不可或缺的一部分。
Part 02、 什么是Apollo
Apollo（阿波罗）是一款可靠的分布式配置管理中心，诞生于携程框架研发部，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
Part 03、 功能介绍
➤ 统一管理不同环境、不同集群的配置
- Apollo提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。
- 同一份代码部署在不同的集群，可以有不同的配置，比如zk的地址等。
- 通过命名空间（namespace）可以很方便的支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖。
- 配置界面支持多语言（中文，English）。
➤ 配置修改实时生效（热发布）
- 用户在Apollo修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序。
➤ 版本发布管理
- 所有的配置发布都有版本概念，从而可以方便的支持配置的回滚。
➤ 灰度发布
- 支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例。
➤ 权限管理、发布审核、操作审计
- 应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。
- 所有的操作都有审计日志，可以方便的追踪问题。
➤ 客户端配置信息监控
- 可以方便的看到配置在被哪些实例使用。
➤ 提供Java和.Net原生客户端
- 提供了Java和.Net的原生客户端，方便应用集成。
- 支持Spring Placeholder，Annotation和Spring Boot的ConfigurationProperties，方便应用使用（需要Spring 3.1.1+）。
- 同时提供了Http接口，非Java和.Net应用也可以方便的使用。
➤ 提供开放平台API
- Apollo自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。
- 不过Apollo出于通用性考虑，对配置的修改不会做过多限制，只要符合基本的格式就能够保存。
- 在我们的调研中发现，对于有些使用方，它们的配置可能会有比较复杂的格式，如xml, json，需要对格式做校验。
- 还有一些使用方如DAL，不仅有特定的格式，而且对输入的值也需要进行校验后方可保存，如检查数据库、用户名和密码是否匹配。
- 对于这类应用，Apollo支持应用方通过开放接口在Apollo进行配置的修改和发布，并且具备完善的授权和权限控制。
➤ 部署简单
- 配置中心作为基础服务，可用性要求非常高，这就要求Apollo对外部依赖尽可能地少。
- 目前唯一的外部依赖是MySQL，所以部署非常简单，只要安装好Java和MySQL就可以让Apollo跑起来。
- Apollo还提供了打包脚本，一键就可以生成所有需要的安装包，并且支持自定义运行时参数。
Part 04、 架构设计
4.1 基础模型
如下即是Apollo的基础模型：
- 用户在配置中心对配置进行修改并发布。
- 配置中心通知Apollo客户端有配置更新。
- Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用。
图片
4.2 架构模块
如下即是Apollo架构模块的概览：
- Portal：英文意思为门户，在架构中充当的角色为管理端，用户通过该模块对配置进行修改。
- PortalDB：存储一些环境变量、配置环境等信息的数据库。注意，该库不存储配置信息。
- Admin Service：负责接收Portal发送过来的配置信息，对配置信息进行修改。
- ConfigDB：储存配置信息的数据库。
- Client：配置信息使用者，通常为微服务。
- Config Service：负责定期从数据库（ConfigDB）中拉取配置信息，若有变化，推送给客服端。或是客户端定期利用该服务拉取配置信息。
- Eureka：注册中心，无论Conifg Service还是Admin Service，在实际使用中都是部署在多台服务器上的。因此，对于客户端或者门户管理端而言，建立两个服务的连接都需要通过注册中心发现服务地址后再连接。
- Meta
Service：从Eureka获取Config Service和Admin Service的服务信息，相当于是一个Eureka
Client，增设一个Meta
Server的角色主要是为了封装服务发现的细节，对Portal和Client而言，永远通过一个Http接口获取Admin
Service和Config Service的服务信息，而不需要关心背后实际的服务注册和发现组件。
图片
Part 05、 服务端设计
在配置中心中，一个重要的功能就是配置发布后实时推送到客户端。下图即是配置发布后的实时推送设计：
1.用户在Portal操作配置发布。
2.Portal调用Admin Service的接口操作发布。
3.Admin Service发布配置后，发送ReleaseMessage给各个Config Service。
4.Config Service收到ReleaseMessage后，通知对应的客户端。
Part 06、 客户端设计
下图描述了Apollo客户端的实现原理：
1.客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送（通过Http Long Polling实现）。
2.客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。
a.这是一个fallback机制，为了防止推送机制失效导致配置不更新。
b.客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified。
c.定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖，单位为分钟。
3.客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中。
4.客户端会把从服务端获取到的配置在本地文件系统缓存一份。
a.在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置。
5.应用程序可以从Apollo客户端获取最新的配置、订阅配置更新通知。
Part 07、 结束语
在“约定优于配置，配置优于编码”的开发理念下，通过Apollo配置中心，程序员不需要每次更改线上配置都要重新发布服务，成功实现了将配置与编码解耦，为线上服务变更配置提供了解决方案。
