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

而消息服务这块，则面临着使用什么样的技术实现。

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

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

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

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

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

例如，对接了十几套甚至几十套TMS的情况下，消息中间件的主题，该如何规划？会不会出现众多类似的消息主题和繁多的消息通道？
再比如，复杂业务场景下，例如对已经委托过的运输需求单进行改派，由承运商A更换为承运商B，则意味着，不仅需要给新承运商B发一条委托单创建消息，而且还需要给原承运商A发一条委托单作废的消息。

以上举例的两种情况下， 消息中间件自身的功能是难以满足的，这其实跟职责定位有关，消息中间件的重心在于消息的可靠性传输，而不涉及到复杂的权限控制和逻辑处理。

综上，我们需要一个能自己控制权限，进行消息处理的功能组件，而这个组件，底层可以依托成熟的消息中间件来实现消息的发送功能，但必须进行功能扩展，并且扩展也不是那么灵活和方便。

那么，不使用消息中间件，用网络通信框架是否可行吗？

经过了解和思考后，不仅是可行的，而且是最佳选择，完全可以定制一些高度复杂的业务逻辑，来满足业务需求和需要。

目前主流的网络通信框架，非netty莫属。

在前几年的技术实现时，或者称接口开放平台1.0版本，由于各种客观因素影响，采用的技术框架不是netty，而是mina。
mina和netty的原作者都是1个人，mina出现的更早一些，在生产环境运行了几年，性能和稳定性也都没什么问题。

现在计划采用目前主流的netty框架，将整个接口开放平台进行升级为2.0版本。