基于Spring的RPC通訊模型.

一、概念和原理

? ? RPC(remote procedure call),遠程過程調用,是客戶端應用和服務端之間的會話。在客戶端,它所需要的一些功能并不在該應用的實現范圍之內,所以應用要向提供這些功能的其他系統尋求幫助。而遠程應用通過遠程服務暴露這些功能。RPC 是同步操作,會阻塞調用代碼的執行,直到被調用的過程執行完畢。

? ??Spring支持多種不同的RPC模型,包括RMI、Caucho的Hessian和Burlap以及Spring自帶的HTTP invoker:

? ? 客戶端:

? ? 在所有的模型中,服務都是作為 Spring 所管理的 bean 配置到我們的應用中。這是通過一個代理工廠 bean 實現的,這個bean能夠把遠程服務像本地對象一樣裝配到其他bean的屬性中。

? ? 客戶端向代理發起調用,就像代理提供了這些服務一樣。代理代表客戶端和遠程服務進行通信,由它負責處理連接的細節并向遠程服務發起調用。

? ? 服務端:

Spring 使用遠程導出器(remote exporter)將bean方法發布為遠程服務。

回到頂部

二、RMI

? ? RMI 最初在JDK 1.1被引入到Java平臺中,它為Java開發者提供了一種強大的方法來實現Java程序間的交互。

? ? Spring 提供了簡單的方式來發布RMI服務,在服務端,RmiServiceExporter 可以把任何 Spring 管理的bean發布為RMI服務 ,如圖所示,RmiServiceExporter 把bean包裝在一個適配器類中,然后適配器類被綁定到RMI注冊表中,并且代理到服務類的請求。?

/**

? ? ?* 服務端:

? ? ?* <p>

? ? ?* 1、默認情況下,RmiServiceExporter 會嘗試綁定到本地機器1099端口上的RMI注冊表。

? ? ?* 2、如果在這個端口沒有發現RMI注冊表,RmiServiceExporter 將會啟動一個注冊表。

? ? ?* 3、可重寫注冊表的路徑和端口,這個是個大坑,當你設置了registryHost屬性的時候,源碼中就不創建Registry,而是直接去獲取,可是我們自己也沒有創建,所以就會報連接不上。

? ? ?*

? ? ?* @param userService

? ? ?* @return

? ? ?*/

? ? @Bean(name = "rmiServiceExporter")

? ? public RmiExporter rmiServiceExporter(UserService userService, Environment environment) {

? ? ? ? String registryHost = environment.getProperty("registryHost");

? ? ? ? int registryPort = environment.getProperty("registryPort", Integer.class);

? ? ? ? RmiExporter rmiExporter = new RmiExporter();

? ? ? ? rmiExporter.setService(userService); //要把該bean(即rmiServiceImpl)發布為一個RMI服務

? ? ? ? rmiExporter.setServiceName("RmiService"); //命名RMI 服務

? ? ? ? rmiExporter.setServiceInterface(UserService.class); //指定服務所實現的接口

? ? ? ? rmiExporter.setRegistryHost(registryHost);

? ? ? ? rmiExporter.setRegistryPort(registryPort);

? ? ? ? return rmiExporter;

? ? }

/**

?* Created by XiuYin.Cui on 2018/5/14.

?*?

?* 解決設置 registryHost 后,報連接拒絕的問題。

?*/

public class RmiExporter extends RmiServiceExporter {


? ? @Override

? ? protected Registry getRegistry(String registryHost, int registryPort, RMIClientSocketFactory clientSocketFactory,

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?RMIServerSocketFactory serverSocketFactory) throws RemoteException {



? ? ? ? if (registryHost != null) {

? ? ? ? ? ? try {

? ? ? ? ? ? ? ? if (logger.isInfoEnabled()) {

? ? ? ? ? ? ? ? ? ? logger.info("Looking for RMI registry at port '" + registryPort + "' of host [" + registryHost + "]");

? ? ? ? ? ? ? ? }

? ? ? ? ? ? ? ? //把spring源代碼中這里try起來,報異常就創建一個

? ? ? ? ? ? ? ? Registry reg = LocateRegistry.getRegistry(registryHost, registryPort, clientSocketFactory);

? ? ? ? ? ? ? ? testRegistry(reg);

? ? ? ? ? ? ? ? return reg;

? ? ? ? ? ? } catch (RemoteException ex) {

? ? ? ? ? ? ? ? LocateRegistry.createRegistry(registryPort);

? ? ? ? ? ? ? ? Registry reg = LocateRegistry.getRegistry(registryHost, registryPort, clientSocketFactory);

? ? ? ? ? ? ? ? testRegistry(reg);

? ? ? ? ? ? ? ? return reg;

? ? ? ? ? ? }

? ? ? ? } else {

? ? ? ? ? ? return getRegistry(registryPort, clientSocketFactory, serverSocketFactory);

? ? ? ? }

? ? }

}

接下來,來看看客戶端是怎么使用這些遠程服務的吧!Spring的RmiProxyFactoryBean是一個工廠bean,該bean可以為RMI服務創建代理。該代理代表客戶端來負責與遠程的RMI服務進行通信。客戶端通過服務的接口與代理進行交互,就如同遠程服務就是一個本地的POJO。

