大家好，我是讯享网，很高兴认识大家。



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

….

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

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

| 功能特性 | 重要性 | spring-cloud-config | Apollo | disconf | Nacos | | :————— | :—– | :————————– | :——————————- | :—————————————————— | :—————– | | 静态配置管理 | 高 | 基于file | 支持 | 支持 | 支持 | | 动态配置管理 | 高 | 支持 | 支持 | 支持 | 支持 | | 统一管理 | 高 | 无，需要github | 支持 | 支持 | 支持 | | 多环境 | 中 | 无，需要github | 支持 | 支持 | 支持 | | 本地配置缓存 | 高 | 无 | 支持 | 支持 | 支持 | | 配置锁 | 中 | 支持 | 不支持 | 不支持 | 不支持 | | 配置校验 | 中 | 无 | 无 | 无 | 无 | | 配置生效时间 | 高 | 重启生效，或手动refresh生效 | 实时 | 实时 | 实时 | | 配置更新推送 | 高 | 需要手工触发 | 支持 | 支持 | 支持 | | 配置定时拉取 | 高 | 无 | 支持 | 配置更新目前依赖事件驱动， client重启或者server端推送操 | 支持 | | 用户权限管理 | 中 | 无，需要github | 支持 | 支持 | 支持 | | 授权、审核、审计 | 中 | 无，需要github | 支持 | 无 | 支持 | | 配置版本管理 | 高 | Git做版本管理 | 界面上直接提供发布历史和回滚按钮 | 操作记录有落数据库，但无查询接口 | 界面操作，支持回滚 | | 配置合规检测 | 高 | 不支持 | 支持（但还需完善） | | 支持 | | 实例配置监控 | 高 | 需要结合spring admin | 支持 | 支持，可以查看每个配置在哪些机器上加载 | 支持 | | 灰度发布 | 中 | 不支持 | 支持 | 不支持部分更新 | 支持 | | 告警通知 | 中 | 不支持 | 支持，邮件方式告警 | 支持，邮件方式告警 | 支持 |

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

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

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

不过，感兴趣的还是可以多看看对比对比，这类文章在网上很多。

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

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

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

讯享网

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

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

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

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

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

1、引入maven的依赖

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

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

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

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

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

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

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

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

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

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

点个赞一点都不过分吧？我是3y，下期见。

austin项目立志成为每个Java初学者能够写在简历上的项目，它的核心是消息推送平台，核心功能：发送消息

项目出现意义：只要公司内有发送消息的需求，都应该要有类似austin的项目，对各类消息进行统一发送处理。这有利于对功能的收拢，以及提高业务需求开发的效率