资阳网站优化金华建设技工学校网站
文章目录
- Apollo介绍
 - 配置中心介绍
 - apollo介绍
 - 主流配置中心
 - 功能特性对比
 
- Apollo简介
 
- 入门
 - 简单的执行流程
 - Apollo具体的执行流程
 - Apollo对象
 - 执行流程
 - 分步执行流程
 
- 核心概念
 - 应用,环境,集群,命名空间
 - 企业部署方案
 - 灰度发布
 - 全量发布
 
- 配置发布的原理
 - 发送ReleaseMessage
 - Config Service通知客户端
 - 客户端读取设计
 
Apollo介绍
配置中心介绍
- 分布式系统环境下,给其他服务提供配置文件的管理,统一管理各种应用配置的一个基础服务组件
 

apollo介绍
Apollo(阿波罗)是携程开源的一款可靠的分布式配置管理中心,它能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性,适用于微服务配置管理场景
主流配置中心
目前市面上用的比较多的配置中心有:
- Spring Cloud Config 
- 2014年9月开源,Spring Cloud 生态组件,可以和Spring Cloud体系无缝整合。
 - GitHub地址 
- https://github.com/spring-cloud/spring-cloud-config
 
 
 - Nacos 
- 2018年6月,阿里开源的配置中心,也可以做DNS和RPC的服务发现。
 - GitHub地址 
- https://github.com/alibaba/nacos
 
 
 - Apollo 
- 2016年5月,携程开源的配置管理中心
 - 能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端
 - 并且具备规范的权限、流程治理等特性,适用于微服务配置管理场景。
 - GitHub地址 
- https://github.com/apolloconfig
 
 
 
功能特性对比
| 功能点 | Spring Cloud Config | Apollo | Nacos | 
|---|---|---|---|
| 配置实时推送 | 支持 | 支持(HTTP长轮询1s内) | 支持(HTTP长轮询1s内) | 
| 版本管理 | 支持 | 支持 | 支持 | 
| 灰度发布 | 支持 | 支持 | 不支持 | 
| 权限管理 | 支持(依赖Git) | 支持 | 不支持 | 
| 多语言 | 只支持Java | 主流语言,提供了Open API | 主流语言,提供了Open API | 
- 总结 
- Spring Cloud Config 与 Apollo类似,但只支持 Java,所以不用 Spring Cloud Config
 - Nacos 不支持 灰度发布 和 权限管理,所以不用 Nacos
 
 
Apollo简介
- Apollo 是 一个 分布式配置中心的解决方案
 - Apollo 包括 
- 服务端 
- 服务端基于 Spring Boot 和Spring Cloud 开发
 
 - 客户端 
- Java客户端不依赖任何框架
 
 
 - 服务端 
 - Apollo 特性: 
- 统一管理不同环境,不同集群的配置 
- 提供了一个Apotal界面来管理
 
 - 热发布 
- 用户在Apollo修改完配置并发布后
 - 客户端能实时(1秒)接收到最新的配置,并通知到应用程序
 
 - 版本发布管理 
- 所有的配置发布都有版本概念
 - 从而可以方便地支持配置的回滚
 
 - 灰度发布 
- 支持配置的灰度发布 
- 比如点了发布后,只对部分应用实例生效
 - 等观察一段时间没问题后再推给所有 应用实例
 
 
 - 支持配置的灰度发布 
 
 - 统一管理不同环境,不同集群的配置 
 
入门
简单的执行流程
- 四个对象: 
- 配置中心
 - 客户端
 - 应用程序
 - 本地文件缓存
 
 - 执行流程
 
1、在Apollo配置中心修改配置
2、应用程序通过Apollo客户端从配置中心拉取配置信息
用户通过Apollo配置中心修改或发布配置后,会有两种机制来保证应用程序来获取最新配置:
- 一种是Apollo配置中心会向客户端推送最新的配置;
 - 另外一种是Apollo客户端会定时从Apollo配置中心拉取最新的配置
 
通过以上两种 机制共同来保证应用程序能及时获取到配置。
Apollo具体的执行流程

Apollo对象
- Config Service 
- 配置的读取和推送
 - 客户端通过 Config Service 读取配置
 
 - Admin Service 
