聊聊草草
实现一套通信框架
A - 移动终端； B - 接入服务器(网关) , C,D,E - 内部服务系统 ， M -内部服务系统的消息队列
B 用于接入成千上万的A，B不具备业务能力，只有CDE才能与A进行业务交互，M充当消息管道。
一般的做法，各个系统模块指定标准协议，可以是xml或者二进制的，然后各开发各的，socket或者http等部件，开发语言也是cpp，python，java齐上阵。
这种开发模式过于繁琐，模块之间的耦合比较紧密，应该把应用和通信细节剥离出来。
我的做法是所有有系统对象之间的消息传递都是基于Rpc接口级的调用，更本不设计通信、协议编码，只要根据IDL就可以，A请求C的服务，那A只需要调用C的接口函数即可，底部的工作：
A到B的socket通信，B将A的消息转换到M，M再传输到C，这些工作都可以透过Rpc层完成透明，反过来C的调用请求也安原路返回到A。
C要发送消息到A，那调用A的接口，rpc层自动将请求转化未MQ协议，被路由到B，B找到A的链接，并将Mq消息转化未socket消息传递到A，A端接收消息转换成Rpc函数回调到A的应用代码。
除了简单的调用、返回方式还有
单项调用请求、异步调用请求、消息广播请求
B端可以通过外部配置使得A的请求路由到C，或者D，或者全部接收，取决与应用需求(应用还是集群)
MQ如果系统总线一般，将各个服务子系统链接成网络，是构成整个系统的基础。Rpc可以解脱程序员，让其将经历花在具体业务上，而且基本只要编写若干的服务接口函数即可。
当然要实现以上功能特点，很多可用的框架，CORBA，DCOM，ICE等等，但这些过于庞大，对环境要求也有限制，如果要更高效、灵活的运用和包装需要大量修改其底层代码，与第三方的整合只能工作在他们的上层接口上，这个令人很沮丧，会导致产生更多的依赖和复杂的编程技巧。
这些全都丢弃，还是自己的rpc