Apollo 你了解下这些内容就完美了
来源：https://urlify.cn/eIBZne
前言
Apollo是携程框架部门研发的开源配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端。本文介绍了配置的概念、配置中心的必要性以及Apollo的特点，着重拆解分析Apollo客户端的设计原理，了解Apollo的原理，也能帮助读者更加能够理解配置中心的实现原理。
一、什么是配置
配置是程序运行时，动态调整行为的能力。
配置有以下属性：
- 配置是独立于程序的只读变量
- 同一份程序在不同的配置下才会有不同的行为，而且配置对于程序来说是只读的，所以程序可以通过读取配置来改变自己的行为，但是不能自己改动配置文件。
- 配置伴随应用的整个生命周期
- 应用在启动的时候通过读取配置来初始化，在运行时根据配置改变自己的行为。
- 配置有多中加载方式
- 程序内部hard code，这种做法是反模式，十分不建议。
- 配置文件。
- 环境变量，配置可以预置在操作系统的环境变量里，程序运行时读取。
- 启动参数，可以在程序启动时一次性提供参数。
- 基于数据库，将易变配置放在数据库中，这样可以在运行期灵活调整配置。
- 配置需要治理
- 权限控制：对配置的修改需要有比较完善的权限控制，否则不正确的配置会引起灾难。
- 不同环境、集群配置管理：同一份程序在不同环境（开发、测试、生产）、不同的集群（如不同的数据中心）经常需要有不同的配置，所以需要完善的环境、集群配置管理。
- 框架类组件配置管理：如CAT客户端的配置。
二、为什么需要配置中心
在没有引入配置中心之前，一般研发的时候会有以下痛点：
配置格式散乱不规范
- 有的用properties格式，有的用yml格式，有的用xml格式，还有存DB的，做法五花八门。
- 主要采用本地静态配置，配置修改麻烦
- 在分布式微服务环境下，当服务实例很多的时候，配置修改费时费力。
- 易引发生产事故
- 如将测试环境的配置带到生产环境上。
- 配置缺乏安全审计和版本控制功能
- 无法查看到修改配置的人，修改了什么内容，以及修改的时间，除了问题也无法及时回滚。
三、配置中心的核心需求
1.交付件和配置分离
传统做法应用在打包部署的时候，会为不同环境打出不同配置的包，每个包里头包含环境特定配置。而现在推荐采用如容器镜像方式打包和交付微服务，应用镜像一般只打一份，可以部署到不同环境，所以这要求交付件和配置进行分离，交付件只制作一份，并且是不可变的，可以部署到任意环境。但是所有环境的配置都可以在配置中心集中配置，运行期应用可以根据自身环境到配置中心动态拉取相应的配置。
2.抽象标准化
配置中心应该封装屏蔽配置管理的细节和配置的不同格式，方便用户进行自主式配置管理，一般用户只需要关注两个抽象和标准化的接口即可：
- 配置管理界面UI，方便应用开发人员管理和发布配置。
- 封装好的客户端API，方便应用集成和获取配置。
3.多环境多集群
微服务应用大多采用多环境部署，一般标准的环境有开发/测试/生产等，有的应用还需要多集群部署，如支持跨机房或多版本部署。配置中心需要支持对多环境和多集群应用配置的集中式管理。
4.高可用
配置中心不能挂，否则会大面积影响微服务。
5.实时性
配置更新需要尽快通知到客户端，有些配置的实时性要求很高，像是主备切换配置或者蓝绿部署配置，这些需要秒级切换配置的能力。
6.治理
配置需要治理，具体包括：
1.配置审计，需要记录修改人，修改内容和修改事件，方便出现问题时能后追溯。
2.配置版本控制，每次变更需要版本化，出现问题可以及时回滚到上一版本。
3.配置权限控制，配置变更发布需要认证授权。
4.灰度发布，配置发布时可以先让少数实例生效，确定没有问题就可以扩大应用范围。
四、什么是Apollo
Apollo是携程框架部门研发的开源配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。
Apollo的特性如下：
- 统一管理不同环境、不同集群的配置。
- Apollo提供了一个统一界面集中式管理不同环境、不同集群、不同命名(namespace)空间的配置，而且同一份代码部署在不同集群，可以有不同的配置。
- 配置修改实时生效（热发布）
- 版本发布管理
- 灰度发布
- 客户端配置信息监控
- 可以在界面上方便地看到配置在被哪些实例使用。
- 提供Java和.Net原生客户端
- 提供开放平台API
- 部署简单
可以看到，Apollo的特性几乎符合上文配置中心的核心需求。
五、Apollo的基本模型
我们可以看到，Apollo在配置时的基础流程：
- 用户现在UI界面修改/发布配置。
- Apollo配置中心会将配置更新信息推送到Apollo客户端。
- 客户端再从Apollo配置中心拉取最新配置，更新本地配置之后，通知到应用。
六、Apollo客户端设计
我们已经初步了解Apollo的基础结构，但如果想更加深入地了解它，还得从其实现原理下手。
1、Apollo客户端实现原理
2、配置更新推送实现
上文提到Apollo客户端和服务端保持了一个长连接，从而可以第一时间获得配置更新的推送，实际上长连接是通过Http Long Polling实现的：
- 客户端发起Http请求给服务端
- 服务端保持60s连接
- 如果在60s中有客户端关心的配置变化，则请求会立即返回，并告知客户端有配置变化的namespace信息，客户端会据此拉取该namespace的最新配置。
- 如果60s内没有客户端关心的配置变化，则返回http状态码304给客户端。
在服务端，是用async servlet(Spring DeferredResult)来服务Http Long Polling请求。
七、Apollo总体设计
在捋清思路之前，先对其中的模块进行了解：
主要模块：
- ConfigService
- 提供配置获取接口
- 提供配置推送接口
- 服务于Apollo客户端
- AdminService
- 提供配置管理接口
- 提供配置修改发布接口
- 服务于管理界面Portal
- Client
- 为应用获取配置，支持实时更新
- 通过MetaServer获取ConfigService的服务列表
- 使用客户端软负载SLB方式调用ConfigService
- Portal
- 配置管理页面
- 通过MetaServer获取AdminService的服务列表
- 使用客户端软负载SLB方式调用AdminService
辅助模块：
- Eureka
- 用于服务发现和注册
- Config/AdminService注册实例并定期报心跳
- 和ConfigService一起部署
- MetaServer
- Portal通过域名访问MetaServer获取AdminService的地址列表
- Client通过域名访问MetaServer获取ConfigService的地址列表
- 相当于Eureka Proxy
- 和ConfigService一起部署
- NginxLB
- 和域名系统配合，协助Portal访问MetaServer获取AdminService的地址列表
- 和域名系统配合，协助Client访问MetaServer获取ConfigService的地址列表
- 和域名系统配置，协助用户访问Portal进行配置管理。
1、简化架构A
假设没有分布式微服务的服务发现，那么：
- Portal会调用AdminService进行配置管理和发布
- ConfigService和Client保持长连接，ConfigService服务于Client进行配置获取，ConfigService和Client通过一种推拉结合的方式，实现配置实时更新 的同时，保证配置更新不丢失。
- ConfigService和AdminService共享ConfigDB，ConfigDB中存放项目在某个环境的配置信息，而且这三者在每个配置环境（DEV/FAT/UAT/PRO)中都要部署一份。
- Protal有个独立的PortalDB，存放用户权限、项目和配置的元数据信息。Portal只需部署一份，它可以管理多套环境。
2、简化架构B
因为Client要找ConfigService需要地址列表，Portal找到AdminService也需要地址列表，这时候就需要服务发现了。
- Config/AdminService启动后都会注册到Eureka服务注册中心，并定期发送保持心跳。
- Eureka采用集群方式部署，使用分布式 一致性协议保证每个势力的状态最终一致。
- Client和Portal可以通过Eureka发现ConfigService和AdminService的地址列表。
因为携程需要跟自家的.Net的系统兼容，所以引入了MetaServer服务，这相当于是代理Proxy，将Eureka的服务发现接口以更简单明确的HTTP接口的形式暴露出来。
但是MetaServer本身也是无状态以集群方式部署的，那么Client/Protal该如何发现MetaServer呢？传统的方式是借助硬件（可以在其中指定MetaServer的位置）或者是软件负载均衡器。
3、完全结构
使用NginxLB（也称Software Load Balancer），由运维为MetaServer集群配置一个域名，指向NginxLB集群，NginxLB再对MetaServer进行负载均衡和流量转发。Client/Portal通过域名+NginxLB间接访问MetaServer集群。
结语
这里踩个坑，因为一套Portal就可以集中管理多套环境（DEV/FAT/UAT/PRO）中的配置，所以当切换环境的时候，需要注意到.properties(.yml)等配置文件中（SpringBoot）是否有明确标记处需要取出哪些namespace的配置，否则Client将会拉取不了配置中心的配置到本地。
对了，在这里说一下，我目前是在职Java开发，如果你现在正在学习Java，了解Java，渴望成为一名合格的Java开发工程师，在入门学习Java的过程当中缺乏基础入门的视频教程，可以关注并私信我：01。获取。我这里有最新的Java基础全套视频教程。