你的位置:首页 > ASP.net教程

[ASP.net教程]如何选择合适的开源消息中间件


原创文章转载请注明出处:@协思, http://zeeman.cnblogs.com
 
我们要引入消息中间件,势必要考虑成本收益问题,怎样达到最高的性价比。很多公司的研发团队还没有专门的资源投入到基础设施的研发中,使用开源产品,扬长避短无疑是最好的方式。业界消息中间件的种类繁多,各有侧重点,看着网上的一些选型推荐,你会觉得无所适从。但我可以告诉你的是,能用的真的不多:)。
 
对于一般的电子商务而言,不会为了性能降低可靠性,因为一个消息的丢失,可能意味着有一笔订单无法及时处理。追求极致性能的ZeroMQ一般用在游戏和工控方面,咱们做电商的还是别添乱了。就规模体量而言,大公司会自研消息队列,像阿里、新浪、亚马逊,京东,携程,据我所知,他们是自己开发维护着一套消息队列,为什么要自己做,说到底是他们使用消息队列的场景模式已经相对固化,需要在这种场景下追求最高的性能。中小公司没有这样的资源去做,采用通用的开源产品是很合适的,当你有那么大的体量时,再自己去发明一套定制轮子。
 
我们能选择的有三种:
 
1. ActiveMQ/ApolloMQ
优点:老牌的消息队列,使用Java语言编写。对JMS支持最好,采用多线程并发,资源消耗比较大。如果你的主语言是Java,可以重点考虑。
缺点:由于历史悠久,历史包袱较多,版本更新很缓慢。集群模式需要依赖Zookeeper实现。最新架构的产品被命名为Apollo,号称下一代ActiveMQ,目前案例较少。
 
2. RocketMQ/Kafka
优点:专为海量消息传递打造,主张使用拉模式,天然的集群、HA、负载均衡支持。话说还是那句话,适合不适合看你有没有那么大的量。
缺点:所谓鱼和熊掌不可兼得,放弃了一些消息中间件的灵活性,使用的场景较窄,需关注你的业务模式是否契合,否则山寨变相使用很别扭。除此之外,RocketMQ没有.NET下的客户端可用。RocketMQ身出名门,但使用者不多,生态较小,毕竟消息量能达到这种体量的公司不多,你也可以直接去购买阿里云的消息服务。Kafka生态完善,其代码是用Scala语言写成,可靠性比RocketMQ低一些。
 
3. RabbitMQ
优点:生态丰富,使用者众,有很多人在前面踩坑。AMQP协议的领导实现,支持多种场景。淘宝的MySQL集群内部有使用它进行通讯,OpenStack开源云平台的通信组件,最先在金融行业得到运用。
缺点:Erlang代码你Hold得住不? 虽然Erlang是天然集群化的,但RabbitMQ在高可用方面做起来还不是特别得心应手,别相信广告。
 
如果你不着急使用,也可以观望一下Redis作者的新产品Disque,还有Go语言写的Nsq也有不错的表现。
 
等你每个产品都作了测试就会发现,都有不爽的地方,毕竟不是为你量身打造的,所以我前面说能选择的不多。我建议使用的时候遵守AMTP或者STOMP规范,在规范之下,Client SDK和Service Broker是可替换的,不管你用哪种语言都可以在Github上找到一堆SDK,这两种规范ActiveMQ和RabbitMQ都是支持的,Kafka自成一派,基本上大多数人用不上。ActiveMQ和RabbitMQ之间对于有.NET背景的团队建议使用RabbitMQ,希望本文对你的选择性障碍有所缓解。