Apollo基本使用
Apollo基本使用
转自：配置中心 & Apollo基本使用
一、Apollo(配置中心)
Apollo(阿波罗)是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限，流程治理等特性，适用于微服务配置管理场景。
Apollo服务端基于Spring Boot 和Spring Cloud开发，打包后可以直接运行，不需要额外部署Tomcat等应用容器。
Apollo客户端不依赖任何框架，能够运行于所有Java运行时环境，同时对Spring/Spring Boot 环境也有较好的支持。
二、Apollo特性
A、统一管理配置
Apollo提供了一个统一界面集中式管理不同的环境(environment)、不同的集群(cluster)、不同的命名空间(namespace)的配置。
同一份代码部署在不同的集群，可以有不同的配置，比如zk的地址。
通过命名空间(namespace)可以很方便的支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖。
B、配置修改实时生效(热发布)
用户在Apollo修改完配置并发布后，Apollo客户端能实时(1s)接收到最新的配置，并通知到应用程序。
C、版本发布管理
所有的配置发布都有版本概念，从而可以方便的支持配置的回滚。
D、客户端配置信息的监控
可以方便的看到配置在被哪些实例使用。
E、便于集成
支持Spring Placeholder,Annotation和Spring Boot 的ConfigurationProperties,方便应用使用。
三、配置中心解决的痛点
随着程序功能的日益复杂，程序的配置日益增多：各种功能的开关、参数的配置、服务器的地址……
对程序配置的期望值也越来越高：配置修改后实时生效。灰度发布，分环境、分集群管理配置，完善的权限、审核机制……
天猫相关，可独立启动的应用17个，涉及到的作业52个，接口8个，web平台1个。
每个应用维护着一份自己的配置文件，平均每个应用配置文件数为4个，其中大量的配置项是相同的。
比如：appKey、secretKey、sessionKey、tmall.openapi.url等等。
冗余配置带来的问题很多：
- 一致性难以保证
- 维护成本高
- 不同环境之间容易误用
四、Apollo执行流程
- Apollo客户端和Apollo服务端保持长连接，从而能在第一时间获得配置更新的推送
- Apollo客户端会定时从Apollo服务端拉取应用的最新配置
- fallback机制，防止推送机制失败导致配置不更新
- Apollo客户端定时拉取上报本地版本，所以一般情况下，对于定时拉取的操作，服务端会返回304-Not Modified（？）
- 拉取频率为5分钟一次，客户端可以指定
- Apollo客户端从Apollo服务端获取到应用的最新配置后，会保存在内存中
- 客户端会把从服务端获取到的配置在本地文件系统缓存一份
- 在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置
- 应用程序从Apollo客户端获取最新的配置，订阅配置更新通知。
五、Apollo的安全性和可用性分析
A、安全性
配置文件除了改变程序行为之外，可能还包含一些敏感信息，比如: 开放接口的tokenId、secretKey、数据库账号等。
Apollo有一个默认的超级用户，可以在安装的时候初始化密码。
Apollo登录可以对接SSO，使用域账户登录。具体参考：Portal实现用户登录功能
Apollo在创建每个应用(映射到物理上的应用：转单、拉单)的时候，强制创建者指定一个owner，只有这个owner用户拥有该应用配置的编辑、发布权限。每个namespace(相当于.properties的概念)除了owner拥有全部权限，也可以给他人单独授权，这样就可以将配置项按照不同的安全级别划分到不同的namespace中，从而实现更小粒度的权限控制：比如db相关的namespace只有运维能编辑、发布。
B、可用性
配置中心作为基础服务，可用性要求非常高，下面描述了不同场景下Apollo的可用性：
1.某台config service下线，无影响，config service无状态，客户端重连其它config service。
2.所有config service下线，客户端无法读取最新配置，Portal无影响，客户端重启时，可以读取本地缓存配置文件。
3.某台admin service下线，无影响，Admin service无状态，Portal重连其它admin service。
4.所有admin service下线，客户端无影响，portal无法更新配置。
5.某台portal下线，无影响，Portal域名通过slb绑定多台服务器，重试后指向可用的服务器。
6.全部portal下线，客户端无影响，portal无法更新配置。
7.某个数据中心下线，无影响，多数据中心部署，数据完全同步，Meta Server/Portal域名通过slb自动切换到其它存活的数据中心。
按照官方的分析，只要部署时避免ConfigService（包含Meta Server）、AdminService、Protal Server单点。并且对各节点加上存活监控（以便短时间内dump节点的恢复），就能在保证高可用性。
在admin可以看到哪些实例（具体到IP）应用了哪些配置，上面原理中有体现，客户端也会定时上报自己的配置版本，避免了「推送失败，而服务端不知道」的情况。
六、web-admin端部署
Meta Server：这个一般是针对分布式存储集群而言的，metadata server存储的是实际的数据的位置（例如文件1在哪个机器上），又称元数据服务器。
ConfigService: 用于提供给client获取配置信息，以及配置更新后通知client的服务；ConfigService仅为client提供服务，且每个环境对应相应的ConfigService集群。
Admin Service：提供配置管理接口，提供配置修改发布接口，服务于管理界面Portal
Client：为应用获取配置，支持实时更新，通过MataServer获取ConfigService服务列表，使用客户端软负载SLB方式调用ConfigService
Portal：配置管理界面，通过MetaServer获取AdminService的服务列表，使用客户端负载SLB方式调用AdminService
七、应用端接入
7.1、具体的分部式部署指南如下：
分布式部署指南
7.2、Java程序集成Apollo
1）首先在pom.xml中引入apollo的引用。
2）告诉应用程序获取的是apollo配置的哪个项目的配置信息，即配好appid
3）将具体的环境配置(比如dev，uat，pro)直接配在具体的服务器上，将环境配置信息与应用进行一个解耦。一个机器只要确定是用于生产环境它就几乎确定下来，不会变了。在服务器中的/opt/settings/server.properties文件中进行配置具体的环境。直接告诉应用程序我这台机器指向哪几台机器(具体的环境)。
4）通过代码调用apollo的配置信息，在resources/META-INF下填写配置信息，配置该项目对应的namespace即可使用
5）使用方法直接在变量上面加@Value(“${***}”)即可
八、工作原理
1、Config Service 提供配置的读取、推送等功能，服务对象是Apollo客户端
2、Admin Service 提供配置的修改、发布等功能，服务对象是Apollo Portal (管理界面)
3、Config Service和 Admin Service都是多实例、无状态部署，所以需要将自己注册到Eureka中并保持心跳
4、在Eureka之上我们架了一层Meta Server用于封装Eureka的服务发现接口
5、Client通过域名访问Meta Server获取Config Service服务列表(IP+Port)，而后直接通过IP+Port访问服务，同时在Client侧会做load balance、错误重试
6、Portal 通过域名访问Meta Server获取Admin Service服务列表(IP+Port)，而后直接通过IP+Port访问服务，同时在Portal侧会做load balance、错误重拾
7、为了简化部署。我们实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中