什么是分布式配置中心？

我是敖丙的老婆，一年CRUD经验用十年的markdown程序员👨🏻‍💻常年被誉为优质八股文选手。

上次给大家安排了监控的相关使用姿势，不知道大家有没有配置起来。但我可不管你们的进度怎么样，是不会等着你们的哟。

今天来跟大家聊下分布式配置中心这个话题

01、什么是分布式配置中心

在之前我就很早已经提及过：分布式配置中心这种组件在后端就是标配的。

要理解分布式配置中心很简单：其实就是把一些配置的信息分离于自身的系统，而这些信息又能被应用实时获取得到。

要做到上面的核心功能并不难，但是作为中间件会需要更多的配套服务，包括但不限于

• 1、有后台界面供我们修改配置
• 2、配置服务如果挂了有相关的容灾逻辑
• 3、支持不同环境下的配置信息（我们线上的配置一般是分不同的环境配置不同的值）
• 4、相关权限管理（只有负责人才能对配置进行update）
• 5、简单易用（有对应的SDK支持或api支持）
• ...

有的公司会自研一套这种分布式配置中心的组件，实现了上面我提到的功能。作为个人或者小公司，直接上开源的就完事了。别老想着自研多么美妙，维护成本极大的。

02、为什么分布式配置中心

我们可以把常变动的配置信息存放在分布式配置中心上，比如：请求的ip地址、限流值、系统的配置值、各种业务开关等等。

甚至，我老东家的规则引擎也是在分布式配置中心的基础上干的，分布式配置中心用到的场景是在是太多了...

就以我们austin项目为例就好了，这期我们要实现丢弃消息。没错，你没看错。我们项目的核心是发消息，但需要在系统中实现丢弃消息的功能。

austin作为推送平台，它的定位是面向整个公司的所有类型的消息推送。有了这个定位以后，我们很难去保证用这个系统的都是些什么人（自然在这里面就会有粗心的）。

从austin的实现架构，我们可以发现的是：如果瞬间有大批量消息需要被下发时，数据会堵在MQ上等待消费

我们是在austin-api层实现了判断模板是否被删除的校验，但很有可能的是：请求已经全部被austin-api处理完毕了，消息已经积压在MQ了。

是可以在austini-handler再判断一遍模板是否被删除，但很多时候消息模板的拥有者并不是想把模板删掉（删掉意味着他们在控制台就看不到该模板的配置消息了），可能他们就只是发错了而已，希望还没下发的消息不再发送而已。

除此之外，我们还得在austin项目实现白名单拦截的功能，这功能作用于dev和pre环境。

对于austin项目而言，dev和pre环境跟线上环境其实没有什么本质上的区别。因为最终是下发消息，只要环境能把消息下发到用户手上，那就可以把他当做线上环境在用。

一般业务在正式下发消息之前，都会在dev和pre环境走一遍流程。但我们是很难保证它们的测试一定是正常的，万一业务方就出Bug导致dev/pre环境大批量推送了呢？

所以，我们会在dev/pre环境设置白名单，只有在白名单的内的用户才能收到消息。而白名单的列表我们又可以维护在分布式配置中心上

PS :相信大家多多少少都见过很多推送的事故（各大厂貌似都有过类似的新闻和经历）。在很大原因上，就是环境混用了。本来想用dev或者pre环境去测试消息下发，不料使用了生产环境。（这种问题一般就需要通过权限和审批的干预了）

像之前的实现的去重功能，我在代码硬编码写了具体的num和seconds值。这些值也许有一天都会随着运营规则有所变动，所以也会抽到分布式配置中心上。

....

03、分布式配置中心 选择

从我第一天把Apollo写入到austin可能要引入的中间件，就有很多人问我：为什么选择Apollo。我还挺纳闷的，怎么就这个中间件问我的特别多呢？分布式配置中心可选择的项目也是蛮多的：

在网上也有很多相关的对比，比如：

总体来说：Apollo支持的功能齐全、社区活跃、中文文档丰富。所以，我就选择了Apollo。社区活跃太重要了，当你使用某个框架时出现问题，然后网上一搜，发现都没人有过类似的踩坑记录，这时候头都大了。

