本人3y，markdown程序员，一年CRUD经验，十年经验姿势，不知道你有没有配置。但我不管你的进步如何，我不会等你的。今天和大家聊聊分布式配置中心01的话题，什么是分布式配置中心？很早以前就提过：分布式配置中心等组件是后端的标准配置。分布式配置中心理解起来很简单：其实就是从自己的系统中分离出一些配置信息，这些信息可以被应用实时获取。实现以上核心功能并不难，但是作为一个中间件，需要更多的配套服务，包括但不限于1.有一个后台接口供我们修改配置2.如果配置服务被挂起，还有是相关的容灾逻辑3..支持不同环境下的配置信息（我们在线配置一般在不同环境下配置不同的值）4.相关权限管理（只有负责人才能更新配置）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环境来测试消息的投递，没想到用了production环境。（这种问题一般需要权限和认可的介入。）像之前实现的去重功能，我在代码中硬写了具体的num和seconds值。这些值可能有一天会随着运行规则发生变化，所以也会被拉到分布式配置中心。....03。分布式配置中心。从我第一天把Apollo写进Austin可能会介绍的中间件开始，很多人问我为什么选择Apollo。我很纳闷，你为什么要问我这么多关于这个中间件的事情？分布式配置中心的选择还是蛮多的：网上有很多相关的对比，比如：特性的重要性spring-cloud-configApollodisconfNacos静态配置管理highfile-basedsupportsupport动态配置管理highsupportsupport支持统一管理HighNone，需要github支持支持多环境None，需要github支持支持本地配置缓存HighNone生效，或者手动刷新生效Real-timereal-time实时real-timereal-timeconfigurationupdatepushhighmanualtriggersupportsupportsupportconfigurationtimingpullhigh不支持配置更新目前依赖事件驱动，客户端重启或服务端推送操作支持用户权限管理无，需要github支持支持授权，审计，审计无，需要github支持不支持配置版本管理高Git版本管理界面直接提供发布历史和回滚按钮操作记录有数据库，但是没有查询界面界面操作，支持回滚配置合规性检测高不支持支持（但还是需要改进）支持实例配置监控高需要结合springadmin支持支持，可以查看每个配置加载在哪些机器上支持灰度发布不支持不支持部分更新支持告警通知国内不支持，email支持，并且支持电子邮件。总的来说：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-dockerhttps://github.com/apolloconfig/apollo/tree/master/scripts/docker-quick-start由于端口占用问题，我改了映射端口后，最重要的是看两个端口：8070是后台控制页面的端口，8080是服务的06端口，而SpringBoot用apollo写这个的时候，发现我真的没什么可写的。无非就是跟着官方文档走。唯一的好处就是我有现成的代码，跟着的同学直接复制粘贴即可。1.引入maven的依赖
