我們公司項目做微服務化框架升級，需要升級消息隊列中間件。這個任務就派到我身上了锯玛。
由于項目的并發(fā)量不是很大，對消息隊列中間件的要求不高兼蜈，加上客戶給的錢少攘残，于是項目開始之初我就設計了一個非常簡單的實現(xiàn)——用memcacheq就OK。沒有集群为狸，沒有高可用歼郭、也沒有考慮高性能。
老大最近發(fā)話了：我們不能放縱辐棒。項目是可以質(zhì)量差一點病曾，但我們對自己的要求不能差。加上以后我們會承接更多更重要漾根，安全可靠性要求更高的項目泰涂，最好在消息隊列中間件的高可用，高可靠性上做一些文章辐怕，命令我一定要寫一個好一點的中間件選擇方案文檔逼蒙。萬一以后需要了，也好應付自如寄疏，不至于手足無措是牢。
經(jīng)過三天的學習，我對比了目前開源產(chǎn)品中比較流行的三套中間件產(chǎn)品：RabbitMQ,Kafka和RocketMQ陕截。其他像ZeroMQ,ActiveMQ這些估計也是差不多的驳棱，不會有更好的表現(xiàn)。按照網(wǎng)上的大多數(shù)人的對比艘策，得出了最好使用RocketMQ的建議蹈胡。
然而今天早上醒來，我發(fā)現(xiàn)我錯了朋蔫，離開項目實際的一切比較都是耍流氓罚渐。我之所以得出這樣的結(jié)論，是認為RocketMQ的吞吐能力強驯妄，安全可靠荷并，水平擴展能力強等等。但是別忘了青扔，RabbitMQ和Kafka也一樣可以源织。網(wǎng)上有人說rabbitMQ消息堆積會影響性能翩伪，但剛剛才看到可以用惰性隊列解決這個問題的。就像我那個項目而言谈息，消息量不大的情況下何必用消息隊列中間件呢缘屹？用一個ArrayBlockingQuene不就解決了嗎？
在我們IT領域侠仇，比較不同產(chǎn)品之間的差異似乎成為了非常流行的做法轻姿。如果你上百度查詢“XX與XX的對比”或者“XX與XX的區(qū)別”就可以得出一大堆結(jié)果。這些文章有些似乎說得很有道理逻炊，其實不然互亮。
就使“主流MVC框架的對比”做說明吧。很多人說Struct2比Struct1更方便更好用余素，因此推薦用Struct2豹休。前幾年出現(xiàn)了SpringMVC，他們又開始推薦SpringMVC了桨吊，說它開發(fā)更方便威根，更容易，更強大等屏积。突然之間医窿，SpringMVC似乎也有點落后了，現(xiàn)在又有很多人開始寫大量的Spring Boot的介紹文章炊林，說用它會如何如何姥卢。
這幾年我一路走過來，從Struct1一路升級框架渣聚，到現(xiàn)在独榴，并沒有發(fā)現(xiàn)我們的開發(fā)工作量減少了多少∞戎Γ總是有人談論說：喲棺榔，這個框架這么神奇呀，居然可以這樣隘道。是啊症歇，挺神奇的，真的可以這樣谭梗⊥睿可是又能怎么樣呢？用了它你就可以不用加班了激捏？用了它你的代碼就不爛设塔？用了它你就成了高級開發(fā)、架構(gòu)師远舅、技術總監(jiān)闰蛔？簡單地一句：你太于關注這些框架不會使你的技術真正進步痕钢。
你過于關注它們哪個好，其實歸根到底只是想用框架代替你少干活序六，這真的現(xiàn)實嗎任连？我們追求的東西到底是不是本末倒置？我想难咕，我們應該將精力回歸到程序員基本功上面：加強學習設計能力课梳，需求分析能力距辆，代碼整潔之道余佃。框架只不過是一個工具跨算，中間件要使用也非常方便爆土，這些都不是根本。
程序員應該更關注基本功诸蚕，更加關注“解決了什么樣的問題步势，是如何解決的”，而不是框架啊這些東西背犯。從struct升級到spring mvc坏瘩，你的業(yè)務代碼一句都不會少寫，倒不如多重構(gòu)一下代碼漠魏，多畫UML圖倔矾，養(yǎng)成良好的編程習慣≈拢基本功扎實時哪自，你會發(fā)現(xiàn)一切東西都似曾相識，原理就在我們打基本功的過程中使用過了禁熏，只不過現(xiàn)在用同樣一種模式解決同樣類似的問題而已壤巷。
