怎么接收和處理流？輪訓(xùn)JMSQueue來(lái)接收Message，接收到后進(jìn)行處理，處理完畢后仍然是以Message的方式放入Queue中發(fā)送或Multicast。

傳輸協(xié)議是？不限。

基于JMS也是常用的實(shí)現(xiàn)遠(yuǎn)程異步調(diào)用的方法之一。

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

RMI調(diào)用遠(yuǎn)程對(duì)象方法，允許方法返回Java對(duì)象以及基本數(shù)據(jù)類型，而RPC不支持對(duì)象的概念，傳送到RPC服務(wù)的消息由外部數(shù)據(jù)表示
(External Data Representation, XDR) 語(yǔ)言表示，這種語(yǔ)言抽象了字節(jié)序類和數(shù)據(jù)類型結(jié)構(gòu)之間的差異。只有由
XDR 定義的數(shù)據(jù)類型才能被傳遞，可以說(shuō) RMI 是面向?qū)ο蠓绞降腏ava 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”的類中，名叫“methodname”。然后RPC服務(wù)器就去搜索與之相匹配的類和方法，并把它作為那種方法參數(shù)類型的輸入。這里的參數(shù)類型是與RPC請(qǐng)求中的類型是匹配的。一旦匹配成功，這個(gè)方法就被調(diào)用了，其結(jié)果被編碼后返回客戶方。

RPC本身沒(méi)有規(guī)范,但基本的工作機(jī)制是一樣的，即：serialization/deserialization+stub+skeleton，寬泛的講，只要能實(shí)現(xiàn)遠(yuǎn)程調(diào)用，都是RPC，如:rmi.net-remoting ws/soap/rest hessian xmlrpc thrift potocolbuffer。

在Java里提供了完整的sockets通訊接口，但sockets要求客戶端和服務(wù)端必須進(jìn)行應(yīng)用級(jí)協(xié)議的編碼交換數(shù)據(jù)，采用sockets是非常麻煩的。一個(gè)代替Sockets的協(xié)議是RPC(RemoteProcedure Call), 它抽象出了通訊接口用于過(guò)程調(diào)用，使得編程者調(diào)用一個(gè)遠(yuǎn)程過(guò)程和調(diào)用本地過(guò)程同樣方便。RPC系統(tǒng)采用XDR來(lái)編碼遠(yuǎn)程調(diào)用的參數(shù)和返回值。但RPC并不支持對(duì)象，所以，面向?qū)ο蟮倪h(yuǎn)程調(diào)用RMI(Remote Method Invocation)成為必然選擇。采用RMI，調(diào)用遠(yuǎn)程對(duì)象和調(diào)用本地對(duì)象同樣方便。RMI 采用JRMP(Java RemoteMethod Protocol)通訊協(xié)議，是構(gòu)建在TCP/IP協(xié)議上的一種遠(yuǎn)程調(diào)用方法。

采用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)用。

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專注于遠(yuǎn)程服務(wù)調(diào)用，jms專注于信息交換。

大多數(shù)情況下Webservice是兩系統(tǒng)間的直接交互（Consumer Producer），而大多數(shù)情況下jms是三方系統(tǒng)交互（Consumer 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)方案；

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)各有千秋吧。

目前java領(lǐng)域可用于實(shí)現(xiàn)遠(yuǎn)程通訊的框架或library，知名的有：JBoss-Remoting、Spring-Remoting、Hessian、Burlap、XFire(Axis)、ActiveMQ、Mina、Mule、EJB3等等，來(lái)對(duì)每種做個(gè)簡(jiǎn)單的介紹和評(píng)價(jià)，其實(shí)呢，要做分布式服務(wù)框架，這些東西都是要有非常深刻的了解的，因?yàn)榉植际椒?wù)框架其實(shí)是包含了解決分布式領(lǐng)域以及應(yīng)用層面領(lǐng)域兩方面問(wèn)題的。

當(dāng)然，你也可以自己根據(jù)遠(yuǎn)程網(wǎng)絡(luò)通信原理(transport protocol+Net IO)去實(shí)現(xiàn)自己的通訊框架或library。

