消息中间件的应用场景

目前单位内部系统众多，有一些互相调用数据的需求。想搭建一个中间件平台，所有应用统一像这个平台提交查询请求，然后由平台根据请求查询各系统获取数据，反传给提交查询的系统。 请问这个场景适合用消息中间件么？我查了下资料发现，消息中间件一般是单向传输，数据消费者拿到消息后好像没有和数据生产者的互动。另外对于消息的大小也有限制。我看淘宝开源的metaq限制在1m以下。那是不是如果有10几m这种的数据，就不太适合用消息中间件，那请问大家还有比较好的架构设计么？

消息中间件一般两个功能,解耦和异步处理,分别举个例子吧

解耦合:
比如我们做一个微博产品中的好友系统,就很需要使用消息中间件
当我们添加一个关注的时候, 涉及以下几个子系统

推荐系统,需要根据你关注的人给你做数据分析
搜索系统,需要根据你的数据建立索引
feed系统,需要根据你关注的人,发送一条新鲜事
统计系统 用于数据统计,了解产品情况

而如果直接在加关注的流程里进行这些操作,可能带来风险,所以,会引入mq来解耦合,因此就像你说的,一般是 "单向传输" 的(当然这不是绝对的,取决于你系统复杂度),而且发往mq的数据一般都不大,比如 from_uid, to_uid 就行了,一般都不会很大,如果发送的数据不满足你的要求,这个时候,需要调用好友系统提供的接口了

异步处理:
有的时候,我们一个操作可能会耗时比较久,所以,并不会在主要业务流程里进行处理
比如,我们在删除一个用户的时候,可能会有很多关联数据的操作,为了尽快的响应以及解耦合,我们会将这个消息发送给其他系统,让它们根据需求自己处理

那请问，我这种需要异步查询别的系统。 需要用什么方式来处理呢？

感觉就是一个代理系统而已

请求端-->MQ-->响应端-->Webservice-->请求端  我们的数据交换平台是采用这种方式

建议采用ESB产品。

消息中间件适合于异步消息传输，对于请求-响应 消息交互模式，处理起来稍微麻烦点。

ESB可能比较适合你们的系统集成情况，ESB作为消息代理和服务中介，屏蔽服务和消息的提供者地址，所有集成的系统通过ESB进行解耦。并且集成需求中如果需要采用异步消息进行通信的话，ESB接入三方MQ产品也很容易实现。

我这里有很多集成案例和产品介绍说明，楼主可以和我联系。

是否可以考虑主动推送数据，把企业间多系统都共用的数据独立出来维护，有变化通过webServe同步到其它系统

我自己设计的一个审核反馈系统
按我的消息格式走有个callback，人工审核完了 callback通知

我目前的想法是这样的，客户端A提交查询到总控Server的mq队列，Server程序监控这个mq队列，一旦有新的查询请求就将该请求转发给对应的业务系统B的mq_b队列。每个业务系统B有一个线程监控该mq_b队列，一旦拿到查询请求，即在自己的系统中将结果查询出，然后将结果发送到提交请求的客户端A所在队列mq_a。 客户端A有一个线程实时监控自己的结果mq_a队列。扫描到有结果，即将结果入库，与此同时，A在提交查询之后，就需要一直刷新自己的数据库，查看结果是否反传回来。
但是这样设计的问题是：前台在联机访问时，提交查询后，处理过程是异步的，我只能在提交了查询请求后，控制程序每秒扫描一次自己的数据库，看看是否有结果返回。 这样是不是不太好。 是否有更好的解决方案呢？

那请问你们的请求端，在发送请求后，如何判断结果已经返回呢？