楼主: zxit666
665 0

Docker+Kubernetes(k8s)微服务容器化实践|完结无密 [推广有奖]

  • 0关注
  • 0粉丝

高中生

30%

还不是VIP/贵宾

-

威望
0
论坛币
0 个
通用积分
0.0138
学术水平
0 点
热心指数
0 点
信用等级
0 点
经验
140 点
帖子
12
精华
0
在线时间
9 小时
注册时间
2022-3-9
最后登录
2022-8-28

+2 论坛币
k人 参与回答

经管之家送您一份

应届毕业生专属福利!

求职就业群
赵安豆老师微信:zhaoandou666

经管之家联合CDA

送您一个全额奖学金名额~ !

感谢您参与论坛问题回答

经管之家送您两个论坛币!

+2 论坛币
Docker+Kubernetes(k8s)微服务容器化实践|完结无密如何完成可插拔配置?
我又又又又被吐槽了,随之而来,我的音讯推送平台开源项目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、(彩蛋)KAFKA支持TAG过滤
我的股东们是能直接用我的远程效劳的:Kafka的Topic是共享的,Group消费者也是共享的,在不修正的前提下,直接运用会带来一个问题。
当同时有两个或以上的股东在本地启动了Austin,那就会争抢消费这个Topic(相当于一个消费者组里起了多个消费者),招致在测试下发的时分可能收不到本人调试的音讯(被别的股东抢去了)。
要处理这个问题我第一时间的想法很简单:不同的股东运用不同的group(相当于每个股东都会有独立的消费者组),那不就完事了嘛?正好我的groupId生成是依赖渠道的code,改掉code就完事咯。

但这还是有问题的:每个股东有独立的消费者组,意味着每个股东能消费整个topic的一切音讯,这又意味着股东会承受到其他股东的测试音讯(明明只想要本人测试的音讯,却来了一条其别人发的)。
要处理这个问题,除了给每个股东一个独立的topic,那就是依据tag过滤啦。
在Kafka完成这种效果,挺简单的:在发送的时分,把tag写进Kafka的头部,在消费前把非本身tag的音讯过滤掉就完事了。

03、总结
从开端写这个项目到如今还不断在迭代,这个过程遭到了不少的吐槽。这种吐槽大多数是正向的,毕竟有人吐槽那才阐明我这个项目是真的有人在用的,有人在看的。
最近有个想法:把这个系统做成是线上的,能够由各大开发者在推送音讯的时分调用我的接口,做成这样一定会很有意义,面临的应战和需求也会更多。那我就不断能够迭代,在这过程中一定我还能学到很多以前所不晓得的东西。
这次我用@ConditionAlOnProperties这个注解来完成可插拔的配置,但其实假如是提供二方库的方式的话,运用SPI的姿态会愈加文雅。
Docker+Kubernetes(k8s)微服务容器化实践|完结无密

download链接:https://pan.baidu.com/s/1IGHUeJCvkK0KeAP6wGfskA?pwd=90ya
提取码:90ya
--来自百度网盘超级会员V5的分享

二维码

扫码加我 拉你入群

请注明:姓名-公司-职位

以便审核进群资格,未注明则拒绝

关键词:Uber doc Ber NET conditional

您需要登录后才可以回帖 登录 | 我要注册

本版微信群
加JingGuanBbs
拉您进交流群

京ICP备16021002-2号 京B2-20170662号 京公网安备 11010802022788号 论坛法律顾问:王进律师 知识产权保护声明   免责及隐私声明

GMT+8, 2024-5-23 00:39