Apollo配置中心架构剖析以及对比分析

Apollo 官网：Github

简介

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

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

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

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

核心概念

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

1. application (应用)：
   • 这个很好理解，就是实际使用配置的应用，Apollo客户端在运行时需要知道当前应用是谁，从而可以去获取对应的配置
   • 每个应用都需要有唯一的身份标识 – appId，我们认为应用身份是跟着代码走的，所以需要在代码中配置。
2. environment (环境)：
   • 配置对应的环境，Apollo客户端在运行时需要知道当前应用处于哪个环境，从而可以去获取应用的配置
   • 我们认为环境和代码无关，同一份代码部署在不同的环境就应该能够获取到不同环境的配置
   • 所以环境默认是通过读取机器上的配置（server.properties中的env属性）指定的，不过为了开发方便，我们也支持运行时通过System Property等指定。
3. cluster (集群)
   • 一个应用下不同实例的分组，比如典型的可以按照数据中心分，把上海机房的应用实例分为一个集群，把北京机房的应用实例分为另一个集群。
   • 对不同的cluster，同一个配置可以有不一样的值，如zookeeper地址。
   • 集群默认是通过读取机器上的配置（server.properties中的idc属性）指定的，不过也支持运行时通过System Property指定。
4. namespace (命名空间)
   • 一个应用下不同配置的分组，可以简单地把namespace类比为文件，不同类型的配置存放在不同的文件中，如数据库配置文件，RPC配置文件，应用自身的配置文件等
   • 应用可以直接读取到公共组件的配置namespace，如DAL，RPC等
   • 应用也可以通过继承公共组件的配置namespace来对公共组件的配置做调整，如DAL的初始数据库连接数

其余具体的一些信息，请移位到git自行观看。地址：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进程中

Apollo提供的功能 - 为什么选择Apollo

正是基于配置的特殊性，所以Apollo从设计之初就立志于成为一个有治理能力的配置发布平台，目前提供了以下的特性：

• 统一管理不同环境、不同集群的配置

  • Apollo提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。
  • 同一份代码部署在不同的集群，可以有不同的配置，比如zookeeper的地址等
  • 通过命名空间（namespace）可以很方便地支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖

• 配置修改实时生效（热发布）

  • 用户在Apollo修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序

• 版本发布管理

  • 所有的配置发布都有版本概念，从而可以方便地支持配置的回滚

• 灰度发布

  • 支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例

• 权限管理、发布审核、操作审计

  • 应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。
  • 所有的操作都有审计日志，可以方便地追踪问题

• 客户端配置信息监控

  • 可以在界面上方便地看到配置在被哪些实例使用

• 提供Java和.Net原生客户端

  • 提供了Java和.Net的原生客户端，方便应用集成
  • 支持Spring Placeholder, Annotation和Spring Boot的ConfigurationProperties，方便应用使用（需要Spring 3.1.1+）
  • 同时提供了Http接口，非Java和.Net应用也可以方便地使用

• 提供开放平台API

  • Apollo自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。不过Apollo出于通用性考虑，不会对配置的修改做过多限制，只要符合基本的格式就能保存，不会针对不同的配置值进行针对性的校验，如数据库用户名、密码，Redis服务地址等
  • 对于这类应用配置，Apollo支持应用方通过开放平台API在Apollo进行配置的修改和发布，并且具备完善的授权和权限控制

• 部署简单

  • 配置中心作为基础服务，可用性要求非常高，这就要求Apollo对外部依赖尽可能地少
  • 目前唯一的外部依赖是MySQL，所以部署非常简单，只要安装好Java和MySQL就可以让Apollo跑起来
  • Apollo还提供了打包脚本，一键就可以生成所有需要的安装包，并且支持自定义运行时参数

与Spring Config对比

对比项	Apollo	SpringConfig
配置界面	统一界面	无
动态的配置管理	支持	支持
本地缓存配置	支持	可以设置本地备份，提高可用性
配置生效时间	支持	重启生效，配置刷新生效
配置更新推送	支持	需要和git配合触发
配置定时拉取	支持	无，可代码设置定时任务拉取
用户权限管理	支持	无，需要git，数据库等
实例配置监控	支持	不支持
灰度发布	支持	不支持
告警通知	支持邮件方式警告	不支持
支持SpringBoot	支持	原生支持
设计的技术栈	Mysql	SpringCloudBus,MQ,Git
业务系统入侵性	入侵性弱	入侵性弱
单点故障	支持HA部署	支持HA部署