共计 4078 个字符，预计需要花费 11 分钟才能阅读完成。
我是 3y，一年 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。我还挺纳闷的，怎么就这个中间件问我的特地多呢？分布式配置核心可抉择的我的项目也是蛮多的：
在网上也有很多相干的比照，比方：
| 性能个性 | 重要性 | spring-cloud-config | Apollo | disconf | Nacos |
|---|---|---|---|---|---|
| 动态配置管理 | 高 | 基于 file | 反对 | 反对 | 反对 |
| 动静配置管理 | 高 | 反对 | 反对 | 反对 | 反对 |
| 对立治理 | 高 | 无，须要 github | 反对 | 反对 | 反对 |
| 多环境 | 中 | 无，须要 github | 反对 | 反对 | 反对 |
| 本地配置缓存 | 高 | 无 | 反对 | 反对 | 反对 |
| 配置锁 | 中 | 反对 | 不反对 | 不反对 | 不反对 |
| 配置校验 | 中 | 无 | 无 | 无 | 无 |
| 配置失效工夫 | 高 | 重启失效，或手动 refresh 失效 | 实时 | 实时 | 实时 |
| 配置更新推送 | 高 | 须要手工触发 | 反对 | 反对 | 反对 |
| 配置定时拉取 | 高 | 无 | 反对 | 配置更新目前依赖事件驱动，client 重启或者 server 端推送操 | 反对 |
| 用户权限治理 | 中 | 无，须要 github | 反对 | 反对 | 反对 |
| 受权、审核、审计 | 中 | 无，须要 github | 反对 | 无 | 反对 |
| 配置版本治理 | 高 | Git 做版本治理 | 界面上间接提供公布历史和回滚按钮 | 操作记录有落数据库，但无查问接口 | 界面操作，反对回滚 |
| 配置合规检测 | 高 | 不反对 | 反对（但还需欠缺） | 反对 | |
| 实例配置监控 | 高 | 须要联合 spring admin | 反对 | 反对，能够查看每个配置在哪些机器上加载 | 反对 |
| 灰度公布 | 中 | 不反对 | 反对 | 不反对局部更新 | 反对 |
| 告警告诉 | 中 | 不反对 | 反对，邮件形式告警 | 反对，邮件形式告警 | 反对 |
总体来说：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.apollo</groupId>
<artifactId>apollo-client-config-data</artifactId>
<version>1.9.1</version>
</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 就有了，不必愁了）
点个赞一点都不过分吧？我是 3y，下期见。
关注我的微信公众号【Java3y】除了技术我还会聊点日常，有些话只能轻轻说~ 【对线面试官 + 从零编写 Java 我的项目】继续高强度更新中！求 star！！原创不易！！求三连！！
austin 我的项目源码 Gitee 链接：gitee.com/austin
austin 我的项目源码 GitHub 链接：github.com/austin