@Resource(name="rmiUserServiceClient") ? ?private UserService userService;

RMI 的缺陷:

1、RMI很難穿越防火墻,這是因為RMI使用任意端口來交互——這是防火墻通常所不允許的。
2、RMI是基于Java的。這意味著客戶端和服務端必須都是用java開發。因為RMI使用了Java的序列化機制,所以通過網絡傳輸的對象類型必須要保證在調用兩端的Java運行時中是完全相同的版本。

? ??tips:最近發現?Dubbo 底層也是用 RMI 實現的,它把 zookeeper 當作注冊表。

回到頂部

三、Hessian 和 Burlap

? ??Hession 和 Burlap 是 Caucho Technology 的兩種基于HTTP的輕量級遠程服務解決方案。借助于盡可能簡單的API和通信協議,它們都致力于簡化Web服務。

? ??Hession,像RMI一樣,使用二進制消息進行客戶端和服務端的交互。但是它與RMI不同的是,它的二進制消息可以移植到其他非Java的語言中。由于它是基于二進制的,所以它在帶寬上更具優勢。

? ??Burlap 是一種基于XML的遠程調用技術,這使得它可以自然而然的移植到任何能夠解析XML的語言上。正因為它基于XML,所以相比起Hessian的二進制格式而言,Burlap可讀性更強。但是和其他基于XML的遠程技術(例如SOAP或XML-RPC)不同,Burlap的消息結構盡可能的簡單。

? ? 下面我們會介紹 Hession 的使用。Spring 不推薦使用?Burlap,BurlapServiceExporter 在4.0后被廢棄,不再提供支持。5.0 后直接從開發包丟棄了。

? ? 服務端,類似于 RmiServiceExporter ,Hession 也有一個?HessianServiceExporter 將 Spring 管理的 bean 發布為 Hessian 服務,不同于RMI的是,HessianServiceExporter是一個Spring MVC控制器,它接收Hessian請求(HTTP協議的請求),并將這些請求轉換成對被導出POJO的方法調用。既然是HTTP請求,那我們就必須配置Spring 的?DispatcherServlet ,并配置?HandlerMapping,將相應的URL映射給?HessianServiceExporter。

?

/**

? ? ?* Hession沒有注冊表,不需要設置 serviceName

? ? ?*/

? ? @Bean(name = "hessianServiceExporter")

? ? public HessianServiceExporter hessianServiceExporter(UserService userService) {

? ? ? ? HessianServiceExporter hessianServiceExporter = new HessianServiceExporter();

? ? ? ? hessianServiceExporter.setService(userService);

? ? ? ? hessianServiceExporter.setServiceInterface(UserService.class);

? ? ? ? return hessianServiceExporter;

? ? }

? ? /**

? ? ?* 需要配置一個URL映射來確保DispatcherServlet把請求轉給HessianServiceExporter

? ? ?*/

? ? @Bean(name = "handlerMapping")

? ? public HandlerMapping handlerMapping() {

? ? ? ? SimpleUrlHandlerMapping handlerMapping = new SimpleUrlHandlerMapping();

? ? ? ? Properties mappings = new Properties();

? ? ? ? mappings.setProperty("/user.service", "hessianServiceExporter");

? ? ? ? handlerMapping.setMappings(mappings);

? ? ? ? return handlerMapping;

? ? }

客戶端,類似于?RmiProxyFactoryBean ,Hessian 也有一個代理工廠Bean——HessianProxyFactoryBean,來創建代理與遠程服務進行通信:


esource(name="hessianUserServiceClient") ? ?private UserService userService;?

Hessian 的缺陷:

? ??Hession 和 Burlap 都是基于HTTP的,它們都解決了RMI所頭疼的防火墻滲透問題。但是當傳遞過來的RPC消息中包含序列化對象時,RMI就完勝 Hessian 和 Burlap 了。因為 Hessian 和 Burlap 都采用了私有的序列化機制,而RMI使用的是Java本身的序列化機制。

回到頂部

四、HttpInvoker

? ? RMI 和 Hessian 各有自己的缺陷,一方面,RMI使用Java標準的對象序列化機制,但是很難穿透防火墻。另一方面,Hessian和Burlap能很好地穿透防火墻,但是使用私有的對象序列化機制。就這樣,Spring的HTTP invoker應運而生了。HTTP invoker是一個新的遠程調用模型,作為Spring框架的一部分,能夠執行基于HTTP的遠程調用,并使用Java的序列化機制。

? ? HttpInvoker 的使用和 Hessian 很類似,HttpInvokerServiceExporter 也是一個Spring MVC 控制器,也是通過?DispatcherServlet 將請求分發給它...

客戶端,像 RmiProxyFactoryBean 和 HessianProxyFactoryBean 一樣,HttpInvoker 也提供了一個代理工廠Bean——HttpInvokerProxyFactoryBean,用于創建HttpInvoker代理來與遠程服務通信:

@Resource(name="httpInvokerUserServiceClient") ? ?private UserService userService;


?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容