大家好,我是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默认的强依赖只剩下了MySQL和Redis,其余中间件的都是弱依赖,要做到可插拔我是借助配置去实例化不同的中间件。
当我的配置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