Apollo：分布式配置管理中心
点击上方蓝字关注我们
配置需求
Spring Cloud配置中心从git仓库、svn仓库等配置源统一获取系统配置参数，由Spring Cloud Config Client消费。其配置文件必须遵循严格的语法格式，即使多余的空格都会造成Client 无法读取相应的配置参数，一旦出问题很容易被忽视。
面对越来越丰富的配置场景需求，如：
配置修改后实时生效；
灰度发布；
分环境、分集群管理配置；
完善的权限、审核机制；
一款大格局的配置中心给我们带来了“村里”的希望：
Apollo（阿波罗）是一款可靠的分布式配置管理中心，诞生于携程框架研发部，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
https://github.com/ctripcorp/apollo
ctripcorp
Apollo功能
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除功能上满足了我们对管理配置文件的场景需求，其本身采用的分布式微服务架构部署，也对我们现有的微服务架构有一定的指导意义。
1.基础模型
Apollo的基础模型：
用户在配置中心对配置进行修改并发布；
配置中心通知Apollo客户端有配置更新；
Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用；
2.架构模型
从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客户端的访问路径为：SLB-->Meta-->Config Service，实现配置读取、配置推送等功能；
开发访问Portal管理界面路径为：SLB-->Meta-->Admin Service，实现配置的修改、发布、授权、审批等功能；
其中如果没有Meta Server这层，Apollo客户端将通过Eureka来访问Config Service 和 Admin Service，此时在负载均衡、错误重试将有所欠缺。而Meta Server 换成我们的日常架构应该对应的是网关，它的作用由服务发现变为限流、熔断、重试、路由等。
而Portal管理界面带给我们启发的是：在当前应用系统不断增加的情况下，我们迫切的需要统一的用户体系及管理入口分别管理对应的应用，而不是各自为战，这也就意味着Portal的重要性。
Apollo宕机影响
从架构看Apollo是自成体系的，由于托管生产所有的配置文件，其重要性不言而喻。此时我也会像你一样有个疑问：Apollo 一旦宕机，应用是不是会因获取不到配置文件而产生重大事故？
因此我们需要了解下客户端设计来让大家安心。
上图简要描述了Apollo客户端的实现原理：
客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送（通过Http Long Polling实现）；
客户端还会定时从Apollo配置中心服务端拉取应用的最新配置；
这是一个fallback机制，为了防止推送机制失效导致配置不更新
客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified
定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property:
apollo.refreshInterval来覆盖，单位为分钟。
客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中；
客户端会把从服务端获取到的配置在本地文件系统缓存一份；
在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置
应用程序可以从Apollo客户端获取最新的配置、订阅配置更新通知；
通过以上原理我们得知，一旦Apollo集群故障，此时应用程序不会受影响，配置文件可以从本地文件系统恢复配置，但无法获取配置更新。
Apollo分布式部署
Apollo的部署架构多种多样，但无论如何部署都基于模型对以下服务进行分配：
进程1：Portal
进程2：Meta Server、Eureka、Config Service
进程3：Admin Service
数据库：PortalDB、ConfigDB
1.单机、单环境
对于多台Linux Server，一般将进程1、进程2 、进程3 分别拆分开来，分别放于不同的机器上。
2.单机、双环境
Portal实际上可以只部署1套，推荐的部署架构如下：
3台Linux服务器：
Portal Linux Server单独部署Portal
SIT Linux Server部署SIT的Config Service和Admin Service
UAT Linux Server部署UAT的Config Service和Admin Service
3个database：1个PortalDB + 1个SIT的ConfigDB + 1个UAT的ConfigDB
对于多环境，除PortalDB外，ConfigDB应按环境区分使用。
3.携程多环境部署图
部署策略如下：
Portal部署在生产环境的机房，通过它来直接管理FAT、UAT、PRO等环境的配置
Meta Server、Config Service和Admin Service在每个环境都单独部署，使用独立的数据库
Meta Server、Config Service和Admin Service在生产环境部署在两个机房，实现双活
Meta Server和Config Service部署在同一个JVM进程内，Admin Service部署在同一台服务器的另一个JVM进程内
Apollo接入最佳实践
当完成Apollo的部署后进行生产接入时，我认为还是要有一定规范的，而不是简单的接入即可。尤其当我们有CMDB时，我们要让其切实起到为上层应用提供数据支撑的作用。
在此特提供以下几点规范供参考：
CMDB 模型名称（模型下关联应用IP）与应用包名保持一致；
Apollo的项目AppId 与CMDB模型名称、应用包名一致；
自动化工具通过CMDB API 获取模型名称实现Apollo与应用的一致性接入；
在此还是要强调下，如果CMDB建立后无法和应用、业务关联使用，驱动运维对CMDB的数据进行有效更新，那么CMDB将成为运维的负资产，因此请引起我们的重视。