download：构建数据工程师能力模型完结无密
如何实现可插拔配置？
我又又又又被吐槽了，随之而来，我的消息推送平台开源我的项目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的姿势会更加斯文。