幾種遠(yuǎn)程監(jiān)控通信方式的介紹

? ? ? ?一.RPC

　　RPC使用C/S方式，采用http協(xié)議，發(fā)送請(qǐng)求到服務(wù)器，等待服務(wù)器返回結(jié)果。這個(gè)請(qǐng)求包括一個(gè)參數(shù)集和一個(gè)文本集，通常形成“classname.methodname”形式。優(yōu)點(diǎn)是跨語(yǔ)言跨平臺(tái)，C端、S端有更大的獨(dú)立性，缺點(diǎn)是不支持對(duì)象，無(wú)法在編譯器檢查錯(cuò)誤，只能在運(yùn)行期檢查。

　　二.Web Service

　　Web Service提供的服務(wù)是基于web容器的，底層使用http協(xié)議，類(lèi)似一個(gè)遠(yuǎn)程的服務(wù)提供者，比如天氣預(yù)報(bào)服務(wù)，對(duì)各地客戶端提供天氣預(yù)報(bào)，是一種請(qǐng)求應(yīng)答的機(jī)制，是跨系統(tǒng)跨平臺(tái)的。就是通過(guò)一個(gè)servlet，提供服務(wù)出去。

　　首先客戶端從服務(wù)器的到WebService的WSDL（網(wǎng)絡(luò)服務(wù)描述語(yǔ)言），同時(shí)在客戶端聲稱(chēng)一個(gè)代理類(lèi)（Proxy Class） 這個(gè)代理類(lèi)負(fù)責(zé)與WebService服務(wù)器進(jìn)行Request 和Response 當(dāng)一個(gè)數(shù)據(jù)（XML格式的）被封裝成SOAP格式的數(shù)據(jù)流發(fā)送到服務(wù)器端的時(shí)候，就會(huì)生成一個(gè)進(jìn)程對(duì)象并且把接收到這個(gè)Request的SOAP包進(jìn)行解析，然后對(duì)事物進(jìn)行處理，處理結(jié)束以后再對(duì)這個(gè)計(jì)算結(jié)果進(jìn)行SOAP包裝，然后把這個(gè)包作為一個(gè)Response發(fā)送給客戶端的代理類(lèi)（Proxy Class），同樣地，這個(gè)代理類(lèi)也對(duì)這個(gè)SOAP包進(jìn)行解析處理，繼而進(jìn)行后續(xù)操作。這就是WebService的一個(gè)運(yùn)行過(guò)程。

　　Web Service大體上分為5個(gè)層次：

　　1. Http傳輸信道

　　2. XML的數(shù)據(jù)格式

　　3. SOAP封裝格式（soap用來(lái)描述傳遞信息的格式）

　　4. WSDL的描述方式

　　5. UDDI UDDI是一種目錄服務(wù)，企業(yè)可以使用它對(duì)Webservices進(jìn)行注冊(cè)和搜索

　　三.RMI （Remote Method Invocation）

　　RMI 采用stubs 和 skeletons來(lái)進(jìn)行遠(yuǎn)程對(duì)象（remote object）的通訊。stub 充當(dāng)遠(yuǎn)程對(duì)象的客戶端代理，有著和遠(yuǎn)程對(duì)象相同的遠(yuǎn)程接口，遠(yuǎn)程對(duì)象的調(diào)用實(shí)際是通過(guò)調(diào)用該對(duì)象的客戶端代理對(duì)象stub來(lái)完成的，通過(guò)該機(jī)制RMI就好比它是本地工作，采用tcp/ip協(xié)議，客戶端直接調(diào)用服務(wù)端上的一些方法。優(yōu)點(diǎn)是強(qiáng)類(lèi)型，編譯期可檢查錯(cuò)誤，缺點(diǎn)是只能基于Java語(yǔ)言，客戶機(jī)與服務(wù)器緊耦合。

　　來(lái)看下基于RMI的一次完整的遠(yuǎn)程通信過(guò)程的原理：1. 客戶端發(fā)起請(qǐng)求，請(qǐng)求轉(zhuǎn)交至RMI客戶端的stub類(lèi)；

　　2. stub類(lèi)將請(qǐng)求的接口、方法、參數(shù)等信息進(jìn)行序列化；

　　3. 基于socket將序列化后的流傳輸至服務(wù)器端；