那么在了解這些遠(yuǎn)程通訊的框架或library時(shí)，會(huì)帶著什么問(wèn)題去學(xué)習(xí)呢？

是基于什么協(xié)議實(shí)現(xiàn)的？

怎么發(fā)起請(qǐng)求？

怎么將請(qǐng)求轉(zhuǎn)化為符合協(xié)議的格式的？

使用什么傳輸協(xié)議傳輸？

響應(yīng)端基于什么機(jī)制來(lái)接收請(qǐng)求？

怎么將流還原為傳輸格式的？

處理完畢后怎么回應(yīng)？

Spring-remoting是Spring提供java領(lǐng)域的遠(yuǎn)程通訊框架，基于此框架，同樣也可以很簡(jiǎn)單的將普通的spring bean以某種遠(yuǎn)程協(xié)議的方式來(lái)發(fā)布，同樣也可以配置spring bean為遠(yuǎn)程調(diào)用的bean。

是基于什么協(xié)議實(shí)現(xiàn)的？作為一個(gè)遠(yuǎn)程通訊的框架，Spring通過(guò)集成多種遠(yuǎn)程通訊的library，從而實(shí)現(xiàn)了對(duì)多種協(xié)議的支持，例如rmi、http+io、xml-rpc、binary-rpc等。

怎么發(fā)起請(qǐng)求？在Spring中，由于其對(duì)于遠(yuǎn)程調(diào)用的bean采用的是proxy實(shí)現(xiàn)，發(fā)起請(qǐng)求完全是通過(guò)服務(wù)接口調(diào)用的方式。

怎么將請(qǐng)求轉(zhuǎn)化為符合協(xié)議的格式的？Spring按照協(xié)議方式將請(qǐng)求的對(duì)象信息轉(zhuǎn)化為流，例如Spring Http
Invoker是基于Spring自己定義的一個(gè)協(xié)議來(lái)實(shí)現(xiàn)的，傳輸協(xié)議上采用的為http，請(qǐng)求信息是基于java串行化機(jī)制轉(zhuǎn)化為流進(jìn)行傳輸。

使用什么傳輸協(xié)議傳輸？支持多種傳輸協(xié)議，例如rmi、http等等。

響應(yīng)端基于什么機(jī)制來(lái)接收請(qǐng)求？響應(yīng)端遵循協(xié)議方式來(lái)接收請(qǐng)求，對(duì)于使用者而言，則只需通過(guò)spring的配置方式將普通的spring
bean配置為響應(yīng)端或者說(shuō)提供服務(wù)端。

怎么將流還原為傳輸格式的？按照協(xié)議方式來(lái)進(jìn)行還原。

處理完畢后怎么回應(yīng)？處理完畢后直接返回即可，spring-remoting將根據(jù)協(xié)議方式來(lái)做相應(yīng)的序列化。

Hessian是由caucho提供的一個(gè)基于binary-RPC實(shí)現(xiàn)的遠(yuǎn)程通訊library。

是基于什么協(xié)議實(shí)現(xiàn)的？基于Binary-RPC協(xié)議實(shí)現(xiàn)。

怎么發(fā)起請(qǐng)求？需通過(guò)Hessian本身提供的API來(lái)發(fā)起請(qǐng)求。

怎么將請(qǐng)求轉(zhuǎn)化為符合協(xié)議的格式的？Hessian通過(guò)其自定義的串行化機(jī)制將請(qǐng)求信息進(jìn)行序列化，產(chǎn)生二進(jìn)制流。

使用什么傳輸協(xié)議傳輸？Hessian基于Http協(xié)議進(jìn)行傳輸。

響應(yīng)端基于什么機(jī)制來(lái)接收請(qǐng)求？響應(yīng)端根據(jù)Hessian提供的API來(lái)接收請(qǐng)求。

怎么將流還原為傳輸格式的？Hessian根據(jù)其私有的串行化機(jī)制來(lái)將請(qǐng)求信息進(jìn)行反序列化，傳遞給使用者時(shí)已是相應(yīng)的請(qǐng)求信息對(duì)象了。

