首页IT科技接口comparable和 接口comparator的比较(ConditionAlOnProperties实现可插拔?)

接口comparable和 接口comparator的比较(ConditionAlOnProperties实现可插拔?)

时间2025-08-04 16:21:28分类IT科技浏览4687
导读:大家好,我是3y,一年CRUD经验用十年的markdown程序员??‍?常年被誉为职业八股文选手...

大家好              ,我是3y                      ,一年CRUD经验用十年的markdown程序员??‍?常年被誉为职业八股文选手

我又又又又被吐槽了        ,随之而来           ,我的消息推送平台开源项目Austin又又又又更新啦                     ,迭代自己的项目多是一件美事啊              。

源码Gitee链接:gitee.com/austin

01              、可插拔

我的项目逐渐成型了之后            ,有挺多小伙伴吐槽过我的项目太重了        ,依赖的中间件有点多                      。

在最开始的那一版需要强依赖MySQL/Redis/Kafka/Apollo(项目启动就需要部署这些中间件)                     ,弱依赖prometheus/graylog/flink/xxl-job(想要有完整的项目体验                ,就需要把这些给部署起来)        。

MySQL是没有人吐槽的    ,数据库这种东西                     ,可以说是后端必需的了           。

Redis暂时还没人吐槽                    ,毕竟用的还是太多了,也没有什么强大的竞品                     。

Apollo经常被吐槽能不能换成Nacos            。

Kafka时而有人吐槽                 ,想要支持RabbitMQ                      、RocketMQ        。

我以前存在个观念:在公司里中间件是不会轻易替换的                       ,现在我的代码已经实现了一种姿势    ,感觉没多大必要支持多种中间件实现              ,你想换就自己动手改改嘛                      ,又不难                     。

「“Apollo太重啦        ,Apollo不好用!快点支持Nacos!                ”」「“支持RocketMQ好不好啊                      ”」「“能不能支持RabbitMQ?      ”」

对我来说并不是啥大理由           ,我还是觉得Apollo挺好用                     ,足够成熟稳定            ,同理Kafka亦是如此                。不过当我被吐槽多了        ,总会怀疑自己是不是做得不够好                     ,也会跟身边的大佬讨论讨论                ,有没有必要支持一些功能    。

思来想去    ,我变了                     ,我又懂了

为了让消息推送平台Austin易上手                    ,我首先把Apollo做成弱依赖,可以通过配置选择读本地文件还是读配置中心(Apollo)                     。其实当我们使用Apollo时                 ,即便Apollo挂了                       ,Apollo本身就有很强的容灾能力(自带本地文件)

其次    ,我把Kafka做成弱依赖              ,可以通过配置选择用Guava的eventbus还是走分布式消息队列(Kafka)                      ,后续可能还会支持RocketMQ/RabbitMQ        ,感兴趣的也可以在我的代码基础上实现一把           ,蹭个pull request也很香的                    。

一方面是降低使用门槛而做的                     ,另一方面是可以对具体实现进行可插拔            ,这是开源项目所需要的。我认为如果是公司级生产环境线上的项目        ,对这块更多考虑的是异构容灾(而非可插拔)                 。

于是乎                     ,现在消息推送平台Austin默认的强依赖只剩下了MySQLRedis                ,其他中间件的都是弱依赖    ,要做到可插拔我是借助配置去实例化不同的中间件                       。

当我的配置austin-mq-pipeline=eventbus时                     ,我就不去实例化Kafka相关的生产者和消费者                    ,转而去初始化eventBus的生产者和消费者,那自然接口下的实现类就是为eventbus的

02        、支持Nacos分布式配置中心

项目已经将Nacos已经接入了!从我做项目开始                 ,就一直有小伙伴留言是不是要支持Nacos作为分布式配置中心                       ,为什么偏偏就选择Apollo    。我一直错觉以为我遇到了邪教组织了    ,现在Nacos都流行到这个地步了?

接入完Nacos              ,又发现了低版本的客户端会导致SpringBean的懒加载失效                      ,从而导致我的Kafka消费者失败了        ,折腾了好一阵子!

03           、Kafka支持Tag过滤

我的股东们是能直接用我的远程服务的:Kafka的Topic是共享的           ,Group消费者也是共享的                     ,在不修改的前提下            ,直接使用会带来一个问题              。

当同时有两个或以上的股东在本地启动了Austin        ,那就会争抢消费这个Topic(相当于一个消费者组里起了多个消费者)                     ,导致在测试下发的时候可能收不到自己调试的消息(被别的股东抢去了)                      。

要解决这个问题我第一时间的想法很简单:不同的股东使用不同的group(相当于每个股东都会有独立的消费者组)                ,那不就完事了嘛?正好我的groupId生成是依赖渠道的code    ,改掉code就完事咯        。

但这还是有问题的:每个股东有独立的消费者组                     ,意味着每个股东能消费整个topic的所有消息                    ,这又意味着股东会接受到其他股东的测试消息(明明只想要自己测试的消息,却来了一条其他人发的)           。

要解决这个问题                 ,除了给每个股东一个独立的topic                       ,那就是根据tag过滤啦                     。

在Kafka实现这种效果    ,挺简单的:在发送的时候              ,把tag写进Kafka的头部                      ,在消费前把非自身tag的消息过滤掉就完事了            。

04                     、总结

从开始写这个项目到现在还一直在迭代        ,这个过程受到了不少的吐槽        。这种吐槽大多数是正向的           ,毕竟有人吐槽那才说明我这个项目是真的有人在用的                     ,有人在看的                     。

最近有个想法:把这个系统做成是线上的            ,可以由各大开发者在推送消息的时候调用我的接口        ,做成这样一定会很有意思                     ,面临的挑战和需求也会更多                。那我就一直可以迭代                ,在这过程中一定我还能学到很多以前所不知道的东西    。

这次我用@ConditionAlOnProperties这个注解来实现可插拔的配置    ,但其实如果是提供二方库的形式的话                     ,使用SPI的姿势会更加优雅                     。

如果想学Java项目的                    ,我还是强烈推荐我的开源项目消息推送平台Austin,可以用作毕业设计                 ,可以用作校招                       ,又可以看看生产环境是怎么推送消息的                    。

仓库地址(求各位兄弟们三连哟!)

项目Gitee仓库链接:http://gitee.com/zhongfucheng/austin 项目GitHub仓库链接:http://github.com/ZhongFuCheng3y/austin

创心域SEO版权声明:以上内容作者已申请原创保护,未经允许不得转载,侵权必究!授权事宜、对本内容有异议或投诉,敬请联系网站管理员,我们将尽快回复您,谢谢合作!

展开全文READ MORE
elementui表格合并列(el-table表格动态合并行、合并行列及详解) 注解英文老人与海(注解)