乐趣区

关于java:分布式配置系统Apollo如何实时更新配置的

jiezi

引言

记得咱们那时候刚开始学习 Java 的时候都只是一个单体我的项目，我的项目外面的配置根本都是写在我的项目外面的 properties 文件中，比方数据库配置啥的，各种逻辑开关，一旦这些配置批改了，还须要重启我的项目这批改才会失效。随着各种微服务的诞生，服务的拆分也越来越细，可能波及的服务成千上百，服务根本也是集群部署，这样再去一个一个我的项目批改配置，而后重启这显然是行不通的。所以分布式配置核心就诞生了，当初开源的分布式配置核心也挺多的比方：开源分布式配置核心有很多，比方 spring-cloud/spring-cloud-config、淘宝 /diamond、百度 /disconf、携程 /apollo、netflix/archaius、Qconf、XDiamond、naco s 等等。 咱们是不是很好奇配置核心如何做到实时更新并且告诉到客户端的 这也是一个面试中常常会问到的题目。上面咱们就以 apollo 为例吧去剖析剖析它是如何实现的。为什么抉择 Apollo 来剖析列？因为当初的公司就在应用它作为配置核心。尽管 Apollo 是携程开源的，然而携程外部也不必它。

Apoll 简介

要去理解一个玩意，就要先会去应用它。它的应用基本上很简略。尽管应用简略不便，然而它的设计还是挺简单的，上面咱们看一个它官网提供的架构图，是不是挺简单的。
通过上述架构图咱们能够看到 ConfigService、AdminService、Client、Portal、Meta Server、Eureka 这几个模块，次要的还是后面四个模块 Meta Server、Eureka 这两个模块只是 Apollo 自身外部所须要的辅助模块, 咱们临时能够不须要关注它。

ConfigService

  • 提供配置获取接口
  • 提供配置推送接口

  • 服务于 Apollo 客户端

    AdminService

  • 提供配置管理接口
  • 提供配置批改公布接口

  • 服务于治理界面 Portal

    Client

  • 为利用获取配置，反对实时更新
  • 通过 MetaServer 获取 ConfigService 的服务列表 \

  • 应用客户端软负载 SLB 形式调用 ConfigService

    Portal

  • 配置管理界面
  • 通过 MetaServer 获取 AdminService 的服务列表

  • 应用客户端软负载 SLB 形式调用 AdminService

    Apoll 更新配置

    介绍完了下面这些 Apollo 组成的模块回到正题，配 置核心如何做到实时更新并且到客户端如何感知配置被更新了？看这个问题之前咱们先回顾下每到周末咱们去人气比拟旺的餐厅吃饭的时候流程是什么样的？

  • 首先必定是现场取号，或者手机端取号。

  • 而后就是排队刷手机等着被叫号。中途你还会被动问一问还要等多久，服务员会通知你等着吧，你后面还有几桌。
    下面这个吃饭的例子怎么晓得到号了列？两种形式，一种使咱们我每隔一段时间而后被动去问下服务员，是否到号，没到号持续刷手机，如果到号间接进去吃饭，还有一种的话就是罗唆始终坐在那里刷手机我反正不赶时间，等着被告诉到号。同样的配置核心的更新是如何告诉到客户端列？是服务端主（configService）动告诉到客户端（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/apolloconf…
    这样推送音讯就是有状态了，做不到幂等了，会带来很多问题。目前推送是单连贯走 http 的，所以问题可能不大，不过在设计上而言是有这个问题的，比方如果推送是走的 tcp 长连贯的话。另外，长轮询和推送之间也会有抵触，如果间断两次配置变动，就可能造成双写。还有一点，就是放弃逻辑的简略，目前的做法推送只负责做简略的告诉，不须要去计算客户端的配置应该是什么，因为计算逻辑挺简单的，须要思考集群，关联，灰度等，总而言之，就是在满足幂等性，实时性的根底上放弃设计的简略。

客户端定时工作全量拉取配置

这样是不是就是很完满了，客户端能够实时接管到配置的更新。然而客户端如果接管服务端的更新内容解决失败，比方服务异样或者空指针的时候。这时候咱们的客户端配置如果不重启是不是永远都不会被更新了。没关系这种状况 apollo 也帮你想到啦，你既然通知我更新失败，那我就本人每隔一段时间被动去把我所有的配置都拉到客服端，拉回客服端之后和客户端的缓存配置做比拟，如果统一间接完结，不统一就更新客户端的缓存，并且还会去异步更新本地文件。通过定时工作的补充，能够让配置达到最终的一致性。

客户端本地文件缓存配置

被动轮询，和定时工作全量拉取配置是不是就十拿九稳呢？只有波及到分布式咱们就要思考到其余零碎的宕机，比方哪一天挖机间接把部署 Apollo 的机房的光纤给挖断了，这样整个配置服务间接挂了，这时候被动轮询以及定时工作都没法起到作用了。是不是拉取不了配置，整个咱们的客户端利用也要跟着受影响列，咱们的配置基本上是改变的频率也是比拟小的，即便咱们的配置核心挂掉了，咱们还有一份本地文件系统来兜底，这个文件目录默认是 /opt/data 或 C:\opt\data，

所以即便配置核心挂了，对利用的影响也比拟小。因为它还会去读取本地文件来兜底。

小结

到当初为止咱们应该晓得 Apollo 客户端是如何感知服务端配置更新了的把？

  • 次要是通过客户端利用发动一个长连贯去 Apollo ConfigServer 端，如果 Apollo ConfigServer 端有配置更改会通知利用端有配置批改，让客户端立马去拉取全量的配置，并且把配置更新到本地缓存，并且还会异步去更新本地文件缓存。

  • 客户端还有一个默认 5min 执行一次的定时工作，去拉取全量的配置。拉回配置之后也是比照本地缓存和近程是否统一，如果不统一则更新本地过程缓存为近程的，同时还去异步更新下本地文件。

    完结

  • 因为本人满腹经纶，难免会有纰漏，如果你发现了谬误的中央，还望留言给我指出来, 我会对其加以修改。
  • 如果你感觉文章还不错，你的转发、分享、赞叹、点赞、留言就是对我最大的激励。
  • 感谢您的浏览, 非常欢送并感谢您的关注。

  • 站在伟人的肩膀
    https://www.apolloconfig.com/…
    https://www.iocoder.cn/Apollo…
退出移动版