處理完畢后怎么回應(yīng)？處理完畢后直接返回，hessian將結(jié)果對(duì)象進(jìn)行序列化，傳輸至調(diào)用端。

Burlap也是有caucho提供，它和hessian的不同在于，它是基于XML-RPC協(xié)議的。

是基于什么協(xié)議實(shí)現(xiàn)的？基于XML-RPC協(xié)議實(shí)現(xiàn)。

怎么發(fā)起請(qǐng)求？根據(jù)Burlap提供的API。

怎么將請(qǐng)求轉(zhuǎn)化為符合協(xié)議的格式的？將請(qǐng)求信息轉(zhuǎn)化為符合協(xié)議的XML格式，轉(zhuǎn)化為流進(jìn)行傳輸。

使用什么傳輸協(xié)議傳輸？Http協(xié)議。

響應(yīng)端基于什么機(jī)制來(lái)接收請(qǐng)求？監(jiān)聽(tīng)Http請(qǐng)求。

怎么將流還原為傳輸格式的？根據(jù)XML-RPC協(xié)議進(jìn)行還原。

處理完畢后怎么回應(yīng)？返回結(jié)果寫入XML中，由Burlap返回至調(diào)用端。

XFire、Axis是Webservice的實(shí)現(xiàn)框架，WebService可算是一個(gè)完整的SOA架構(gòu)實(shí)現(xiàn)標(biāo)準(zhǔn)了，因此采用XFire、Axis這些也就意味著是采用webservice方式了。

是基于什么協(xié)議實(shí)現(xiàn)的？基于SOAP協(xié)議。
怎么發(fā)起請(qǐng)求？獲取到遠(yuǎn)端service的proxy后直接調(diào)用。
怎么將請(qǐng)求轉(zhuǎn)化為符合協(xié)議的格式的？將請(qǐng)求信息轉(zhuǎn)化為遵循SOAP協(xié)議的XML格式，由框架轉(zhuǎn)化為流進(jìn)行傳輸。
使用什么傳輸協(xié)議傳輸？Http協(xié)議。
響應(yīng)端基于什么機(jī)制來(lái)接收請(qǐng)求？監(jiān)聽(tīng)Http請(qǐng)求。
怎么將流還原為傳輸格式的？根據(jù)SOAP協(xié)議進(jìn)行還原。
處理完畢后怎么回應(yīng)？返回結(jié)果寫入XML中，由框架返回至調(diào)用端。

ActiveMQ是JMS的實(shí)現(xiàn)，基于JMS這類消息機(jī)制實(shí)現(xiàn)遠(yuǎn)程通訊是一種不錯(cuò)的選擇，畢竟消息機(jī)制本身的功能使得基于它可以很容易的去實(shí)現(xiàn)同步/異步/單向調(diào)用等，而且消息機(jī)制從容錯(cuò)角度上來(lái)說(shuō)也是個(gè)不錯(cuò)的選擇，這是Erlang能夠做到容錯(cuò)的重要基礎(chǔ)。

是基于什么協(xié)議實(shí)現(xiàn)的？基于JMS協(xié)議。

怎么發(fā)起請(qǐng)求？遵循JMS API發(fā)起請(qǐng)求。

怎么將請(qǐng)求轉(zhuǎn)化為符合協(xié)議的格式的？不太清楚，猜想應(yīng)該是二進(jìn)制流。

使用什么傳輸協(xié)議傳輸？支持多種傳輸協(xié)議，例如socket、http等等。

響應(yīng)端基于什么機(jī)制來(lái)接收請(qǐng)求？監(jiān)聽(tīng)符合協(xié)議的端口。

怎么將流還原為傳輸格式的？同問(wèn)題3。

處理完畢后怎么回應(yīng)？遵循JMS API生成消息，并寫入JMS Queue中。

Mina是Apache提供的通訊框架，在之前一直沒(méi)有提到網(wǎng)絡(luò)IO這塊，之前提及的框架或library基本都是基于BIO的，而Mina是采用NIO的，NIO在并發(fā)量增長(zhǎng)時(shí)對(duì)比BIO而言會(huì)有明顯的性能提升，而java性能的提升，與其NIO這塊與OS的緊密結(jié)合是有不小的關(guān)系的。

