协议（Protocol）是个很广的概念，RPC 被称为远程过程调用协议，HTTP 和 TCP 也是大家熟悉的协议，也有人经常拿 RPC 和 RESTFUL 做对比，后者也可以被理解为一种协议… 我个人偏向于把“协议”理解为不同厂家不同用户之间的“约定”，而在 RPC 中，协议的含义也有多层。

Protocol 在 RPC 中的层次关系

翻看 dubbo 和 motan 两个国内知名度数一数二的 RPC 框架（或者叫服务治理框架可能更合适）的文档，他们都有专门的一章介绍自身对多种协议的支持。RPC 框架是一个分层结构，从我的这个《深入理解 RPC》系列就可以看出，是按照分层来介绍 RPC 的原理的，前面已经介绍过了传输层，序列化层，动态代理层，他们各自负责 RPC 调用生命周期中的一环，而协议层则是凌驾于它们所有层之上的一层。简单描述下各个层之间的关系：

protocol 层主要用于配置 refer（发现服务） 和 exporter（暴露服务） 的实现方式，transport 层定义了传输的方式，codec 层诠释了具体传输过程中报文解析的方式，serialize 层负责将对象转换成字节，以用于传输，proxy 层负责将这些细节屏蔽。

它们的包含关系如下：protocol > transport > codec > serialize

motan 的 Protocol 接口可以佐证这一点：

1
2
3
4
5

public interface Protocol {
    <T> Exporter<T> export(Provider<T> provider, URL url);
    <T> Referer<T> refer(Class<T> clz, URL url, URL serviceUrl);
    void destroy();
}

我们都知道 RPC 框架支持多种协议，由于协议处于框架层次的较高位置，任何一种协议的替换，都可能会导致服务发现和服务注册的方式，传输的方式，以及序列化的方式，而不同的协议也给不同的业务场景带来了更多的选择，下面就来看看一些常用协议。

这周六参加了一个美团点评的技术沙龙，其中一位老师在介绍他们自研的 RPC 框架时提到一点：RPC 请求分为 sync，future，callback，oneway，并且需要遵循一个原则：能够异步的地方就不要使用同步。正好最近在优化一个业务场景：在一次页面展示中，需要调用 5 个 RPC 接口，导致页面响应很慢。正好启发了我。

为什么慢？

大多数开源的 RPC 框架实现远程调用的方式都是同步的，假设 [接口 1，…，接口 5] 的每一次调用耗时为 200ms （其中接口 2 依赖接口 1，接口 5 依赖接口 3，接口 4），那么总耗时为 1s，这整个是一个串行的过程。

多线程加速

RPC 被称为“远程过程调用”，表明了一个方法调用会跨越网络，跨越进程，所以传输层是不可或缺的。一说到网络传输，一堆名词就蹦了出来：TCP、UDP、HTTP，同步 or 异步，阻塞 or 非阻塞，长连接 or 短连接…

本文介绍两种传输层的实现：使用 Socket 和使用 Netty。前者实现的是阻塞式的通信，是一个较为简单的传输层实现方式，借此可以了解传输层的工作原理及工作内容；后者是非阻塞式的，在一般的 RPC 场景下，性能会表现的很好，所以被很多开源 RPC 框架作为传输层的实现方式。

RpcRequest 和 RpcResponse

传输层传输的主要对象其实就是这两个类，它们封装了请求 id，方法名，方法参数，返回值，异常等 RPC 调用中需要的一系列信息。

1
2
3
4
5
6
7
8
9
10

public class RpcRequest implements Serializable {
    private String interfaceName;
    private String methodName;
    private String parametersDesc;
    private Object[] arguments;
    private Map<String, String> attachments;
    private int retries = 0;
    private long requestId;
    private byte rpcProtocolVersion;
}

提到 JAVA 中的动态代理，大多数人都不会对 JDK 动态代理感到陌生，Proxy，InvocationHandler 等类都是 J2SE 中的基础概念。动态代理发生在服务调用方 / 客户端，RPC 框架需要解决的一个问题是：像调用本地接口一样调用远程的接口。于是如何组装数据报文，经过网络传输发送至服务提供方，屏蔽远程接口调用的细节，便是动态代理需要做的工作了。RPC 框架中的代理层往往是单独的一层，以方便替换代理方式（如 motan 代理层位于 com.weibo.api.motan.proxy ，dubbo 代理层位于 com.alibaba.dubbo.common.bytecode ）。

实现动态代理的方案有下列几种：

• jdk 动态代理
• cglib 动态代理
• javassist 动态代理
• ASM 字节码
• javassist 字节码

上一篇 《深入理解 RPC 之序列化篇 –Kryo》, 介绍了序列化的基础概念，并且详细介绍了 Kryo 的一系列特性，在这一篇中，简略的介绍其他常用的序列化器，并对它们进行一些比较。序列化篇仅仅由 Kryo 篇和总结篇构成可能有点突兀，等待后续有时间会补充详细的探讨。

定义抽象接口

1
2
3
4
5
6

public interface Serialization {

   byte[] serialize(Object obj) throws IOException;

   <T> T deserialize(byte[] bytes, Class<T> clz) throws IOException;
}

RPC 框架中的序列化实现自然是种类多样，但它们必须遵循统一的规范，于是我们使用 Serialization 作为序列化的统一接口，无论何种方案都需要实现该接口。

一年前，笔者刚刚接触 RPC 框架，从单体式应用向分布式应用的变革无疑是让人兴奋的，同时也对 RPC 背后到底做了哪些工作产生了兴趣，但其底层的设计对新手而言并不是很友好，其涉及的一些常用技术点都有一定的门槛。如传输层常常使用的 netty，之前完全没听过，想要学习它，需要掌握前置知识点 nio；协议层，包括了很多自定义的协议，而每个 RPC 框架的实现都有差异；代理层的动态代理技术，如 jdk 动态代理，虽然实战经验不多，但至少还算会用，而 cglib 则又有一个盲区；序列化层倒还算是众多层次中相对简单的一环，但 RPC 为了追求可扩展性，性能等诸多因素，通常会支持多种序列化方式以供使用者插拔使用，一些常用的序列化方案 hessian，kryo，Protobuf 又得熟知…

这个系列打算就 RPC 框架涉及到的一些知识点进行探讨，本篇先从序列化层的一种选择 –kryo 开始进行介绍。

序列化概述

大白话介绍下 RPC 中序列化的概念，可以简单理解为对象 –> 字节的过程，同理，反序列化则是相反的过程。为什么需要序列化？因为网络传输只认字节。所以互信的过程依赖于序列化。有人会问，FastJson 转换成字符串算不算序列化？对象持久化到数据库算不算序列化？没必要较真，广义上理解即可。

JDK 序列化

时下很多企业应用更新换代到分布式，一篇文章了解什么是 RPC。
原作者梁飞，在此记录下他非常简洁的 rpc 实现思路。