记一次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的各个字段的含义和用法，而不是不动脑筋就随便乱改，害人害己啊。

在不熟悉的领域更应该多查看资料，因为开发大量使用框架，一些底层的东西被很好的封装了起来，多阅读源码，才能更好去使用框架