之前我就提到过：技术选型并往往不跟技术挂钩。如果是个人项目，选个社区活跃的，并且该中间件已经被踩了很多坑的，学习它的思想和原理就能举一反三。等以后知识面上去了，觉得自己当时脑子进了屎选了个破玩意，切换成本一般也不会有多大。

如果是在公司，本身就有类似的中间件，该用什么就用什么，在这基础上修修补补就好了。如果没有类似的中间件，那就多点花时间调研，但我认为在选取的时候最后还是离不开中间件的成熟度和社区活跃度（也有可能大老板按照以往的习惯一拍板...）

虽说如此，感兴趣的还是可以多看看对比对比，这类文章在网上很多。（别老想着我什么都喂给你）

04、分布式配置中心原理

我以前的公司是自研的分布式配置中心，我曾经就看过其原理思想。那时候看到公司自研的技术实现是利用长连接使配置能实时被客户端监听到。这次引用了Apollo，我也去看了下设计文档，也是通过长轮询的方式实现客户端实时感知

推荐大家去读一读，如果对分布式配置中心不太熟悉或者不了解它是什么东西的话。

携程Apollo配置中心架构剖析演进

https://www.apolloconfig.com/#/zh/design/apollo-design

对于这块，我感觉我没什么可讲的，我平白无事也不会去捞源码看（除非特别对某个技术实现感兴趣，想看看人家是怎么实现的）。而Apollo文档这块做得是相当不错了。

我针对性从头读到尾，感觉挺流畅的，貌似不太需要我补充什么内容。

05、部署Apollo

部署Apollo跟之前一样直接用docker-compose就完事了，在GitHub已经给出了对应的教程和docker-compose.yml以及相关的文件，直接复制粘贴就完事咯。

https://www.apolloconfig.com/#/zh/deployment/quick-start-docker

https://github.com/apolloconfig/apollo/tree/master/scripts/docker-quick-start

由于端口的占用问题，我换了下映射端口，最主要看两个端口吧：8070是后台控制页面的端口，8080是服务的端口

06、SpringBoot 使用apollo

写到这的时候，发现我是真的没啥好写的，我无非也是跟着官方文档弄弄。唯一的好处是我有现成的代码，跟着做的同学可以直接复制粘贴就完了。

1、引入maven的依赖

<dependency>
  <groupId>com.ctrip.framework.apollogroupId>
  <artifactId>apollo-client-config-dataartifactId>
  <version>1.9.1version>
dependency>

2、在配置文件上加入apollo的配置信息：

# apollo  TODO
app:
  id: austin
apollo:
  bootstrap:
    enabled: true
    namespaces: boss.austin

配置的信息是在apollo的后台上新增的（这块大家只要能打开后台，问题就不大了，操作都挺简单的，感觉也没必要看啥文档）

部门的创建其实也是一份"配置"，输入organizations就能把现有的部门给改掉，我新增了boss股东部门，大家都是我的股东。

3、在Spring中直接使用ApolloConfig就完了

还值得一提的是，我们是在云服务器上使用docker部署的apollo的。一般获取姿势配置都是在内网上暴露对应的服务地址的，但我们这先体验的，所以可以直接跳过meta server

为了方便使用，直接在启动的时候设置下参数就好了（跟着做的同学可以换下自己的ip和端口）

08、总结

这篇文章简单介绍了什么是分布式配置中心，以及分布式配置中心能用来干什么，介绍了如何入门Apollo，使用SpringBoot环境下使用Apollo。

我强烈建议如果不了解分布式配置中心的同学可以从Apollo入手，根据上面给出的链接阅读下他的架构由来以及它的设计理念。作为一个markdown程序员而言，我觉得写得很不错的了。

对这感兴趣的，也可以深入阅读下源码，看看关键的功能是怎么实现的（这不又是一条学习路径？）

如果公司还没有用到分布式配置中心的，看完文章看看自己的项目有没有相关的场景，可以专研下来接入下（一整个Q的KPI/OKR就有了，不用愁了）