通用接口开放平台设计与实现——（6）消息服务技术选型

背景

接口开放平台关于API服务部分，采用Restful接口，技术实现使用SpringMVC，没什么可多说的。
而消息服务这块，则面临着使用什么样的技术实现。

问题与挑战

在最初的需求明确后，咋一看，感觉与消息队列中间件的应用场景非常接近，就是消息的传递，而主流的消息中间件，像RabbitMQ、kafka、RocketMQ等，设计都很优秀，内部实现了高性能、高吞吐量，如果采用这种成熟的中间件，是否就不用自己来实现了？

结合业务场景深入思考，发现不是那么回事。

在这个应用场景下，有个关键的问题，是消息中间件未提供的能力或无法解决的，就是数据权限的控制。

例如：物流系统LMS对接若干家汽运承运商的运输管理系统TMS，LMS需要调度人员为运输需求单指派一家汽运承运商，然后需要消息服务中心，向被委托的这一家承运商的TMS系统，推送1条委托单创建消息，而如果把这条委托单消息推送给所有的承运商TMS系统，明显是很不合理的。

消息中间件评估

上面提到的几个主流消息队列中间件，虽然能提供一些消息主题分类和路由分发功能，但往往只是按消息主题建立消息通道，至于消息会发向什么地方，控制权不在于消息服务端，而是由客户端自行决定订阅哪些消息主题。在上面这种场景下，实际是做不到权限控制的。当然，我们也可以基于消息中间件的基础功能做一定的变通，例如将路由的key值通过密钥加密，只有相应的客户端才能通过加密或签名算法获取到消息通道，这样表