当前位置:   article > 正文

初识配置中心Apollo(携程)的设计原理

携程 apllo propertiessource 原理

点击上方 "程序员小乐"关注, 星标或置顶一起成长

每天凌晨00点00分, 第一时间与你相约

每日英文

If we can only encounter each other rather than stay with each other, then I wish we had never encountered. 

如果只是遇见,不能停留,不如不遇见。

每日掏心

旅行或许改变不了现实,却可以改变心境,走着走着就明白,没有人会为你而改变,也没有人有义务迁就你。

来自:NYfor2020 | 责编:乐乐

链接:blog.csdn.net/NYfor2017/article/details/104821599

程序员小乐(ID:study_tech) 第 898 次推文  图源:百度

往日回顾:优秀!95后程序员月薪2万背电脑送外卖,送单途中修bug!

     

   正文   

前言

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在配置时的基础流程:

  1. 用户现在UI界面修改/发布配置。

  2. Apollo配置中心会将配置更新信息推送到Apollo客户端。

  3. 客户端再从Apollo配置中心拉取最新配置,更新本地配置之后,通知到应用。

六、Apollo客户端设计

我们已经初步了解Apollo的基础结构,但如果想更加深入地了解它,还得从其实现原理下手。

1、Apollo客户端实现原理

  1. 客户端和服务端会保持一个长连接,从而第一时间获取配置更新的推送。

  2. 客户端还会定时从Apollo配置中心服务端拉取应用的最新配置,而且客户端定时拉取会上报给本地版本,默认每隔5分钟拉取一次,也可以通过运行时指定apollo.refreshInterval来覆盖,单位为分钟。

  3. 客户端从Apollo配置中心服务端获取到应用的最新配置后,会保存在内存。

  4. 客户端会把从服务端拉取到的配置在本地文件系统缓存一份,保证在遇到服务不可用或网路故障时,依赖能从本地恢复配置,也实现了一定的高可用性。

  5. 应用程序从客户端获取到罪行的配置、订阅配置更新通知。

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

假设没有分布式微服务的服务发现,那么:

  1. Portal会调用AdminService进行配置管理和发布

  2. ConfigService和Client保持长连接,ConfigService服务于Client进行配置获取,ConfigService和Client通过一种推拉结合的方式,实现配置实时更新 的同时,保证配置更新不丢失。

  3. ConfigService和AdminService共享ConfigDB,ConfigDB中存放项目在某个环境的配置信息,而且这三者在每个配置环境(DEV/FAT/UAT/PRO)中都要部署一份。

  4. Protal有个独立的PortalDB,存放用户权限、项目和配置的元数据信息。Portal只需部署一份,它可以管理多套环境。

2、简化架构B

因为Client要找ConfigService需要地址列表,Portal找到AdminService也需要地址列表,这时候就需要服务发现了。

  1. Config/AdminService启动后都会注册到Eureka服务注册中心,并定期发送保持心跳。

  2. Eureka采用集群方式部署,使用分布式 一致性协议保证每个势力的状态最终一致。

  3. 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将会拉取不了配置中心的配置到本地。

参考资料:

  • 【微服务架构 为什么需要配置中心】https://www.cnblogs.com/davidwang456/articles/9238281.html

  • 【携程 Apollo 配置中心架构深度剖析】https://www.infoq.cn/article/ctrip-apollo-configuration-center-architecture/

  • 【Apollo配置中心介绍】https://github.com/ctripcorp/apollo/wiki/Apollo配置中心介绍

欢迎在留言区留下你的观点,一起讨论提高。如果今天的文章让你有新的启发,学习能力的提升上有新的认识,欢迎转发分享给更多人。

欢迎各位读者加入订阅号程序员小乐技术群,在后台回复“加群”或者“学习”即可。

猜你还想看

阿里、腾讯、百度、华为、京东最新面试题汇集

(六)手把手教你 SpringBoot+SpringCloud --集成 MyBatis

Thread.sleep(0) 有什么用?看完这篇你就明白了!

Java内存模型之可见性(填坑之路)

关注订阅号「程序员小乐」,收看更多精彩内容

嘿,你在看吗

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/2023面试高手/article/detail/478552
推荐阅读
相关标签
  

闽ICP备14008679号