[51CTO传媒TB]注意了!Kafka与RabbitMQ千万不要乱用…( 五 )


传统解决方案无法满足的高伸缩能力
大部分情况下这两个消息平台都可以满足我们的要求 。 但是 , 它取决于我们的架构师 , 他们会选择最合适的工具 。
当做决策的时候 , 我们需要考虑上面着重强调的功能性差异和非功能性限制 。
这些限制如下:
当前开发者对这两个消息平台的了解
托管云解决方案的可用性(如果适用)
每种解决方案的运营成本
适用于我们目标栈的SDK的可用性
当开发复杂的软件系统时 , 我们可能被诱导使用同一个消息平台去实现所有必须的消息用例 。
但是 , 从我的经验看 , 通常同时使用这两个消息平台能够带来更多的好处 。
例如 , 在一个事件驱动的架构系统中 , 我们可以使用RabbitMQ在服务之间发送命令 , 并且使用Kafka实现业务事件通知 。
原因是事件通知常常用于事件溯源 , 批量操作(ETL风格) , 或者审计目的 , 因此Kafka的消息留存能力就显得很有价值 。
相反 , 命令一般需要在消费者端做额外处理 , 并且处理可以失败 , 所以需要高级的容错处理能力 。
这里 , RabbitMQ在功能上有很多闪光点 。 以后我可能会写一篇详细的文章来介绍 , 但是你必须记住:你的里程(mileage)可能会变化 , 因为适合性取决于你的特定需求 。
总结
写这两篇文章是由于我观察到许多开发者把这RabbitMQ和Kafka作为等价来看待 。
我希望通过这两篇文章的帮助能够让你获得对这两种技术实现的深刻理解以及它们之间的技术差异 。
反过来通过它们之间的差异来影响这两个平台去给用例提供更好的服务 。 这两个消息平台都很棒 , 并且都能够给多个用例提供很好的服务 。
但是 , 作为解决方案架构师 , 取决于我们对每一个用例需求的理解 , 以及优化 , 然后选择最合适的解决方案 。
作者:王欢编译