【rpc专栏】深入理解rpc之序列化篇kryo.docxVIP

RPC 专栏】深入理解 RPC 之序列化篇 Kryo 年前，笔者刚刚接触 RPC 框架，从单体式应用向分 布式应用的变革无疑是让人兴奋的，同时也对 RPC 背后到 底做了哪些工作产生了兴趣，但其底层的设计对新手而言并 不是很友好，其涉及的一些常用技术点都有一定的门槛。如 传输层常常使用的 netty ，之前完全没听过， 想要学习它， 需 要掌握前置知识点nio ;协议层，包括了很多自定义的协议， 而每个 RPC 框架的实现都有差异； 代理层的动态代理技术， 如 jdk 动态代理，虽然实战经验不多，但至少还算会用，而 cglib 则又有一个盲区； 序列化层倒还算是众多层次中相对简 单的一环，但 RPC 为了追求可扩展性，性能等诸多因素， 通常会支持多种序列化方式以供使用者插拔使用，一些常用 的序列化方案 hessian ，kryo ，Protobuf 又得熟知 ... 这个系列 打算就 RPC 框架涉及到的一些知识点进行探讨，本篇先从 序列化层的一种选择 --kryo 开始进行介绍。序列化概述大白 话介绍下 RPC 中序列化的概念，可以简单理解为对象 --gt; 字节的过程，同理，反序列化则是相反的过程。为什么需要 序列化？因为网络传输只认字节。所以互信的过程依赖于序 列化。 有人会问， FastJson 转换成字符串算不算序列化？对 象持久化到数据库算不算序列化？没必要较真，广义上理解 即可。 JDK 序列化可能你没用过 kryo ，没用过 hessian ，但你一定用过 jdk 序列化。我最早接触 jdk 序列化，是在大 的 JAVA 大作业中，《 XX 管理系统》需要把对象保存到文件 中（那时还没学数据库） ，jdk 原生支持的序列化方式用起来 也很方便。 class Student implements Serializable{private String name; } class Serializable{ Main{ public static void main(String[] args) throws Exception{// create a Student Exception{ // create a Student Student st = new Student(kirito);file// serialize the st to student.db new Student(kirito); file ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream(student.db)); oos.writeObject(st);oos.close();// oos.writeObject(st); oos.close(); // deserialize the object from student.db Student kirito =ObjectInputStream ois = Student kirito = FileInputStream(student.db)); (Student) ois.readObject();ois.close();// (Student) ois.readObject(); ois.close(); // assert assert kirito.equals(kirito.getName()); Student 实体类需要实现 Serializable 接口，以告知其可被序 列化。序列化协议的选择通常有下列一些常用的指标：通用 性。是否只能用于 java 间序列化 /反序列化，是否跨语言， 跨平台。性能。分为空间开销和时间开销。序列化后的数据 般用于存储或网络传输，其大小是很重要的一个参数；解 析的时间也影响了序列化协议的选择，如今的系统都在追求 input.close(); assert input.close(); assert 极致的性能。可扩展性。系统升级不可避免，某一实体的属 性变更，会不会导致反序列化异常，也应该纳入序列化协议 的考量范围。 易用性。 API 使用是否复杂， 会影响开发效率。 容易用的模型通常性能不好，性能好的模型通常用起来都比 较麻烦。显然， JDK 序列化属于前者。我们不过多介绍它， 直接引入今天的主角 kryo 作为它的替代品。 Kryo 入门引入 依赖com.esotericsoftwarekryo 依赖 com.esotericsoftware kryo 4.0.1由于其底层依赖于 ASM 技术，与 Spring 等框架可 能会发生 ASM 依赖的版本冲突（文档中表示这个冲突还挺 4.0.1 容易出现）所以提供了另外一个依赖以供解决此问题