聊聊草草
實現一套通信框架
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