apollo配置中心

Apollo简介

Apollo（阿波罗）是携程框架部门研发的开源配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。

Apollo支持4个维度管理Key-Value格式的配置：

• application (应用)
• environment (环境)
• cluster (集群)
• namespace (命名空间) 同时，Apollo基于开源模式开发，开源地址：https://github.com/ctripcorp/apollo

Apollo特性

• 统一管理不同环境、不同集群的配置
  • Apollo提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。
  • 同一份代码部署在不同的集群，可以有不同的配置，比如zk的地址等
  • 通过命名空间（namespace）可以很方便的支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖
• 配置修改实时生效（热发布）
  • 用户在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还提供了打包脚本，一键就可以生成所有需要的安装包，并且支持自定义运行时参数

Apollo基础模型

如下即是Apollo的基础模型：

1. 用户在配置中心对配置进行修改并发布
2. 配置中心通知Apollo客户端有配置更新
3. Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用

Apollo的四个维度

Apollo基于四个维度去管理key-value格式的配置：

1、application(项目/应用) - 一级维度
②Apollo 客户端在运行时需要知道当前项目是谁，从而可以根据不同的应用来获取对应的项目的配置。
②这个项目在SpringBoot代码里用app.id来标识，在VM options中用-Dapp.id来标识。

2、environment(环境) - 二级维度
实际开发中，不可能只有一个环境。常见的如：
①DEV - 开发环境
②FAT - 功能验收测试环境
③UAT - 用户验收测试环境
④PRO - 生产环境
⑤其他环境（test-测试环境、sit-系统集成测试环境、pre-灰度环境）

3、cluster(集群) - 三级维度
一个应用下不同实例的分组，比如上海、北京两个机房为两个集群，它们中某些参数配置可能不一致。

4、namespace(命名空间) - 四级维度
可以简单地把 namespace 类比为不同的配置文件，不同类型的配置存放在不同的文件中，如数据库配置文件，RPC 配置文件，应用自身的配置文件等。

4.1、Namespace的两种权限
①public(公共的)：public权限的Namespace可以被任何应用获取
②private(私有的)：只能被所属的应用获取到。一个应用尝试获取其他应用private的Namespace，Apollo会报404错误。

4.2、Namespace的三种类型
①公有类型：具有public权限，游离与应用之外的配置，名称全局唯一。
②私有类型：具有private权限。
③关联类型（继承类型）：具有private权限，可以将继承关联的Namespace的配置，并且可以覆盖配置。

Apollo架构模块

接下来从上往下简单介绍一下：

• Config Service：提供配置获取接口。提供配置更新推送接口(基于Http long polling)。服务对象为Apollo客户端(Client)。

• 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服务：提供Web界面供用户管理配置，通过MetaServer获取AdminService服务列表（IP+Port），通过IP+Port访问AdminService服务。

• Client：实际上就是我们创建的SpringBoot项目，引入ApolloClient的maven依赖，为应用提供配置获取、实时更新等功能。

• Meta Server：从Eureka获取Config Service和Admin Service的服务信息，相当于是一个Eureka Client。主要是为了封装服务发现的细节，对Portal和Client而言，永远通过一个Http接口获取Admin Service和Config Service的服务信息，而不需要关心背后实际的服务注册和发现组件。Meta Server只是一个逻辑角色，在部署时和Config Service是在一个JVM进程中的，所以IP、端口和Config Service一致。

• Eureka：注册中心。Config Service和Admin Service会向Eureka注册服务。为了简单起见，目前Eureka在部署时和Config Service是在一个JVM进程中的。

• 为了简化部署，我们实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中