?RPC框架泛化調(diào)用功能在網(wǎng)關、接口測試等場景下有著廣泛的需求，本文給各位讀者介紹一下主流的泛化調(diào)用實現(xiàn)方式及原理，比較各種實現(xiàn)方案的優(yōu)缺點，并分享泛化調(diào)用在轉(zhuǎn)轉(zhuǎn)的實踐。一方面有助于RPC框架使用方理解泛化調(diào)用，更好地使用泛化調(diào)用；另一方面對于有自研RPC框架需求的開發(fā)者在選擇泛化調(diào)用實現(xiàn)方案上有一定參考意義。

1、普通RPC調(diào)用

基于動態(tài)代理技術，RPC框架客戶端做到了調(diào)用RPC方法與調(diào)用本地方法相同的體驗。一般情況下服務端定義服務接口，并將接口打包到二方jar包發(fā)布。服務端在服務進程中實現(xiàn)該接口，而調(diào)用方在進程中根據(jù)該接口創(chuàng)建動態(tài)代理進行調(diào)用，與調(diào)用本地方法體驗一致。

例如有接口HelloService?，被打包在demo-service-interfaces.jar包中。

public interface HelloService {
    String hello(String name);
}

服務端依賴demo-service-interfaces.jar?，創(chuàng)建HelloServiceImpl實現(xiàn)該接口。

public class HelloServiceImpl implements HelloService {
    @Override
    public String hello(String name){
        return "hello, " + name;
    }
}

客戶端同樣依賴demo-service-interface.jar?，創(chuàng)建HelloService的代理類，以下為代碼示例，實際上創(chuàng)建代理類，發(fā)送接口、參數(shù)，接收返回結(jié)果等操作都是封裝在框架內(nèi)的。

HelloService helloService = (HelloService)Proxy.newProxyInstance(this.getClass().getClassLoader(), HelloService.class, (InvocationHandler) (proxy, method, args) -> {
    //都是封裝在框架內(nèi)的
    //獲取方法、參數(shù)類型
    String methodName = method.getName();
    Class<?>[] parameterTypes = method.getParameterTypes();
    //發(fā)送方法、參數(shù)類型和實參到服務端并返回結(jié)果
    return request(methodName, parameterTypes, args);
});
String result = helloService.hello("jack");
System.out.println(result);

2、網(wǎng)關、接口測試等場景下的需求

由上文可以看到普通的RPC調(diào)用需要將接口類（參數(shù)和返回值如果是POJO類型同樣需要一起打包）打到一個jar包中，被服務方和調(diào)用方共同依賴。這種方式在多大數(shù)業(yè)務場景中是適用的，且更加方便，因為所依賴的接口jar包是可枚舉的。

但是在一些特殊的場景下依賴接口jar包變得很不方便，比如網(wǎng)關、接口測試平臺等。例如使用http網(wǎng)關代理私有協(xié)議RPC請求，如果在網(wǎng)關中依賴接口jar包，那么在新增方法或者接口時網(wǎng)關需要重新編譯上線。而接口測試平臺需要對全公司所有的RPC接口進行測試，將全公司所有的接口jar包添加到測試平臺的依賴中顯然是不可行的。

在這些場景下就誕生了對泛化調(diào)用的需求。

3、泛化調(diào)用

泛化調(diào)用就是在不依賴服務方接口jar包的情況下進行調(diào)用，包括對調(diào)用方法的泛化、參數(shù)的泛化和返回值的泛化。

public interface GenericService {
    Object $genericInvoke(String methodName, String[] parameterTypes, Object[] args);
}

在沒有接口類依賴的情況下，parameterTypes?需要通過字符串指定，而args?和返回值如果是jdk?內(nèi)置類型的話與普通調(diào)用無異，而如果是POJO類型的話則需要尋找一種通用的表示方法。

下普通RPC調(diào)用的序列化與反序列化原理，如下圖所示，實際上序列化框架在將POJO?序列化成字節(jié)數(shù)組之前需要解析POJO的類結(jié)構(gòu)生成序列化中間體，當然序列化中間體并非一定能在序列化框架中找到對應的類，有時候這個中間體是虛擬的。

普通RPC調(diào)用序列化原理

3.1 基于Java Bean的泛化調(diào)用

基于Java Bean?的泛化調(diào)用是通過統(tǒng)一的Java Bean?描述符（JavaBeanDescriptor?）來描述POJO?對象，它工作在序列化層之上，例如dubbo?支持該種類型的泛化調(diào)用，在使用泛化調(diào)用時，直接傳遞JavaBeanDescriptor對象作為參數(shù)，基本原理如下圖所示。

Java Bean泛化調(diào)用

該泛化調(diào)用的實現(xiàn)通用性比較強，與底層序列化無關，但是復雜度較高，需要RPC框架處理POJO和JavaBeanDescriptor之間的轉(zhuǎn)換。

