記一次Rabbit Mq開發過程

背景

項目第一次引入spring boot 封裝的rabbitMQ框架，用於接收庫存狀態的消息，用於實時更新。

踩坑過程

踩坑一：數據格式約定

rabbitMQ開發過程當中雙方須要提早約定如下數據：

• exchang :消息交換機，指定消息的路由發送規則
• routing key：路由關鍵字，exchange根據關鍵字進行消息投遞
• 數據格式：通常爲application/json
• exchange類型（fanout,topic,direct等）

上圖爲拿到的數據格式約定，exchange爲topic。然而調試過程當中遇到如下問題

• 生產方在未通知的狀況下，屢次修改routing key,致使調試過程當中我消費方屢次修改代碼
• 約定數據格式爲json,生產方因爲不熟悉spring cloud配置，給到的數據格式爲text/plain。生產方通過一天的調試，終於發現只須要在配置文件中增長spring.cloud.stream.bindings.myOutPut.content-type=application/json配置便可。至此，終於能夠接收到json格式數據了。
• 約定的格式是JSON,可是生產方實際給到的格式是JSONARRAY,致使我消費方解析數據出錯。

以上，讓我深入體會到契約精神多麼重要。因爲種種數據格式問題，嚴重拖慢了開發進度。然鵝，生產方其實並未意識到這個問題，潛意識認爲本身處於數據鏈路的上游，就能夠隨意修改約定好的格式

踩坑二 ：exchange類型

終於開心（kubi)的完成了開發測試過程，準備開開心心線上作發佈了。結果代碼在部署過程當中大量報錯，服務器直接done掉了。查看報錯信息

method<channel.close>(reply-code=406, reply-text=PRECONDITION_FAILED - inequivalent arg 'type' for exchange 'sim2es' in vhost '/': received 'topic' but current is 'fanout', class-id=40, method-id=10)
複製代碼

exchange須要fanout類型，我消費方定義的是topic類型。 什麼鬼，明明測試環境是topic類型，到線上搖身一變變成廣播fanout了？通過與生產方溝通，發現生產方爲了本身作線上消費的測試，上線的時候把exchange類型順手改爲了fanout，致使與我消費方的topic類型不匹配，消費方直接聲明queue報錯。 生產方是沒有想到這樣改會致使exchange類型不匹配？仍是其實根本不知道這個知識點，咱也不敢問。直接讓他老老實實把exchange類型改回topic。

以上，每一個開發都應該嚴格按照開發規範，熟悉mq的各個字段的含義和用法，而不是不動腦筋就隨便亂改，害人害己啊。

在不熟悉的領域更應該多查看資料，因爲開發大量使用框架，一些底層的東西被很好的封裝了起來，多閱讀源碼，才能更好去使用框架