共计 1867 个字符，预计需要花费 5 分钟才能阅读完成。
download：算法与数据结构 - 综合晋升 C++ 版某课网盘分享
如何实现可插拔配置？
我又又又又被吐槽了，随之而来，我的消息推送平台开源我的项目 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 的姿势会更加斯文。