聊聊草草
實(shí)現(xiàn)一套通信框架
A - 移動(dòng)終端； B - 接入服務(wù)器(網(wǎng)關(guān)) , C,D,E - 內(nèi)部服務(wù)系統(tǒng) ， M -內(nèi)部服務(wù)系統(tǒng)的消息隊(duì)列
B 用于接入成千上萬(wàn)的A，B不具備業(yè)務(wù)能力，只有CDE才能與A進(jìn)行業(yè)務(wù)交互，M充當(dāng)消息管道。
一般的做法，各個(gè)系統(tǒng)模塊指定標(biāo)準(zhǔn)協(xié)議，可以是xml或者二進(jìn)制的，然后各開(kāi)發(fā)各的，socket或者h(yuǎn)ttp等部件，開(kāi)發(fā)語(yǔ)言也是cpp，python，java齊上陣。
這種開(kāi)發(fā)模式過(guò)于繁瑣，模塊之間的耦合比較緊密，應(yīng)該把應(yīng)用和通信細(xì)節(jié)剝離出來(lái)。
我的做法是所有有系統(tǒng)對(duì)象之間的消息傳遞都是基于Rpc接口級(jí)的調(diào)用，更本不設(shè)計(jì)通信、協(xié)議編碼，只要根據(jù)IDL就可以，A請(qǐng)求C的服務(wù)，那A只需要調(diào)用C的接口函數(shù)即可，底部的工作：
A到B的socket通信，B將A的消息轉(zhuǎn)換到M，M再傳輸?shù)紺，這些工作都可以透過(guò)Rpc層完成透明，反過(guò)來(lái)C的調(diào)用請(qǐng)求也安原路返回到A。
C要發(fā)送消息到A，那調(diào)用A的接口，rpc層自動(dòng)將請(qǐng)求轉(zhuǎn)化未MQ協(xié)議，被路由到B，B找到A的鏈接，并將Mq消息轉(zhuǎn)化未socket消息傳遞到A，A端接收消息轉(zhuǎn)換成Rpc函數(shù)回調(diào)到A的應(yīng)用代碼。
除了簡(jiǎn)單的調(diào)用、返回方式還有
單項(xiàng)調(diào)用請(qǐng)求、異步調(diào)用請(qǐng)求、消息廣播請(qǐng)求
B端可以通過(guò)外部配置使得A的請(qǐng)求路由到C，或者D，或者全部接收，取決與應(yīng)用需求(應(yīng)用還是集群)
MQ如果系統(tǒng)總線一般，將各個(gè)服務(wù)子系統(tǒng)鏈接成網(wǎng)絡(luò)，是構(gòu)成整個(gè)系統(tǒng)的基礎(chǔ)。Rpc可以解脫程序員，讓其將經(jīng)歷花在具體業(yè)務(wù)上，而且基本只要編寫(xiě)若干的服務(wù)接口函數(shù)即可。
當(dāng)然要實(shí)現(xiàn)以上功能特點(diǎn)，很多可用的框架，CORBA，DCOM，ICE等等，但這些過(guò)于龐大，對(duì)環(huán)境要求也有限制，如果要更高效、靈活的運(yùn)用和包裝需要大量修改其底層代碼，與第三方的整合只能工作在他們的上層接口上，這個(gè)令人很沮喪，會(huì)導(dǎo)致產(chǎn)生更多的依賴和復(fù)雜的編程技巧。
這些全都丟棄，還是自己的rpc