是基于什么協(xié)議實(shí)現(xiàn)的？基于純粹的Socket+NIO。

怎么發(fā)起請(qǐng)求？通過(guò)Mina提供的Client API。

怎么將請(qǐng)求轉(zhuǎn)化為符合協(xié)議的格式的？Mina遵循java串行化機(jī)制對(duì)請(qǐng)求對(duì)象進(jìn)行序列化。

使用什么傳輸協(xié)議傳輸？支持多種傳輸協(xié)議，例如socket、http等等。

響應(yīng)端基于什么機(jī)制來(lái)接收請(qǐng)求？以NIO的方式監(jiān)聽(tīng)協(xié)議端口。

怎么將流還原為傳輸格式的？遵循java串行化機(jī)制對(duì)請(qǐng)求對(duì)象進(jìn)行反序列化。

處理完畢后怎么回應(yīng)？遵循Mina API進(jìn)行返回。

MINA是NIO方式的，因此支持異步調(diào)用是毫無(wú)懸念的。

RPC（Remote Procedure Call）是一種遠(yuǎn)程調(diào)用協(xié)議，簡(jiǎn)單地說(shuō)就是能使應(yīng)用像調(diào)用本地方法一樣的調(diào)用遠(yuǎn)程的過(guò)程或服務(wù)，可以應(yīng)用在分布式服務(wù)、分布式計(jì)算、遠(yuǎn)程服務(wù)調(diào)用等許多場(chǎng)景。說(shuō)起 RPC 大家并不陌生，業(yè)界有很多開(kāi)源的優(yōu)秀 RPC 框架，例如 Dubbo、Thrift、gRPC、Hprose 等等。下面先簡(jiǎn)單介紹一下 RPC 與常用遠(yuǎn)程調(diào)用方式的特點(diǎn)，以及一些優(yōu)秀的開(kāi)源 RPC 框架。

RPC 與其它遠(yuǎn)程調(diào)用方式比較，RPC 與 HTTP、RMI、Web Service 都能完成遠(yuǎn)程調(diào)用，但是實(shí)現(xiàn)方式和側(cè)重點(diǎn)各有不同。

HTTP（HyperText Transfer Protocol）是應(yīng)用層通信協(xié)議，使用標(biāo)準(zhǔn)語(yǔ)義訪問(wèn)指定資源（圖片、接口等），網(wǎng)絡(luò)中的中轉(zhuǎn)服務(wù)器能識(shí)別協(xié)議內(nèi)容。HTTP 協(xié)議是一種資源訪問(wèn)協(xié)議，通過(guò) HTTP 協(xié)議可以完成遠(yuǎn)程請(qǐng)求并返回請(qǐng)求結(jié)果。

HTTP 的優(yōu)點(diǎn)是簡(jiǎn)單、易用、可理解性強(qiáng)且語(yǔ)言無(wú)關(guān)，在遠(yuǎn)程服務(wù)調(diào)用中包括微博有著廣泛應(yīng)用。HTTP 的缺點(diǎn)是協(xié)議頭較重，一般請(qǐng)求到具體服務(wù)器的鏈路較長(zhǎng)，可能會(huì)有 DNS 解析、Nginx 代理等。

RPC 是一種協(xié)議規(guī)范，可以把 HTTP 看作是一種 RPC 的實(shí)現(xiàn)，也可以把 HTTP 作為 RPC 的傳輸協(xié)議來(lái)應(yīng)用。RPC 服務(wù)的自動(dòng)化程度比較高，能夠?qū)崿F(xiàn)強(qiáng)大的服務(wù)治理功能，和語(yǔ)言結(jié)合更友好，性能也十分優(yōu)秀。與 HTTP 相比，RPC 的缺點(diǎn)就是相對(duì)復(fù)雜，學(xué)習(xí)成本稍高。

RMI（Remote Method Invocation）是指 Java 語(yǔ)言中的遠(yuǎn)程方法調(diào)用，RMI 中的每個(gè)方法都具有方法簽名，RMI 客戶端和服務(wù)器端通過(guò)方法簽名進(jìn)行遠(yuǎn)程方法調(diào)用。RMI 只能在 Java 語(yǔ)言中使用，可以把 RMI 看作面向?qū)ο蟮?Java RPC。

