在很多的业务场景中,我们都需要消费流式消息,然后对消息进行处理、计算和逻辑处理等,从而得出最终的数据结果或者业务处理结果。 典型的处理场景就是,应用要使用各个消息系统对应的SDK,如Kafka Client, RabbitMQ Client等,然后进行进行消息订阅。这种方式存在一定的问题:
- 应用要连接到消息系统,需要特定语言的SDK支持,如果你是使用一个新的语言,而该语言对应的消息系统SDK没有或者不稳定,这个时候就非常麻烦,你自己开发,那么难度还是非常高的。举一个例子,你现在想使用Rust开发应用,想使用Apache RocketMQ,那么不好意思,没有Rust Client,你需要等要不你自己开发。
- 如果对接多个消息系统,如Kafka、RabbitMQ、RocketMQ等,要使用各种SDK,对接不同的系统等,非常麻烦,同时也导致你系统臃肿不堪。
- API不统一: 不同的消息系统,API各不相同,要进行抽象等。
借助于RSocket的Request/Stream支持,让我们看一下新的结构会如何:
在上述架构中,我们可以使用一个Streaming Broker帮助屏蔽各个消息系统对接的细节,然后由Streaming Broker对外提供流式消息。应用只需要通过RSocket协议连接到Streaming Broker就可以,这样做的好处有:
- 不用再对接各种消息系统啦,各种语言SDK等问题,只需要使用RSocket SDK就可以,当然RSocket SDK非常小,而且各种语言都支持,不用担心Rust连接不上RocketMQ的问题啦。一个微服务应用只为了发一条Kafka消息,结果引入了20M的jar包,这是多不划算的事情。
- API统一啦。 其实应用只关心要处理的流式消息,至于是从Kafka、RabbitMQ等,全部不用关心,只要发起一个Request/Stream请求就可以啦。
- 系统升级和切换容易: 如果你想升级Kafka集群,担心SDK兼容问题,需要协调各个应用升级,现在不用担心啦,直接搞定Streaming Broker和集群本身就可以啦,消息消费端无感。
Request/Stream可以更好支持现在Streaming、Pub/Sub场景,如果你有上述的一些担心,我们建议你使用尝试一下RSocket的Streaming集成方案,当然如果你消息消费场景不复杂,同时消息系统统一,那么之前的方案也是不错的选择。