我又被吐槽啦
大家好，我是3y，一年CRUD經(jīng)驗用十年的markdown程序員???????常年被譽為職業(yè)八股文選手
我又又又又被吐槽了，隨之而來，我的消息推送平臺開源項目Austin又又又又更新啦，迭代自己的項目多是一件美事啊。
01、可插拔
我的項目逐漸成型了之后，有挺多小伙伴吐槽過我的項目太重了，依賴的中間件有點多。
在最開始的那一版需要強依賴MySQL/Redis/Kafka/Apollo（項目啟動就需要部署這些中間件），弱依賴prometheus/graylog/flink/xxl-job（想要有完整的項目體驗，就需要把這些給部署起來）。
MySQL是沒有人吐槽的，數(shù)據(jù)庫這種東西，可以說是后端必需的了。
Redis暫時還沒人吐槽，畢竟用的還是太多了，也沒有什么強大的競品。
Apollo經(jīng)常被吐槽能不能換成Nacos。
Kafka時而有人吐槽，想要支持RabbitMQ、RocketMQ。
我以前存在個觀念：在公司里中間件是不會輕易替換的，現(xiàn)在我的代碼已經(jīng)實現(xiàn)了一種姿勢，感覺沒多大必要支持多種中間件實現(xiàn)，你想換就自己動手改改嘛，又不難。
「“Apollo太重啦，Apollo不好用！快點支持Nacos！”」「“支持RocketMQ好不好啊”」「“能不能支持RabbitMQ？”」
對我來說并不是啥大理由，我還是覺得Apollo挺好用，足夠成熟穩(wěn)定，同理Kafka亦是如此。不過當我被吐槽多了，總會懷疑自己是不是做得不夠好，也會跟身邊的大佬討論討論，有沒有必要支持一些功能。
思來想去，我變了，我又懂了
為了讓消息推送平臺Austin易上手，我首先把Apollo做成弱依賴，可以通過配置選擇讀本地文件還是讀配置中心（Apollo）。其實當我們使用Apollo時，即便Apollo掛了，Apollo本身就有很強的容災能力（自帶本地文件）
其次，我把Kafka做成弱依賴，可以通過配置選擇用Guava的eventbus還是走分布式消息隊列（Kafka），后續(xù)可能還會支持RocketMQ/RabbitMQ，感興趣的也可以在我的代碼基礎上實現(xiàn)一把，蹭個pull request也很香的。
一方面是降低使用門檻而做的，另一方面是可以對具體實現(xiàn)進行可插拔，這是開源項目所需要的。我認為如果是公司級生產(chǎn)環(huán)境線上的項目，對這塊更多考慮的是異構容災（而非可插拔）。
于是乎，現(xiàn)在消息推送平臺Austin默認的強依賴只剩下了MySQL和Redis，其他中間件的都是弱依賴，要做到可插拔我是借助配置去實例化不同的中間件。
當我的配置austin-mq-pipeline=eventbus時，我就不去實例化Kafka相關的生產(chǎn)者和消費者，轉而去初始化eventBus的生產(chǎn)者和消費者，那自然接口下的實現(xiàn)類就是為eventbus的
02、Kafka支持Tag過濾
我的股東們是能直接用我的遠程服務的：Kafka的Topic是共享的，Group消費者也是共享的，在不修改的前提下，直接使用會帶來一個問題。
當同時有兩個或以上的股東在本地啟動了Austin，那就會爭搶消費這個Topic（相當于一個消費者組里起了多個消費者），導致在測試下發(fā)的時候可能收不到自己調試的消息（被別的股東搶去了）。
要解決這個問題我第一時間的想法很簡單：不同的股東使用不同的group（相當于每個股東都會有獨立的消費者組），那不就完事了嘛？正好我的groupId生成是依賴渠道的code，改掉code就完事咯。
但這還是有問題的：每個股東有獨立的消費者組，意味著每個股東能消費整個topic的所有消息，這又意味著股東會接受到其他股東的測試消息（明明只想要自己測試的消息，卻來了一條其他人發(fā)的）。
要解決這個問題，除了給每個股東一個獨立的topic，那就是根據(jù)tag過濾啦。
在Kafka實現(xiàn)這種效果，挺簡單的：在發(fā)送的時候，把tag寫進Kafka的頭部，在消費前把非自身tag的消息過濾掉就完事了。
03、總結
從開始寫這個項目到現(xiàn)在還一直在迭代，這個過程受到了不少的吐槽。這種吐槽大多數(shù)是正向的，畢竟有人吐槽那才說明我這個項目是真的有人在用的，有人在看的。
最近有個想法：把這個系統(tǒng)做成是線上的，可以由各大開發(fā)者在推送消息的時候調用我的接口，做成這樣一定會很有意思，面臨的挑戰(zhàn)和需求也會更多。那我就一直可以迭代，在這過程中一定我還能學到很多以前所不知道的東西。
今天就到這吧，下次我更新了代碼再跟大家聊聊我的項目，我是3y下期再見！
最近我開通了閱讀原文可跳轉至消息推送平臺倉庫