Apollo简介
Apollo（阿波罗）是一款可靠的分布式配置管理中心，诞生于携程框架研发部，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
本文主要对apollo分布式配置中心进行简单的概述。主要说明：
- apollo的来源
- apollo的核心功能点
服务端基于Spring Boot和Spring Cloud开发，打包后可以直接运行，不需要额外安装Tomcat等应用容器。 Java客户端不依赖任何框架，能够运行于所有Java运行时环境，同时对Spring/Spring Boot环境也有较好的支持。.Net客户端不依赖任何框架，能够运行于所有.Net运行时环境。
参考文档地址：https://www.apolloconfig.com/#/zh/README
Apollo的核心功能点
统一管理不同环境、不同集群的配置
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还提供了打包脚本，一键就可以生成所有需要的安装包，并且支持自定义运行时参数
Apollo配置中心介绍
程序功能日益复杂，程序配置日益增多：各种功能开关、参数配置、服务器地址…
对程序配置的期望也越来越高：热部署并实时生效、灰度发布、分环境分集群管理配置、完善的权限审核机制…
在这样的背景下，Apollo配置中心应运而生。Apollo支持四个维度Key-Value格式的配置
- Application(应用) 实际使用配置的应用 Apollo客户端在运行时需要知道当前应用是谁，从而可以去获取对应的配置。每个应用都有对应的身份标识–appId，需要在代码中配置
- Environment(环境) 配置对应的环境 Apollo客户端需要知道当前应用出于哪个环境，，从而可以去获取应用的配置；环境和代码无关，同一份代码部署在不同的环境就应该获取不同环境的配置；环境默认是通过读取机器上的配置(server.properties的env属性)指定的
- Cluster(集群) 一个应用下不同实例的分组 例如按照不同数据中心划分，把上海机房的实例分为一个集群、把深圳机房的实例分为一个集群；对于不同的Cluster，同一个配置可以有不一样的值；集群默认是通过读取机器上的配置指定的(server.properties的idc属性)
- Namespace(命名空间) 一个应用下不同配置的分组，是配置项的集合 可以简单地把Namespace类别为(配置)文件，不同类型的配置存放在不同的文件中，例如数据库配置文件、RPC配置文件、应用自身的配置文件等；应用可以直接读取到公共组件的配置namespace，例如DAL、RPC等；应用也可以通过继承公共组件的配置namespace来对公共组件的配置做调整，如DAL的初始数据库连接数
Apollo在创建项目的时候，都会默认创建一个”application”的Namespace，”application”是个应用自身使用的。例如Spring Boot中项目的默认配置文件application.yaml，这里application.yaml就等同于”application”的Namespace。对于大多数应用来说,”application”Namespace已经能满足日常配置使用场景客户端获取”application”Namespace的代码如下
Config config = ConfigService.getAppConfig()
客户端获取非”application”Namespace的代码如下
Config config = ConfigService.getConfig(namespaceName)
Namespace的格式 配置文件有多种格式，properties、xml、yml、yaml、json等，同样Namespace也具有这些格式
tips: 非properties格式的namespace，在客户端使用时需要调用ConfigService.getConfigFile(String namespace, ConfigFileFormat configFileFormat)来获取，如果使用Htpp接口直接调用时，对应的namespace参数需要传入namespace的名字加上后缀名，如datasource.json
Namespace的获取权限分类 此处权限相是对于Apollo客户端来说的
- private(私有的)权限 private权限的Namespace，只能被所属的应用获取到。一个应用尝试获取其他应用private的Namespace，Apollo客户端会报”404”异常
- public(公共的)权限 具有public权限的Namespace，能被任何应用获取
Namespace的类型
- 私有类型 具有private权限，例如上文中提到的”application”Namespace就是私有类型
- 公共类型 具有public权限，公共类型的Namespace相当于游离于应用之外的配置，且通过Namespace的名称去标识公共Namespace，所以公共Namespace的名称必须全局唯一
使用场景 部门级别共享的配置、小组级别共享的配置、几个项目之间共享的配置、中间件客户端的配置
- 关联类型(继承类型) 具有private权限，关联类型的Namespace继承于公共类型的Namespace，用于覆盖公共Namespace的某些配置。例如公共Namespace有两个配置项
k1 = v1 k2 = v2然后应用A有一个关联类型的Namespace关联此公共Namespace，且以新值v3覆盖配置项k1。那么在应用A实际运行时，获取到的公共Namespace的配置为
k1 = v3 k2 = v2使用场景 假设RPC框架的配置(如：timeout)有以下要求
- 提供一份全公司默认的配置，且可动态调整
- RPC客户端项目可以自定义某些配置项且可动态调整 结合Apollo的公共类型的Namespace和关联类型的Namespace。RPC团队在Apollo上维护一个叫“rpc-client”的公共Namespace，在”rpc-client”Namespace上配置默认的参数值。rpc-client.jar里的代码读取”rpc-client”Namespace的配置即可；如需要调整默认的配置，只需要修改公共类型”rpc-client”Namespace的配置；如果客户端项目想要自定义或动态修改某些配置项，只需要在Apollo自己项目下关联”rpc-client”，就能创建关联类型”rpc-client”的Namespace，然后在关联类型下修改配置项即可。这里rpc-client.jar是在应用容器里运行的，所以rpc-client获取到”rpc-client”Namespace的配置是应用的关联类型的Namespace加上公共类型的Namespace
参考资料
GitHub主页地址：https://github.com/ctripcorp/apollo
