基于消息发送中间件的反思

最近项目需要使用JMS来进行消息收发,由于第一次接触,且业务场景为:

将Web服务器部署于机器A, 通过Web点击触发部署于机器B的job

 

看来许多资料,写一点心路历程

1. ActiveMQ

使用ActiveMQ是我在网上查询JMS相关资料看到的第一个中间件。

但是ActiveMQ需要在机器上部署环境,相当于客户端A --> ActiveMQ 端口 -- >服务器B这样的过程

就个人理解而言,这相当于最原始的中间件收发, 等于我们去创建一个新的服务器,以它作为媒介,两台机器同时连接该媒介,客户端发送;服务器端监听,这样的理解和传送方式都较为直白,不足之处在于ActiveMQ的环境部署,由于机器的限制和未来生产环境的部署较为复杂不便, 该方案被立刻kill了

 

2. Kafka

由于机器B上已经配置了Kafka,所以我们如果使用Kafka作为中间件,可以通过机器B的端口直接进行连接和监听, 同时我也思考,能不能使用Kafka直接发送文件内容,但是由于Kafka收发具有文件大小限制,不太适合文件内容的直接发送,因此还是认为发送消息触发job后再去拿文件较为合适。但是这个方案也有缺点,比如Kafka的topic可能有所限制,Kafka不一定配置在生产环境上,如果自己配,还需要配zookeeper,虽然是轻量级的中间件,但是就配置而言其实依然复杂。

 

3. Hazelcast

使用Hazelcast来收发消息可以直接指定自己的topic并且只需要指定监听端/服务器端的监听地址即可,不需要指定端口,较为适应该业务场景,且不需要配置环境,只需要导入jar包即可。关于这块的具体数据传递还有待学习。//TODO:未完待填充Hazelcast相关内容

©️2020 CSDN 皮肤主题: 技术黑板 设计师:CSDN官方博客 返回首页