　　4. 服務(wù)器端接收到流后轉(zhuǎn)發(fā)至相應(yīng)的skelton類(lèi)；

　　5. skelton類(lèi)將請(qǐng)求的信息反序列化后調(diào)用實(shí)際的處理類(lèi)；

　　6. 處理類(lèi)處理完畢后將結(jié)果返回給skelton類(lèi)；

　　7. Skelton類(lèi)將結(jié)果序列化，通過(guò)socket將流傳送給客戶端的stub；

　　8. stub在接收到流后反序列化，將反序列化后的java Object返回給調(diào)用者。

　　四.JMS（Java?Messaging Service）

　　JMS是Java的消息服務(wù)，JMS的客戶端之間可以通過(guò)JMS服務(wù)進(jìn)行異步的消息傳輸。JMS支持兩種消息模型：Point-to-Point（P2P）和Publish/Subscribe（Pub/Sub），即點(diǎn)對(duì)點(diǎn)和發(fā)布訂閱模型。

　　JMS呢，是實(shí)現(xiàn)java領(lǐng)域遠(yuǎn)程通信的一種手段和方法，基于JMS實(shí)現(xiàn)遠(yuǎn)程通信時(shí)和RPC是不同的，雖然可以做到RPC的效果，但因?yàn)椴皇菑膮f(xié)議 級(jí)別定義的，因此我們不認(rèn)為JMS是個(gè)RPC協(xié)議，但它確實(shí)是個(gè)遠(yuǎn)程通信協(xié)議，在其他的語(yǔ)言體系中也存在著類(lèi)似JMS的東西，可以統(tǒng)一的將這類(lèi)機(jī)制稱(chēng)為消 息機(jī)制，而消息機(jī)制呢，通常是高并發(fā)、分布式領(lǐng)域推薦的一種通信機(jī)制，這里的主要一個(gè)問(wèn)題是容錯(cuò)（詳細(xì)見(jiàn)ErLang論文）。

　　來(lái)看JMS中的一次遠(yuǎn)程通信的過(guò)程：

　　1. 客戶端將請(qǐng)求轉(zhuǎn)化為符合JMS規(guī)定的Message；

　　2. 通過(guò)JMS API將Message放入JMS Queue（點(diǎn)對(duì)點(diǎn)）或Topic（發(fā)布/訂閱）中；

　　3. 如為JMS Queue，則發(fā)送中相應(yīng)的目標(biāo)Queue中，如為T(mén)opic，則發(fā)送給訂閱了此Topic的JMS Queue。

　　4. 處理端則通過(guò)輪訓(xùn)JMS Queue，來(lái)獲取消息，接收到消息后根據(jù)JMS協(xié)議來(lái)解析Message并處理。

　　幾種遠(yuǎn)程監(jiān)控方式的比較

　　一、RPC與RMI

　　（1）RPC 跨語(yǔ)言，而 RMI只支持Java。

　?。?）RMI 調(diào)用遠(yuǎn)程對(duì)象方法，允許方法返回 Java 對(duì)象以及基本數(shù)據(jù)類(lèi)型，而RPC 不支持對(duì)象的概念，傳送到 RPC 服務(wù)的消息由外部數(shù)據(jù)表示 （External Data Representation，XDR） 語(yǔ)言表示，這種語(yǔ)言抽象了字節(jié)序類(lèi)和數(shù)據(jù)類(lèi)型結(jié)構(gòu)之間的差異。只有由 XDR 定義的數(shù)據(jù)類(lèi)型才能被傳遞， 可以說(shuō) RMI 是面向?qū)ο蠓绞降?java?RPC 。

　?。?）在方法調(diào)用上，RMI中，遠(yuǎn)程接口使每個(gè)遠(yuǎn)程方法都具有方法簽名。如果一個(gè)方法在服務(wù)器上執(zhí)行，但是沒(méi)有相匹配的簽名被添加到這個(gè)遠(yuǎn)程接口上，那么這個(gè)新方法就不能被RMI客戶方所調(diào)用。在RPC中，當(dāng)一個(gè)請(qǐng)求到達(dá)RPC服務(wù)器時(shí)，這個(gè)請(qǐng)求就包含了一個(gè)參數(shù)集和一個(gè)文本值，通常形成“classname.methodname”的形式。這就向RPC服務(wù)器表明，被請(qǐng)求的方法在為 “classname”的類(lèi)中，名叫“methodname”。然后RPC服務(wù)器就去搜索與之相匹配的類(lèi)和方法，并把它作為那種方法參數(shù)類(lèi)型的輸入。這里的參數(shù)類(lèi)型是與RPC請(qǐng)求中的類(lèi)型是匹配的。一旦匹配成功，這個(gè)方法就被調(diào)用了，其結(jié)果被編碼后返回客戶方。

