浏览 3262 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2011-11-20
最后修改:2011-11-20
在一个分布式应用系统中,有多个进程(都是用java开发的系统)间需要通信, 进程有A,B,C1,C2,C3,C4,D,F1,F2,F3,F4可能还要扩展更多个进程,目前各进程相互通信的相互关系如下 A<------->B,B<------->C, socket方式通信 C<------->M1,C<------->M2,C<------->M3,C<------->M4, RMI方式通信 A<------->D, socket方式通信 D<------->F1,D<------->F2,D<------->F3,D<------->F4, socket方式通信 (注:A<------->B表示A进程和B进程之间相互通信) 目前的做法是,使用了两种通信方式,但是这样作的弊病很大,首先是每个进程里都很多关于通信的代码,其次是如果要增加新的 协议改很多东西,非常不便于扩展,进程通信的代码和业务代码耦合非常紧密。 例如:如果M3要发信息给A必须经过C和B;A和Fn也没法直接通信,必须经过D,这种做法实在非常恶心 这些都是以前的老系统,我感觉这个系统的进程通信设计的非常不好。 我的新思路如下: 1.定义一个消息中心服务进程 2.所有需要通信的进程,必须有一个唯一的名称,然后注册到消息中心服务进程,所有需要通信的消息都发送到消息中心服务进程,然后该消息被转发给目标进程 3.各个进程的地位是平等的,打破上下级的关系,当任意两个进程需要通信时只需要知道对方的名称就可以给对方发消息 4.定一个进程通信包,在这个包里提供和中心消息服务进程通信的所有功能,并对外提供接口(注册,接收消息,发送消息),相当于一个API,其他程序如果想要在 代码中增加进程通信的功能就导入这个jar包,调用相应的接口就可以收发消息,使得进程通信功能和业务代码耦合降到最低。 5.重新定义数据通信协议,比如: 我定义10001的消息格式是: {sender:"xProcessor", receiver:"Adapter_01", msgcode:"10001", fieldnames:"f1,f2,f3", fieldtype:"int,string,float", f1:"10",f2:"xxxx OK",f3:"49.7321"} 各字段说明如下: sender:发送者的进程名称,人为定义的 reciver:接收者的进程名称,人为定义的 msgcode:消息编号,我要定义很多消息,因此可以有很多个编号 fieldnames:字段名列表 fieldtype:字段类型列表 f1:承载数据的字段 f2:承载数据的字段 f3:承载数据的字段 我定义10002的消息格式是: {sender:"xProcessor", receiver:"Adapter_01", msgcode:"10002", fieldnames:"f1,f2,f3,f4", fieldtype:"string,string,string,string", f1:"v1",f2:"v2",f3:"v3",f4:"v4"} 诸如此类,我就可以很轻松的定义很多种不同的消息,这样作的好处是: 1.消息通道和消息格式本身无关, 2.只有发送进程和目标接收进程关系消息具体格式 我觉得我的想法有一定的可行性,并且想尽量借助并使用ActiveMQ来实现,但是我对ActiveMQ不是很熟, 我知道ActiveMQ中有订阅和发布两种方式,但是不明白如果用ActiveMQ实现上面的我这种做法,应该如何来设计,希望大家能一起讨论一下 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2011-11-28
我也遇到和你一样的问题
感觉的我们这种需求,不适合用activemq,因为mq是一个异步消息中间件。而我们的需求应该是一个实时的同步消息中间件。 目前没找到好的办法。要开发一个实时消息中间件可不是一个容易的事 |
|
返回顶楼 | |
发表时间:2011-11-28
你要想明白你是同步通信还是异步通信,你是要可靠通信还是非可靠通信。
对你的服务之间的调用做个梳理,划分到上述的四个象限,然后再去寻找恰当的产品。两个关键词:RPC和MQ。 |
|
返回顶楼 | |
发表时间:2011-11-30
感谢dennis_zane的建议,我们的系统其实目前是异步通信的,要求非可靠通信。其实实时和非实时只是相对的,根据目前的测试,使用一个进程向一个Queue中发送消息,在另一个进程中监听这个Queue的消息,因为是测试,所有目前发送消息的速度是1000个/秒,在接收进程中,接收消息的速度也是1000个/秒,目前没看到有延迟,这只是在一台电脑上的测试结果,也许在局域网中,才能看出来真正的延迟
|
|
返回顶楼 | |