- 配置的修改,发布
 - Portal 通过 Admin Service 将配置写到ConfigDB数据库中
 
 - Eureka 注册中心 
- 服务注册和发现
 - 记录 Config Service 和 Admin Service 的信息 
- IP地址,端口等
 
 - 方便客户端和Portal 的访问
 
 - Meta Server 
- 在Eureka 之上架了一层Meta Server
 - 用于封装Eureka的服务发现接口 
- Meta Server从Eureka获取Config Service和Admin Service的服务信息,相当于是一个Eureka Client
 
 
 
执行流程
- 客户端读取配置流程 
- 通过域名访问Meta Server获取Config Service服务列表(IP+Port
 - 而后直接通过IP+Port访问服务
 
 - 修改配置的流程 
- Portal通过域名访问Meta Server获取Admin Service服务列表(IP+Port)
 - 而后直接通过IP+Port访问服务
 
 - Ps: 
- 为了简化部署,我们实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程 中
 
 
分步执行流程
- Apollo启动后 
- Config/Admin Service会自动注册到Eureka服务注册中心,并定期发送保活心跳。
 
 - Apollo Client和Portal管理端通过配置的Meta Server的域名地址 
- 经由Software Load Balancer**(软件负载均衡** **器)进行负载均衡后分配到某一个Meta** Server
 
 - Meta Server从Eureka获取Config Service和Admin Service的服务信息,相当于是一个Eureka Client
 - Meta Server获取Config Service和Admin Service(IP+Port)失败后会进行重试 
- 获取到正确的Config Service和Admin Service的服务信息后
 - Apollo Client通过Config Service为应用提供配置获取、实时更新等功能;
 - Apollo Portal管理端通过Admin Service提供配置新增、修改、发布等功能
 
 
核心概念
应用,环境,集群,命名空间
-  
应用
- 就是实际使用配置的应用 
- Apollo客户端在运行时需要知道当前应用是谁,从而可以去获取对应的配置
 
 - 关键字: appId
 
 - 就是实际使用配置的应用 
 -  
环境
- 配置对应的环境 
- Apollo客户端在运行时需要知道当前应用处于哪个环境,从而可以去获取应用的配置
 
 - 关键字: env
 
 - 配置对应的环境 
 -  
集群
- 一个应用下不同实例的分组
 - 比如典型的可以按照数据中心分 
- 把上海机房的应用实例分为一个集群
 - 把北京机房的应用实例分为另一个集群。
 
 - 关键字:cluster
 
 -  
关系
- 应用 --> 环境 --> 集群 
- 应用 : 工程项目
 - 应用分环境 
- 具体环境下边 
- 由于部署的集群不同,导致配置的不同 
- 北京和上海数据库的地址不同,虽然都是生产环境
 
 
 - 由于部署的集群不同,导致配置的不同 
 
 - 具体环境下边 
 
 
 - 应用 --> 环境 --> 集群 
 -  
命名空间
-  

 -  
一个应用下不同配置的分组
- 配置通过key,value 存储
 
 
 -  
 -  
通过namespace对我们的配置项进行分类管理
- 不同类型的配置存放在不同的文件中 
- 数据库配置文件,RPC配置文件,应用自身的配置文件
 
 - 在添加配置的时候,要记得对配置项进行分类
 
 - 不同类型的配置存放在不同的文件中 
 -  
公共和私有:
-  

 -  
有共用的情况,公共命名空间可以继承
- 有5个工程都会连接数据库,数据库的配置就共用了
 - 就可以建一个公共的命名空间(例如数据库的连接) 
- 生产环境里面的命名空间可以继承公共的命名空间
 - 生产环境就可以直接拿到数据库的连接 
- 可以在生产环境中再做个性化定义
 
 
 
 
 -  
 
企业部署方案
在企业中常用的部署方案为:
- Apollo-adminservice (发布配置)和Apollo-configservice (查询配置)两个服务 
- 分别在线上环境(pro),仿真环 境(uat)和开发环境(dev)各部署一套
 - 并且还要建立不同的 apolloconfigdb 
- 因为配置信息在不同的数据库当中
 
 
 - Apollo-portal做为管理端 
- 管理界面,只部署一套 
- 统一管理上述三套环境。
 
 - 通过一个portal管理界面,连接访问不同的生产环境
 
 - 管理界面,只部署一套 
 
具体如下图所示:

灰度发布
- 定义: 
- 灰度发布是指在黑与白之间,能够平滑过渡的一种发布方式。
 - 在其上可以进行A/B testing 
- 即让一部分用户继续用 产品特性A
 - 一部分用户开始用产品特性B
 - 如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁 移到B上面来。
 
 
 - Apollo实现的功能 
- 对于一些对程序有比较大影响的配置 
- 可以先在一个或者多个实例生效,观察一段时间没问题后再全量发布 配置。
 
 - 对于一些需要调优的配置参数 
- 可以通过灰度发布功能来实现A/B测试。
 - 可以在不同的机器上应用不同的配 置,不断调整、测评一段时间后找出较优的配置再全量发布配置。
 
 
 - 对于一些对程序有比较大影响的配置 
 
全量发布
- 灰度发布测试完成后,全量发布
 
配置发布的原理
- 参考链接 
- https://www.iocoder.cn/categories/Apollo/
 
 
- 用户在Portal操作配置发布
 - Portal调用Admin Service的接口操作发布
 - Admin Service发布配置后,发送ReleaseMessage给各个Config Service
 - Config Service收到ReleaseMessage后,通知对应的客户端
 
发送ReleaseMessage
- 通过数据库实现了一个简单的消息队列
 
具体实现方式如下:
-  
Admin Service在配置发布后会往ReleaseMessage表插入一条消息记录
- 消息内容就是配置发布的AppId****+Cluster+Namespace
 - 源码: 
- 消息发送类: DatabaseMessageSende
 - https://github.com/ctripcorp/apollo/blob/master/apollo-biz/src/main/java/com/ctrip/framework/apollo/biz/message/DatabaseMessageSender.java
 
 
 -  
Config Service有一个线程会每秒扫描一次ReleaseMessage表
- 看看是否有新的消息记录
 - 源码: 
- 消息扫描类:ReleaseMessageScanner
 - https://github.com/ctripcorp/apollo/blob/master/apollo-biz/src/main/java/com/ctrip/framework/apollo/biz/message/ReleaseMessageScanner.java
 
 
 -  
Config Service如果发现有新的消息记录,那么就会通知到所有的消息监听器
1.- 然后调用消息监听类的handleMessage方法: NotificationControllerV2 
- https://github.com/ctripcorp/apollo/blob/master/apollo-configservice/src/main/java/com/ctrip/framework/apollo/configservice/controller/NotificationControllerV2.java
 
 
 - 然后调用消息监听类的handleMessage方法: NotificationControllerV2 
 -  
NotificationControllerV2得到配置发布的AppId+Cluster+Namespace后,会通知对应的客户端
 

Config Service通知客户端
上面描述了NotificationControllerV2是如何得知有配置发布的
NotificationControllerV2在得知有配置发布通知到客户端:
- 客户端会发起一个Http请求到Config Service的 notifications/v2 接口 NotificationControllerV2
 
客户端发送请求类:RemoteConfigLongPollService
- NotificationControllerV2不会立即返回结果,而是把请求挂起。
 - 考虑到会有数万客户端向服务端发起长连接, 因此在服务端使用了async servlet(Spring DeferredResult)来服务Http Long Polling请求。 
- 如果在60秒内没有该客户端关心的配置发布,那么会返回Http状态码304给客户端。
 - 如果有该客户端关心的配置发布 
- NotificationControllerV2会调用DeferredResult的setResult方法
 - 传入有 配置变化的namespace信息,同时该请求会立即返回。
 - 客户端从返回的结果中获取到配置变化的namespace 后,会立即请求Config Service获取该namespace的最新配置。
 
 
 
客户端读取设计
除了之前介绍的客户端和服务端保持一个长连接,从而能第一时间获得配置更新的推送外,客户端还会定时从
Apollo配置中心服务端拉取应用的最新配置。
- 这是一个备用机制,为了防止推送机制失效导致配置不更新
 - 客户端定时拉取会上报本地版本,所以一般情况下,对于定时拉取的操作,服务端都会返回304 - Not Modified
 - 定时频率默认为每5分钟拉取一次,客户端也可以通过在运行时指定System Property:apollo.refreshInterval 来覆盖,单位为分钟
 