　　二、JMS和RMI

　　采用JMS 服務(wù)，對(duì)象是在物理上被異步從網(wǎng)絡(luò)的某個(gè)JVM 上直接移動(dòng)到另一個(gè)JVM 上（是消息通知機(jī)制）

　　而RMI 對(duì)象是綁定在本地JVM 中，只有函數(shù)參數(shù)和返回值是通過(guò)網(wǎng)絡(luò)傳送的（是請(qǐng)求應(yīng)答機(jī)制）。

　　RMI一般都是同步的，也就是說(shuō)，當(dāng)client調(diào)用Server的一個(gè)方法的時(shí)候，需要等到對(duì)方的返回，才能繼續(xù)執(zhí)行client端，這個(gè)過(guò)程調(diào)用本地方法感覺(jué)上是一樣的，這也是RMI的一個(gè)特點(diǎn)。

　　JMS 一般只是一個(gè)點(diǎn)發(fā)出一個(gè)Message到Message Server，發(fā)出之后一般不會(huì)關(guān)心誰(shuí)用了這個(gè)message。

　　所以，一般RMI的應(yīng)用是緊耦合，JMS的應(yīng)用相對(duì)來(lái)說(shuō)是松散耦合應(yīng)用。

　　三、Webservice與RMI

　　RMI是在tcp協(xié)議上傳遞可序列化的java對(duì)象，只能用在java虛擬機(jī)上，綁定語(yǔ)言，客戶端和服務(wù)端都必須是java

　　webservice沒(méi)有這個(gè)限制，webservice是在http協(xié)議上傳遞xml文本文件，與語(yǔ)言和平臺(tái)無(wú)關(guān)

　　四、Webservice與JMS

　　Webservice專(zhuān)注于遠(yuǎn)程服務(wù)調(diào)用，jms專(zhuān)注于信息交換。

　　大多數(shù)情況下Webservice是兩系統(tǒng)間的直接交互（Consumer 《--》 Producer），而大多數(shù)情況下jms是三方系統(tǒng)交互（Consumer 《- Broker -》 Producer）。當(dāng)然，JMS也可以實(shí)現(xiàn)request-response模式的通信，只要Consumer或Producer其中一方兼任broker即可。

　　JMS可以做到異步調(diào)用完全隔離了客戶端和服務(wù)提供者，能夠抵御流量洪峰； WebService服務(wù)通常為同步調(diào)用，需要有復(fù)雜的對(duì)象轉(zhuǎn)換，相比SOAP，現(xiàn)在JSON，rest都是很好的http架構(gòu)方案；（舉一個(gè)例子，電子商務(wù)的分布式系統(tǒng)中，有支付系統(tǒng)和業(yè)務(wù)系統(tǒng)，支付系統(tǒng)負(fù)責(zé)用戶付款，在用戶在銀行付款后需要通知各個(gè)業(yè)務(wù)系統(tǒng)，那么這個(gè)時(shí)候，既可以用同步也可以用異步，使用異步的好處就能抵御網(wǎng)站暫時(shí)的流量高峰，或者能應(yīng)對(duì)慢消費(fèi)者。）

　　JMS是java平臺(tái)上的消息規(guī)范。一般jms消息不是一個(gè)xml，而是一個(gè)java對(duì)象，很明顯，jms沒(méi)考慮異構(gòu)系統(tǒng)，說(shuō)白了，JMS就沒(méi)考慮非java的東西。但是好在現(xiàn)在大多數(shù)的jms provider（就是JMS的各種實(shí)現(xiàn)產(chǎn)品）都解決了異構(gòu)問(wèn)題。相比WebService的跨平臺(tái)各有千秋吧。