RMI
成都創(chuàng)新互聯(lián)專注于長沙網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠為您提供長沙營銷型網(wǎng)站建設(shè)，長沙網(wǎng)站制作、長沙網(wǎng)頁設(shè)計(jì)、長沙網(wǎng)站官網(wǎng)定制、小程序設(shè)計(jì)服務(wù)，打造長沙網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供長沙網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。
RMI是個(gè)典型的為java定制的遠(yuǎn)程通信協(xié)議， 我們都知道，在single vm中，我們可以通過直接調(diào)用java object instance來實(shí)現(xiàn)通信，那么在遠(yuǎn)程通信時(shí)，如果也能按照這種方式當(dāng)然是最好了，這種遠(yuǎn)程通信的機(jī)制成為RPC（RemoteProcedure Call），RMI正是朝著這個(gè)目標(biāo)而誕生的。
傳輸?shù)臉?biāo)準(zhǔn)格式是Java Object Stream；基于Java串行化機(jī)制將請求的Java Object信息轉(zhuǎn)化為流。傳輸協(xié)議是Socket。
XML-RPC
XML-RPC也是一種和RMI類似的遠(yuǎn)程調(diào)用的協(xié)議，它和RMI的不同之處在于它以標(biāo)準(zhǔn)的xml格式來定義請求的信息(請求的對象、方法、參數(shù) 等)，這樣的好處是在跨語言通訊的時(shí)候也可以使用。所以RMI與RPC的區(qū)別之一是RPC是跨語言的。
傳輸?shù)臉?biāo)準(zhǔn)格式是XML，將XML轉(zhuǎn)化為流，傳輸協(xié)議是HTTP。
Binary-RPC
Binary-RPC和XML-RPC是差不多，不同之處僅在于傳輸?shù)臉?biāo)準(zhǔn)格式由XML轉(zhuǎn)為了二進(jìn)制的格式。
傳輸?shù)臉?biāo)準(zhǔn)格式是二進(jìn)制文件，將二進(jìn)制文件轉(zhuǎn)化為傳輸?shù)牧?，傳輸協(xié)議是HTTP。
SOAP
SOAP（SimpleObject Access Protocol），是一個(gè)用于分布式環(huán)境的、輕量級的、基于XML進(jìn)行信息交換的通信協(xié)議，可以認(rèn)為SOAP是XML RPC的高級版，兩者的原理完全相同，都是http+XML，不同的僅在于兩者定義的XML規(guī)范不同，SOAP也是Webservice采用的服務(wù)調(diào)用協(xié) 議標(biāo)準(zhǔn)。
CORBA
Common Object Request BrokerArchitecture（公用對象請求代理[調(diào)度]程序體系結(jié)構(gòu)），是一組用來定義“分布式對象系統(tǒng)”的標(biāo)準(zhǔn)，由OMG(Object Menagement Group)作為發(fā)起和標(biāo)準(zhǔn)制定單位。CORBA的目的是定義一套協(xié)議，符合這個(gè)協(xié)議的對象可以互相交互，不論它們是用什么樣的語言寫的，不論它們運(yùn)行于 什么樣的機(jī)器和操作系統(tǒng)。CORBA是個(gè)類似于SOA的體系架構(gòu)，涵蓋可選的遠(yuǎn)程通信協(xié)議，但其本身不能列入通信協(xié)議。
JMS
JMS，是實(shí)現(xiàn)java領(lǐng)域遠(yuǎn)程通信的一種手段和方法，基于JMS實(shí)現(xiàn)遠(yuǎn)程通信時(shí)和RPC是不同的，雖然可以做到RPC的效果，但因?yàn)椴皇菑膮f(xié)議 級別定義的，因此我們不認(rèn)為JMS是個(gè)RPC協(xié)議，但它確實(shí)是個(gè)遠(yuǎn)程通信協(xié)議，在其他的語言體系中也存在著類似JMS的東西，可以統(tǒng)一的將這類機(jī)制稱為消 息機(jī)制，而消息機(jī)制呢，通常是高并發(fā)、分布式領(lǐng)域推薦的一種通信機(jī)制，這里的主要一個(gè)問題是容錯(cuò)。JMS注重的是消息交換，RMI注重的是對象方法調(diào)用，所以目的不同。JMS大多時(shí)候是異步的松耦合，RMI大多時(shí)候是同步的緊耦合。
JMS規(guī)定的傳輸格式是Message，將參數(shù)信息放入Message中，傳輸協(xié)議不限?；贘MS也是常用的實(shí)現(xiàn)遠(yuǎn)程異步調(diào)用的方法之一。
RPC是遠(yuǎn)程過程調(diào)用的簡稱，廣泛應(yīng)用在大規(guī)模分布式應(yīng)用中，作用是有助于系統(tǒng)的垂直拆分，使系統(tǒng)更易拓展。Java中的RPC框架比較多，各有特色，廣泛使用的有RMI、Hessian、Dubbo等。RPC還有一個(gè)特點(diǎn)就是能夠跨語言。
1、RMI（遠(yuǎn)程方法調(diào)用）
JAVA自帶的遠(yuǎn)程方法調(diào)用工具，不過有一定的局限性，畢竟是JAVA語言最開始時(shí)的設(shè)計(jì)，后來很多框架的原理都基于RMI，RMI的使用如下：
對外接口
span?style="font-size:12px;"public?interface?IService?extends?Remote?{??
public?String?queryName(String?no)?throws?RemoteException;??
}/span
服務(wù)實(shí)現(xiàn)
import?java.rmi.RemoteException;??
import?java.rmi.server.UnicastRemoteObject;??
//?服務(wù)實(shí)現(xiàn)??
public?class?ServiceImpl?extends?UnicastRemoteObject?implements?IService?{??
/**?
*/??
private?static?final?long?serialVersionUID?=?682805210518738166L;??
/**?
*?@throws?RemoteException?
*/??
protected?ServiceImpl()?throws?RemoteException?{??
super();??
}??
/*?(non-Javadoc)?
*?@see?com.suning.ebuy.wd.web.IService#queryName(java.lang.String)?
*/??
@Override??
public?String?queryName(String?no)?throws?RemoteException?{??
//?方法的具體實(shí)現(xiàn)??
System.out.println("hello"?+?no);??
return?String.valueOf(System.currentTimeMillis());??
}??
}??
RMI客戶端
[java]?view?plain?copy
import?java.rmi.AccessException;??
import?java.rmi.NotBoundException;??
import?java.rmi.RemoteException;??
import?java.rmi.registry.LocateRegistry;??
import?java.rmi.registry.Registry;??
//?RMI客戶端??
public?class?Client?{??
public?static?void?main(String[]?args)?{??
//?注冊管理器??
Registry?registry?=?null;??
try?{??
//?獲取服務(wù)注冊管理器??
registry?=?LocateRegistry.getRegistry("127.0.0.1",8088);??
//?列出所有注冊的服務(wù)??
String[]?list?=?registry.list();??
for(String?s?:?list){??
System.out.println(s);??
}??
}?catch?(RemoteException?e)?{??
}??
try?{??
//?根據(jù)命名獲取服務(wù)??
IService?server?=?(IService)?registry.lookup("vince");??
//?調(diào)用遠(yuǎn)程方法??
String?result?=?server.queryName("ha?ha?ha?ha");??
//?輸出調(diào)用結(jié)果??
System.out.println("result?from?remote?:?"?+?result);??
}?catch?(AccessException?e)?{??
}?catch?(RemoteException?e)?{??
}?catch?(NotBoundException?e)?{??
}??
}??
}??
RMI服務(wù)端
[java]?view?plain?copy
import?java.rmi.RemoteException;??
import?java.rmi.registry.LocateRegistry;??
import?java.rmi.registry.Registry;??
//?RMI服務(wù)端??
public?class?Server?{??
public?static?void?main(String[]?args)?{??
//?注冊管理器??
Registry?registry?=?null;??
try?{??
//?創(chuàng)建一個(gè)服務(wù)注冊管理器??
registry?=?LocateRegistry.createRegistry(8088);??
}?catch?(RemoteException?e)?{??
}??
try?{??
//?創(chuàng)建一個(gè)服務(wù)??
ServiceImpl?server?=?new?ServiceImpl();??
//?將服務(wù)綁定命名??
registry.rebind("vince",?server);??
System.out.println("bind?server");??
}?catch?(RemoteException?e)?{??
}??
}??
}
2、Hessian（基于HTTP的遠(yuǎn)程方法調(diào)用）
基于HTTP協(xié)議傳輸，在性能方面還不夠完美，負(fù)載均衡和失效轉(zhuǎn)移依賴于應(yīng)用的負(fù)載均衡器，Hessian的使用則與RMI類似，區(qū)別在于淡化了Registry的角色，通過顯示的地址調(diào)用，利用HessianProxyFactory根據(jù)配置的地址create一個(gè)代理對象，另外還要引入Hessian的Jar包。
3、Dubbo（淘寶開源的基于TCP的RPC框架）
基于Netty的高性能RPC框架，是阿里巴巴開源的，總體原理如下：
微服務(wù)架構(gòu)已成為目前互聯(lián)網(wǎng)架構(gòu)的趨勢，關(guān)于微服務(wù)的討論，幾乎占據(jù)了各種技術(shù)大會的絕大多數(shù)版面。國內(nèi)使用最多的服務(wù)治理框架非阿里開源的 dubbo 莫屬，千米網(wǎng)也選擇了 dubbo 作為微服務(wù)治理框架。另一方面，和大多數(shù)互聯(lián)網(wǎng)公司一樣，千米的開發(fā)語言是多樣的，大多數(shù)后端業(yè)務(wù)由 java 支撐，而每個(gè)業(yè)務(wù)線有各自開發(fā)語言的選擇權(quán)，便出現(xiàn)了 nodejs，python，go 多語言調(diào)用的問題。
跨語言調(diào)用是一個(gè)很大的話題，也是一個(gè)很有挑戰(zhàn)的技術(shù)活，目前業(yè)界經(jīng)常被提及的解決方案有如下幾種，不妨拿出來老生常談一番：
當(dāng)我們再聊跨語言調(diào)用時(shí)我們在聊什么？縱觀上述幾個(gè)較為通用，成熟的解決方案，可以得出結(jié)論：解決跨語言調(diào)用的思路無非是兩種：
如果一個(gè)新型的團(tuán)隊(duì)面臨技術(shù)選型，我認(rèn)為上述的方案都可以納入?yún)⒖?，可考慮到遺留系統(tǒng)的兼容性問題
舊系統(tǒng)的遷移成本
這也關(guān)鍵的選型因素。我們做出的第一個(gè)嘗試，便是在 RPC 協(xié)議上下功夫。
通用協(xié)議的跨語言支持
springmvc的美好時(shí)代
springmvc
springmvc
在沒有實(shí)現(xiàn)真正的跨語言調(diào)用之前，想要實(shí)現(xiàn)“跨語言”大多數(shù)方案是使用 http 協(xié)議做一層轉(zhuǎn)換，最常見的手段莫過于借助 springmvc 提供的 controller/restController，間接調(diào)用 dubbo provider。這種方案的優(yōu)勢和劣勢顯而易見
通用協(xié)議的支持
事實(shí)上，大多數(shù)服務(wù)治理框架都支持多種協(xié)議，dubbo 框架除默認(rèn)的 dubbo 協(xié)議之外，還有當(dāng)當(dāng)網(wǎng)擴(kuò)展的?rest協(xié)議和千米網(wǎng)擴(kuò)展的?json-rpc?協(xié)議可供選擇。這兩者都是通用的跨語言協(xié)議。
rest 協(xié)議為滿足 JAX-RS 2.0 標(biāo)準(zhǔn)規(guī)范，在開發(fā)過程中引入了 @Path，@POST，@GET 等注解，習(xí)慣于編寫傳統(tǒng) rpc 接口的人可能不太習(xí)慣 rest 風(fēng)格的 rpc 接口。一方面這樣會影響開發(fā)體驗(yàn)，另一方面，獨(dú)樹一幟的接口風(fēng)格使得它與其他協(xié)議不太兼容，舊接口的共生和遷移都無法實(shí)現(xiàn)。如果沒有遺留系統(tǒng)，rest 協(xié)議無疑是跨語言方案最簡易的實(shí)現(xiàn)，絕大多數(shù)語言支持 rest 協(xié)議。
和 rest 協(xié)議類似，json-rpc 的實(shí)現(xiàn)也是文本序列化http 協(xié)議。dubbox 在 restful 接口上已經(jīng)做出了嘗試，但是 rest 架構(gòu)和 dubbo 原有的 rpc 架構(gòu)是有區(qū)別的，rest 架構(gòu)需要對資源(Resources)進(jìn)行定義， 需要用到 http 協(xié)議的基本操作 GET、POST、PUT、DELETE。在我們看來，restful 更合適互聯(lián)網(wǎng)系統(tǒng)之間的調(diào)用，而 rpc 更適合一個(gè)系統(tǒng)內(nèi)的調(diào)用。使用 json-rpc 協(xié)議使得舊接口得以兼顧，開發(fā)習(xí)慣仍舊保留，同時(shí)獲得了跨語言的能力。
千米網(wǎng)在早期實(shí)踐中采用了 json-rpc 作為 dubbo 的跨語言協(xié)議實(shí)現(xiàn)，并開源了基于 json-rpc 協(xié)議下的 python 客戶端?dubbo-client-py?和 node 客戶端?dubbo-node-client，使用 python 和 nodejs 的小伙伴可以借助于它們直接調(diào)用 dubbo-provider-java 提供的 rpc 服務(wù)。系統(tǒng)中大多數(shù) java 服務(wù)之間的互相調(diào)用還是以 dubbo 協(xié)議為主，考慮到新舊協(xié)議的適配，在不影響原有服務(wù)的基礎(chǔ)上，我們配置了雙協(xié)議。
dubbo 協(xié)議主要支持 java 間的相互調(diào)用，適配老接口；json-rpc 協(xié)議主要支持異構(gòu)語言的調(diào)用。
定制協(xié)議的跨語言支持
微服務(wù)框架所謂的協(xié)議(protocol)可以簡單理解為：報(bào)文格式和序列化方案。服務(wù)治理框架一般都提供了眾多的協(xié)議配置項(xiàng)供使用者選擇，除去上述兩種通用協(xié)議，還存在一些定制化的協(xié)議，如 dubbo 框架的默認(rèn)協(xié)議：dubbo 協(xié)議以及 motan 框架提供的跨語言協(xié)議：motan2。
motan2協(xié)議的跨語言支持
???motan2
motan2
motan2 協(xié)議被設(shè)計(jì)用來滿足跨語言的需求主要體現(xiàn)在兩個(gè)細(xì)節(jié)中—MetaData 和 motan-go。在最初的 motan 協(xié)議中，協(xié)議報(bào)文僅由 Header+Body 組成，這樣導(dǎo)致 path，param，group 等存儲在 Body 中的數(shù)據(jù)需要反序列得到，這對異構(gòu)語言來說是很不友好的，所以在 motan2 中修改了協(xié)議的組成；weibo 開源了?motan-go?，motan-php?，motan-openresty?,并借助于 motan-go 充當(dāng)了 agent 這一翻譯官的角色，使用 simple 序列化方案來序列化協(xié)議報(bào)文的 Body 部分（simple 序列化是一種較弱的序列化方案）。
???agent
agent
仔細(xì)揣摩下可以發(fā)現(xiàn)這么做和雙協(xié)議的配置區(qū)別并不是大，只不過這里的 agent 是隱式存在的，與主服務(wù)共生。明顯的區(qū)別在于 agent 方案中異構(gòu)語言并不直接交互。
dubbo協(xié)議的跨語言支持
dubbo 協(xié)議設(shè)計(jì)之初只考慮到了常規(guī)的 rpc 調(diào)用場景，它并不是為跨語言而設(shè)計(jì)，但跨語言支持從來不是只有支持、不支持兩種選擇，而是要按難易程度來劃分。是的，dubbo 協(xié)議的跨語言調(diào)用可能并不好做，但并非無法實(shí)現(xiàn)。千米網(wǎng)便實(shí)現(xiàn)了這一點(diǎn)，nodejs 構(gòu)建的前端業(yè)務(wù)是異構(gòu)語言的主戰(zhàn)場，最終實(shí)現(xiàn)了 dubbo2.js，打通了 nodejs 和原生 dubbo 協(xié)議。作為本文第二部分的核心內(nèi)容，重點(diǎn)介紹下我們使用 dubbo2.js 干了什么事。
Dubbo協(xié)議報(bào)文格式
???dubbo協(xié)議
dubbo協(xié)議
dubbo協(xié)議報(bào)文消息頭詳解：
magic：類似java字節(jié)碼文件里的魔數(shù)，用來判斷是不是 dubbo 協(xié)議的數(shù)據(jù)包。魔數(shù)是常量 0xdabb
flag：標(biāo)志位, 一共8個(gè)地址位。低四位用來表示消息體數(shù)據(jù)用的序列化工具的類型（默認(rèn) hessian），高四位中，第一位為 1 表示是 request 請求，第二位為 1 表示雙向傳輸（即有返回 response），第三位為 1 表示是心跳 ping 事件。
status：狀態(tài)位, 設(shè)置請求響應(yīng)狀態(tài)，dubbo 定義了一些響應(yīng)的類型。具體類型見com.alibaba.dubbo.remoting.exchange.Response
invoke id：消息 id, long 類型。每一個(gè)請求的唯一識別 id（由于采用異步通訊的方式，用來把請求 request 和返回的 response 對應(yīng)上）
body length：消息體 body 長度, int 類型，即記錄 Body Content 有多少個(gè)字節(jié)
body content：請求參數(shù)，響應(yīng)參數(shù)的抽象序列化之后存儲于此。
協(xié)議報(bào)文最終都會變成字節(jié)，使用 tcp 傳輸，任何語言只要支持網(wǎng)絡(luò)模塊，有類似 Socket 之類的封裝，那么通信就不成問題。那，跨語言難在哪兒？以其他語言調(diào)用 java 來說，主要有兩個(gè)難點(diǎn)：
ps：dubbo 協(xié)議通訊demo（ ）
重慶分公司
重慶分公司
