Apollo-阿波罗配置中心
简介
Apollo包括服务端和客户端俩部分
- 服务端基于springboot和springcloud开发,打包后可以直接运行,不需要额外安装tomcat等应用容器
- java客户端不依赖任何框架,能够运行于所有java运行时环境,同事对spring/springboot也有较好的支持
特性
基于配置的特殊性,所以apollo从设计之初就致力于成为一个有治理能力的配置发布平台,提供了以下特性
统一管理不同环境不同集群的配置
apollo提供了一个统一界面集中式管理不同环境(environment)不同集群,不同命名空间的配置.同一份代码部署在不同的集群,可以有不同的配置,比如zookeeper的地址等.通过namespace可以很方便的支持多个不同应用共享同一份配置,同事还允许应用对共享的配置进行覆盖
修改实时生效(热发布)
用户在apollo修改完配置并发布后,客户端能实时(1s)接收到最新的配置,并通知到应用程序
版本发布管理
所有的配置发布都有版本概念,从而可以方便的支持配置的回滚
灰度发布
支持灰度发布,比如点了发布后,只对部分应用实例生效,等观察一段时间没问题后再推送给所有的应用实例
权限管理,发布审核,操作审计
应用和配置都有完善的权限管理机制,对应配置的管理还分为了编辑和发布俩个环节,从而减少人为的错误.所有的操作都有审计日志,可以方便的追踪问题
客户端配置信息监控
可以在界面上方便的看到配置在被哪些实例使用
提供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客户端有配置更新
- apollo客户端从配置真心拉取最新的配置信息,更新本地的配置并通知到应用
四个维度
apollo基于四个维度去管理key-value格式的配置
applicaton(项目/应用)一级维度
- apollo客户端在运行时需要知道当前项目是谁,从而可以根据不同的应用来获取对应的项目的配置
- 这个项目在springboot代码里用app.id来标识,再vm options中用dapp.id来标识
environment（环境） - 二级维度
实际开发中，不可能只有一个环境。常见的如：
①、DEV - 开发环境
②、FAT - 功能验收测试环境
③、UAT - 用户验收测试环境
④、PRO - 生产环境
⑤、其他环境（test - 测试环境、sit - 系统集成测试环境、pre - 灰度环境）
cluster（集群）- 三级维度
一个应用下不同实例的分组，比如上海、北京两个机房为两个集群，它们中某些参数配置可能不一致。
namespace（命名空间） - 四级维度
可以简单的把namespace类比为不同的配置文件，不同类型的配置存放在不同的文件中，如数据库配置文件、RPC配置文件、应用自身的配置文件等。
4.1namespace的两种权限
①、public（公共的）：public权限的namespace可以被任何应用获取。
②、private（私有的）：只有被所属的应用获取到，一个应用尝试获取其他应用private的namespace，Apollo会报404异常。
4.2namespace的三种类型
①、共有类型：具有public权限，游离与应用之外的配置，名称全局唯一。
②、私有类型：具有private权限。
③、关联类型（继承类型）：具有private权限，可以将继承关联的namespace的配置，并且可以覆盖配置。
本地缓存
Apollo客户端会把从服务端获取到的配置在本地文件系统缓存一份，用于在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置，不影响应用正常运行。
本地缓存路径默认位以下路径，所以请确保/opt/data或C:\opt\data\目录存在，且应用有读写权限。
Mac/Linux：/opt/data/{appId}/config-cache
Windows：C:\opt\data\{appId}\config-cache本地配置文件会以下面的文件名格式放置于本地缓存路径下：
{appId}+{cluster}+{namespace}.properties
- 客户端和服务端保持了一个长连接,从而第一时间获得配置更新的推送
- 客户端还会定时从apollo配置真心服务端拉取应用的最新配置
- 这是一个fallback机制,为了防止推送机制失效导致配置不更新
- 客户端定时拉取会上报本地的版本,一般情况下,对于定时拉取的操作，服务端都会返回304 - Not Modified。
- 定时频率默认为每五分钟拉去一次，客户端也可以通过在运行时指定apollo.refreshinterval来覆盖，单位为分钟。
- 客户端从apollo配置真心服务端获取到应用的最新配置后,会保存在内存中
- 客户端会吧从服务器端获取到的配置在本地文件系统缓存一份,再遇到网络服务不可用,或者网络不通的时候,依然能从本地恢复配置
- 应用程序从apollo客户端获取最新的配置,订阅配置更新通知
长连接是通过Http Long Polling实现的，具体而言：
1、客户端发起一个http请求到服务器
2、服务端会保持住这个连接60秒
3、如果在60秒内有客户端关心的配置变化，被保持住的客户端请求会立即返回，并告知客户端有配置变化的namespace信息，客户端会据此拉取对应的namespace最新配置。
4、如果在60秒内没有客户端关心的配置变化，那么会返回http状态码304给客户端，客户端在收到服务端请求后会立即重新发起连接，回到第一步。
5、考虑到会有数万客户端向服务端发起长连，在服务端使用了async servlet(Spring DeferredResult)来服务Http Long Polling。
从上往下看：
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进程中。
八、可用性考虑
配置中心作为基础服务，可用性要求非常高，下面的表格描述了不同场景下Apollo的可用性：
| 场景 | 影响 | 降级 | 原因 |
|---|---|---|---|
| 某台Config Service下线 | 无影响 | Config Service无状态，客户端重连其他Config Service | |
| 所有Config Service下线 | 客户端无法读取最新配置，Portal无影响 | 客户端重启时，可以读取本地缓存配置文件 | |
| 某台Admin Service下线 | 无影响 | Admin Service无状态，Portal重连其它Admin Service | |
| 所有Admin Service下线 | 客户端无影响，Portal无法更新配置 | ||
| 某台Portal下线 | 无影响 | ||
| 全部Portal下线 | 客户端无影响，Portal无法更新配置 | Portal域名通过slb绑定多台服务器，重试后指向可用的服务器 | |
| 某个数据中心下线 | 无影响 | 多数据中心部署，数据完全同步，Meta Server/Portal 域名通过slb自动切换到其他存活的数据中心 |
转载自 Apollo-阿波罗配置中心详细使用教程_apollo配置中心使用教程_hfwangyl的博客-CSDN博客
官方文档 https://www.apolloconfig.com/#/zh/README
动态刷新 https://blog.csdn.net/fengbird/article/details/128969709