新的需求
削峰填谷能力:消息中心需要处理各条业务线的通知和营销任务的信息,而这些信息根据转化的需要,很大可能会集中化地在短期内进行推送,所以需要系统有削峰填谷的能力。 接口通用能力:消息中心的接入方不希望被绑定在某个接口上,不需要对该接口进行维护可以供多个业务方进行发送处理。 灵活类型划分:消息中心需要支持灵活的业务分类配置, 因为我们消息中心这里的业务配置非常多,大类就有短信、PUSH、微信推送,短信里又分通知、验证码和营销类别,而 PUSH 又区分 APNS、渠道服务商等第三方通道,以及 Android 厂商通道。 稳定处理能力:所依赖的技术产品运行稳定,因为处于消息中心的通道位置,不能忍受产品本身的稳定性波动带来的业务损失。 集群扩展能力:所依赖的技术产品没有扩容瓶颈,对于我们的业务继续发展有扩展的足够空间,可以快速进行业务扩容诉求。
新的解法
队列的扩展能力:在这方面,RabbitMQ 的单 Queue 的处理能力不容易扩展;而 RocketMQ 的 Topic 是有 ConsumerQueue 的参数来进行配置扩容的,在 Broker 的配置文件里指定,但是对 Broker 层面生效的;而 Kafka 的 Partition 可以每个 Topic 拥有不同的取值。这样在分类灵活性方面,Kafka 是最优的选择,RocketMQ 次之。 通用的接入方式:本质上 RabbitMQ、RocketMQ、Kafka 都是私有协议的方式接入,比较云上商业版本的接入方式,对于 Kafka 支持最纯粹友好,可以使用官方的接入方式进行接入。 消息的吞吐能力:在各类消息的对比测试中, 因为 Kafka 本身的处理机制原因,都是由客户端进行拉消息,整个 Broker 的处理方式比别的消息中间件要简洁,而 Kafka 的读写能力/吞吐量都是最大的。 集群稳定性能力:云上的消息产品都很友好地保持业务的连续性来进行升配操作,并且对于商业版本的 Kafka 做了 Broker 上的优化,存储上的优化,运维上的优化后,不需要担心自建集群出现的不稳定问题,完全满足骑士卡的需求。
业务价值
“在全球购骑士卡消息中心的搭建过程中,我们使用阿里云的Kafka完成了消息中心高吞吐量,稳定以及可扩展的目标。目前,消息中心作为业务运营推广的基石,发挥着重要作用,对于新业务的接入,通过消息队列的配置修改即可完成,对现有业务可以做到无侵入,尽可能的减少了故障发生的可能。” ——骑士卡CTO
﹀
﹀
﹀