摘要：我们是不是很好奇配置中心如何做到实时更新并且通知到客户端的这也是一个面试中经常会问到的题目。客户端得到状态码是并且会根据立即去服务端拉取最新的配置。
记得我们那时候刚开始学习Java的时候都只是一个单体项目，项目里面的配置基本都是写在项目里面的properties文件中，比如数据库配置啥的，各种逻辑开关，一旦这些配置修改了，还需要重启项目这修改才会生效。随着各种微服务的诞生，服务的拆分也越来越细，可能涉及的服务成千上百，服务基本也是集群部署，这样再去一个一个项目修改配置，然后重启这显然是行不通的。所以分布式配置中心就诞生了，现在开源的分布式配置中心也挺多的比如：开源分布式配置中心有很多，比如spring-cloud/spring-cloud-config、淘宝/diamond、百度/disconf、携程/apollo、netflix/archaius、Qconf、XDiamond、nacos等等。我们是不是很好奇配置中心如何做到实时更新并且通知到客户端的这也是一个面试中经常会问到的题目。下面我们就以apollo为例吧去分析分析它是如何实现的。为什么选择Apollo来分析列？因为现在的公司就在使用它作为配置中心。虽然Apollo是携程开源的，但是携程内部也不用它。
要去了解一个玩意，就要先会去使用它。它的使用基本上很简单。虽然使用简单方便，但是它的设计还是挺复杂的，下面我们看一个它官网提供的架构图，是不是挺复杂的。
通过上述架构图我们可以看到ConfigService、AdminService、Client、Portal、 Meta Server、Eureka这几个模块，主要的还是前面四个模块Meta Server、Eureka这两个模块只是Apollo本身内部所需要的辅助模块,我们暂时可以不需要关注它。
介绍完了上面这些Apollo组成的模块回到正题，配置中心如何做到实时更新并且到客户端如何感知配置被更新了？看这个问题之前我们先回顾下每到周末我们去人气比较旺的餐厅吃饭的时候流程是什么样的？
client）告诉它某某你的应用的配置被修改了，原来的值是啥被修改后的值是啥？还是说客户端（Client）每隔多久去问下服务端我的配置有没有被修改呀？如果是你你会怎么选择列？你也许会说我肯定两种方式都要呀！小朋友才会做选择？再回到我们使用apollo的时候我们应用里面引入的Apollo的Client在我们应用启动的时候会有一个线程每隔5s向服务短发起一个http请求，不过这个http请求是不会立即返回的。它是一个长链接如果配置没有被更新，这个请求会被阻塞挂起，这个实现挂起的方式是通过Spring的DeferredResult来实现的，如果对这个Spring的DeferredResult不是很了解的推荐看下这个文章《5种SpringMvc的异步处理方式你都了解吗？》
挂起60s后会返回HTTP状态码为304给到客户端，如果再阻塞的过程中服务端配置有更新，这个Http请求会立马返回，并且把变化的nameSpace信息返回出去，并且返回的http的状态码是200。客户端得到状态码是200并且会根据nameSpace立即去服务端拉取最新的配置。
这里其实有一个问题，为什么不直接在长链接中返回变更后的结果，而是返回一个变更的通知，需要客户端根据这个变更通知立即去拉取新的配置？
感兴趣的可以参考下这个issue ：https://github.com/apolloconfig/apollo/issues/652
这样推送消息就是有状态了，做不到幂等了，会带来很多问题。目前推送是单连接走http的，所以问题可能不大，不过在设计上而言是有这个问题的，比如如果推送是走的tcp长连接的话。另外，长轮询和推送之间也会有冲突，如果连续两次配置变化，就可能造成双写。还有一点，就是保持逻辑的简单，目前的做法推送只负责做简单的通知，不需要去计算客户端的配置应该是什么，因为计算逻辑挺复杂的，需要考虑集群，关联，灰度等，总而言之，就是在满足幂等性，实时性的基础上保持设计的简单。
这样是不是就是很完美了，客户端可以实时接收到配置的更新。但是客户端如果接收服务端的更新内容处理失败，比如服务异常或者空指针的时候。这时候我们的客户端配置如果不重启是不是永远都不会被更新了。没关系这种情况apollo也帮你想到啦，你既然告诉我更新失败，那我就自己每隔一段时间主动去把我所有的配置都拉到客服端，拉回客服端之后和客户端的缓存配置做比较，如果一致直接结束，不一致就更新客户端的缓存，并且还会去异步更新本地文件。通过定时任务的补充，可以让配置达到最终的一致性。
主动轮询，和定时任务全量拉取配置是不是就万无一失呢？只要涉及到分布式我们就要考虑到其他系统的宕机，比如哪一天挖机直接把部署Apollo的机房的光纤给挖断了，这样整个配置服务直接挂了，这时候主动轮询以及定时任务都没法起到作用了。是不是拉取不了配置，整个我们的客户端应用也要跟着受影响列，我们的配置基本上是改动的频率也是比较小的，即使我们的配置中心挂掉了，我们还有一份本地文件系统来兜底，这个文件目录默认是/opt/data或C:/opt/data，
所以即使配置中心挂了，对应用的影响也比较小。因为它还会去读取本地文件来兜底。
到现在为止我们应该知道Apollo客户端是如何感知服务端配置更新了的把？
Apollo ConfigServer端，如果Apollo ConfigServer端有配置更改会告诉应用端有配置修改，让客户端立马去拉取全量的配置，并且把配置更新到本地缓存，并且还会异步去更新本地文件缓存。5min执行一次的定时任务，去拉取全量的配置。拉回配置之后也是对比本地缓存和远程是否一致，如果不一致则更新本地进程缓存为远程的，同时还去异步更新下本地文件。文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/123979.html
摘要：我们是不是很好奇配置中心如何做到实时更新并且通知到客户端的这也是一个面试中经常会问到的题目。虽然是携程开源的，但是携程内部也不用它。客户端得到状态码是并且会根据立即去服务端拉取最新的配置。通过定时任务的补充，可以让配置达到最终的一致性。 引言记得我们那时候刚开始学习Java的时候都只是一个单体项目，项目里面的配...
摘要：比如使用的时候指定使用哪个环境的配置在微服务架构下，服务的数量会比之前的单体应用多，部署的节点数量也会很多。今天主要是讲下在中如何对接进行配置管理。 问题背景 在实际工作中，我们的开发环境，测试环境，生产环境对应的 Mysql 数据库，Redis 这些信息都不一样，每个环境都有对应的一套配置，在 Spring Boot 中我们通常会编写多个配置文件，也就是每个环境一个配置文件。 比如：...
摘要：基于的动态配置推送。对于任务中心这种多任务平台型的配置，有一定影响。基于回调和配置的扩展点流程共建在建中通过扩展点共建方式，将流程编排的能力，暴露给内外部的开发者，完成任务中心的共建。 一、聊聊本文想说什么： 为更好帮助商家的会员快速成长，保持用户活性，完善用户的成长体系，有赞用户中心-会员成长团队基于现有的业务场景，设计了一套较完备任务中心系统。同时也有很多通用技术组件能够落地。...
摘要：零为何要学源码简单，是我现在看起来最简单的源码不会像封装了一层又一层，把人绕晕，而没有那么多封装，上手快，我们学习就应该从简单的开始凭什么非要去学封的像粽子一样的源码，我们就是要去学简简单单，平时朴素，接地气的源码最接近业务代码的源码。 零 为何要学apollo源码 1 简单，Apollo是我现在看起来最简单的源码不会像spring封装了一层又一层，把人绕晕，而apollo没有那么多封...
摘要：这样做的方式是简单，缺点是无法及时获取变更推模式规则中心统一推送，客户端通过注册监听器的方式时刻监听变化，比如使用等配置中心。 在前面的学习过程中，Sentinel 的规则，也就是我们之前定义的限流规则，是通过代码的方式定义好的。这是初始化时需要做的事情，Sentinel 提供了基于API的方式修改规则： FlowRuleManager.loadRules(List rules); /...
阅读 4488·2023-04-25 18:47
阅读 2514·2021-11-19 11:33
阅读 3237·2021-11-11 16:54
阅读 3009·2021-10-26 09:50
阅读 2340·2021-10-14 09:43
阅读 2704·2021-10-11 10:58
阅读 496·2021-09-03 10:47
阅读 485·2019-08-30 15:54
