关于java:好家伙分布式配置中心真好用

我是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。我还挺纳闷的，怎么就这个中间件问我的特地多呢？分布式配置核心可抉择的我的项目也是蛮多的：

在网上也有很多相干的比照，比方：

总体来说：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  TODOapp:  id: austinapollo:  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