由开发项目衍生出的框架级别副产品

曾经有几年，一直在纠结着分布式系统开发和消息中间件，尤其是如何在不改变现有的开发思路，和开发模式，包括代码调用方式的基础上，实现异步消息调用和路由的分发均衡。

这其中曾经去看了不少别人的思路，也去看了开源分布式框架的一些思路，但是总感觉与自己想要的不一致。

但具体实现也没有个定型的思路，这其中，曾经总结或探讨过一些方法、方式，曾经想着去套用一些别人的东西，但发现很难整合。

在上一个项目中，涉及到数据的客户端异步准实时上传和服务器的异步调度执行，这个原来曾写过一些实现，但是代码的友好度很差，在实现调度时，需要预声明很多的与调度相关的信息，调度代码严重影响了主业务逻辑代码的可读性，软件的设计都是被项目逼出来的，反观本次项目，需要在多个地方实现异步消息队列机制和异步调用处理，如果用微软的MessageQueue等机制，可以比较好的实现消息排队，但是消息的解包反向调用，则需要编写大量的代码。

现在在同步调用过程中，已经实现了RPC，由于RPC的特殊性，开发人员可以基于接口声明，实现服务器端和客户端的一致代码调用和逻辑编写，这个过程是很舒服的，很好用的，但是有时候，调用过程不能放到同步调用，异步调用又需要排队，并且会有多个调用接口同时发起，为了解决RPC的异步调用，一种思路是修改通信协议层，实现直接的排队处理，这在异步客户端回调中，难度太高，实现不太现实，还有一种办法，是利用方法和参数的重新实例化，构建新的调用实例，只是新的调用实例放到了异步消息队列中，利用异步消息队列做调用的调度中转，这样调度过程其实上升到了业务层，在业务层开发人员可以根据业务需求，自然的将某一执行过程，压入消息队列，而再由消息队列进行方法签名和参数的序列化，序列化的数据直接放在本地的硬盘上，由数据库构建统一索引，进行反向排队调用，最后又转化到RPC调用接口上，实现了一样的调用效果。

这种机制解决了客户端或服务器端的异步处理，尤其是大数据文件的缓慢异步处理，包括数据库长时间写入等，并发量也由消息队列自行进行连接控制。这在本地异步调用场合，效率会十分高，并且业务接口清晰合理，在发起调用的地方，声明性的工作基本没有了，所有的调用由于由消息调度层处理，整个处理机制是一个强类型的过程，舒服可靠。

反推之，如果把消息队列底层再打通，将方法签名和参数序列化的硬盘字节流保存工作，推送到远程服务器，由远程服务器的消息队列进行字节流的读取和保存，字节流文件保存到远程服务器，再在远程服务器上部署一套与本地服务器一样的业务执行代码，那远程服务器就可以执行预定的业务逻辑了，如果再在消息队列底层加入与远程TCP连接的负载均衡机制，来动态监测远程服务器的负载，那路由功能就有了，到了这里基本上一个可分布、可路由、稳定可靠，对业务干预较少的框架级的消息框架就呈现出来了。适当的注册机制，可以达到更高效和灵活的业务处理，这是下一步需要添加的。

整体思路，所有的RPC调用，消息队列不做干预，保留调度索引，调度参数和方法签名，统一保存到硬盘，消息队列只负责具体的索引调度起来，RPC的具体反向执行过程，还是由RPC框架实现。分布传输时，传调度索引的同时，把其对应的文件字节流，一起带入远端服务器。

开发人员只需要开发一套业务处理代码，为了实现多点的业务处理，抛入消息队列，由消息队列根据远程调用注册、订阅实现分发。达到分布式调用的目的，不过注册、订阅如何能反向映射到业务层面，这是下一步要考虑解决的，前置的东西已经很好的在项目中使用了。