說(shuō)到這里，順便給大家推薦一個(gè)Java方面中高級(jí)程度的架構(gòu)交流學(xué)習(xí)群：650385180，里面會(huì)分享一些資深架構(gòu)師錄制的視頻錄像：有Spring，MyBatis，Netty源碼分析，高并發(fā)、高性能、分布式、微服務(wù)架構(gòu)的原理，JVM性能優(yōu)化這些成為架構(gòu)師必備的知識(shí)體系。還能領(lǐng)取免費(fèi)的學(xué)習(xí)資源，相信對(duì)于已經(jīng)工作和遇到技術(shù)瓶頸的碼友，在這個(gè)群里會(huì)有你需要的內(nèi)容。

Web Service 是一種基于 Web 進(jìn)行服務(wù)發(fā)布、查詢、調(diào)用的架構(gòu)方式，重點(diǎn)在于服務(wù)的管理與使用。Web Service 一般通過(guò) WSDL 描述服務(wù)，使用 SOAP通過(guò) HTTP 調(diào)用服務(wù)。

RPC 是一種遠(yuǎn)程訪問(wèn)協(xié)議，而 Web Service 是一種體系結(jié)構(gòu)，Web Service 也可以通過(guò) RPC 來(lái)進(jìn)行服務(wù)調(diào)用，因此 Web Service 更適合同一個(gè) RPC 框架進(jìn)行比較。當(dāng) RPC 框架提供了服務(wù)的發(fā)現(xiàn)與管理，并使用 HTTP 作為傳輸協(xié)議時(shí)，其實(shí)就是 Web Service。

相對(duì) Web Service，RPC 框架可以對(duì)服務(wù)進(jìn)行更細(xì)粒度的治理，包括流量控制、SLA 管理等，在微服務(wù)化、分布式計(jì)算方面有更大的優(yōu)勢(shì)。

RPC 可基于 HTTP 或 TCP 協(xié)議，Web Service 就是基于 HTTP 協(xié)議的 RPC，它具有良好的跨平臺(tái)性，但其性能卻不如基于 TCP 協(xié)議的 RPC。會(huì)兩方面會(huì)直接影響 RPC 的性能，一是傳輸方式，二是序列化。

眾所周知，TCP 是傳輸層協(xié)議，HTTP 是應(yīng)用層協(xié)議，而傳輸層較應(yīng)用層更加底層，在數(shù)據(jù)傳輸方面，越底層越快，因此，在一般情況下，TCP 一定比 HTTP 快。

在遠(yuǎn)程通訊領(lǐng)域中，涉及的知識(shí)點(diǎn)還是相當(dāng)?shù)亩嗟模缬校和ㄐ艆f(xié)議(Socket/tcp/http/udp/rmi/xml-rpc etc.)、消息機(jī)制、網(wǎng)絡(luò)IO（BIO/NIO/AIO）、MultiThread、本地調(diào)用與遠(yuǎn)程調(diào)用的透明化方案（涉及Java Classloader、Dynamic Proxy、Unit Test etc.）、異步與同步調(diào)用、網(wǎng)絡(luò)通信處理機(jī)制（自動(dòng)重連、廣播、異常、池處理等等）、Java Serialization (各種協(xié)議的私有序列化機(jī)制等)、各種框架的實(shí)現(xiàn)原理（傳輸格式、如何將傳輸格式轉(zhuǎn)化為流的、如何將請(qǐng)求信息轉(zhuǎn)化為傳輸格式的、如何接收流的、如何將流還原為傳輸格式的等等），要精通其中的哪些東西，得根據(jù)實(shí)際需求來(lái)決定了，只有在了解了原理的情況下才能很容易的做出選擇，甚至可以根據(jù)需求做私有的遠(yuǎn)程通訊協(xié)議，對(duì)于從事分布式服務(wù)平臺(tái)或開(kāi)發(fā)較大型的分布式應(yīng)用的人而言，我覺(jué)得至少上面提及的知識(shí)點(diǎn)是需要比較了解的。