3.2 基于序列化中間體的泛化調(diào)用

支持基于序列化中間體的泛化調(diào)用的RPC框架典型的如sofa-rpc?，使用了sofa-hessian?序列化框架，sofa-hessian?是在hessian?序列化框架基礎上進行二次開發(fā)的，抽象出了序列化中間體，如GenericObject、GenericMap、GenericArray等。

轉(zhuǎn)轉(zhuǎn)RPC框架在支持泛化調(diào)用時也參考了sofa-hessian?的實現(xiàn)，對hessian序列化框架進行二次開發(fā)，并且有所改進。

基于序列化中間體的泛化調(diào)用

而json?序列化天然具備序列化中間體，即JsonObject?或者json String?，在使用json?序列化時調(diào)用方可以直接將Json Object?或者json String?作為參數(shù)代替POJO?進行調(diào)用。轉(zhuǎn)轉(zhuǎn)RPC框架也支持基于json序列化的泛化調(diào)用。

dubbo?除了支持基于Java Bean?的泛化調(diào)用，還支持json-protobuf?泛化調(diào)用，也就是說調(diào)用方可以使用json?描述protobuf?對象，在反序列化時可以將json?反序列為protobuf?對象再轉(zhuǎn)換成POJO，而這些功能本身是序列化框架所提供，不需要RPC框架做額外的開發(fā)支持。

基于序列化中間體的泛化調(diào)用與基于Java Bean的泛化調(diào)用相比，實現(xiàn)較為簡單，有些序列化框架本身原生就支持，或者對序列化框架做簡單的二次開發(fā)即可實現(xiàn)，缺點是與序列化框架耦合。

4、泛化調(diào)用在轉(zhuǎn)轉(zhuǎn)的實踐

目前泛化調(diào)用在轉(zhuǎn)轉(zhuǎn)公司應用最廣泛的領域就是接口測試，我們提供了統(tǒng)一的測試API平臺。通過該平臺可以使用http + json的方式實現(xiàn)對任意服務、任意節(jié)點、任意方法的調(diào)用，而測試API平臺不需要依賴任何服務的接口jar包。并且API平臺也沒有依賴RPC框架jar包，因為轉(zhuǎn)轉(zhuǎn)RPC框架實現(xiàn)了在同一個端口上同時兼容私有的二進制協(xié)議及公有的http協(xié)議，也就是說可以使用http請求來發(fā)起RPC調(diào)用。

泛化調(diào)用在轉(zhuǎn)轉(zhuǎn)的應用

同時還支持獲取任意服務、任意節(jié)點、任意方法參數(shù)及返回值的JsonSchema,如下代碼所示。

{
    "msg": "success",
    "data": {
        "schema": {
            "returnValue": {
                "type": "array",
                "items": {
                    "type": "object",
                    "id": "urn:jsonschema:com:bj58:zhuanzhuan:arch:user:atomic:entity:User",
                    "properties": {
                        "id": {
                            "type": "string"
                        },
                        "userName": {
                            "type": "string"
                        },
                        "userNamePinyin": {
                            "type": "string"
                        },
                        "mock": {
                            "type": "boolean"
                        }
                    }
                }
            },
            "parameters": {
                "pageNum": {
                    "type": "integer"
                },
                "pageSize": {
                    "type": "integer"
                }
            }
        }
    },
    "code": 0
}

未來轉(zhuǎn)轉(zhuǎn)的網(wǎng)關也將基于泛化調(diào)用進行開發(fā)。

5 總結(jié)

RPC框架的泛化調(diào)用在網(wǎng)關、測試平臺等領域應用廣泛，目前主流的泛化調(diào)用實現(xiàn)有基于Java Bean規(guī)范的泛化調(diào)用和基于序列化中間體的泛化調(diào)用，它們的優(yōu)缺點分別如下：

• 基于Java Bean?的泛化調(diào)用：優(yōu)點是與序列化無關；缺點是RPC框架需要實現(xiàn)JavaBeanDescriptor向POJO的轉(zhuǎn)換功能，較為復雜。
• 基于序列化中間體的泛化調(diào)用：優(yōu)點是RPC框架實現(xiàn)簡單，序列化框架原生支持或者僅需少量改造；缺點是與特定的序列化框架耦合。

在開發(fā)RPC框架時，具體選擇哪種泛化調(diào)用實現(xiàn)方式，還需要結(jié)合實際情況做出選擇。

關于作者

王建新，轉(zhuǎn)轉(zhuǎn)架構(gòu)部服務治理負責人，主要負責服務治理、RPC框架、分布式調(diào)用跟蹤、監(jiān)控系統(tǒng)等。愛技術、愛學習，歡迎聯(lián)系交流。