微服务架构之RPC-client序列化细节

第一章聊了【“为什么要进行服务化，服务化究竟解决什么问题”】

第二章聊了【“微服务的服务粒度选型”】

上一篇聊了【“为什么说要搞定微服务架构，先搞定RPC框架？”】

通过上篇文章的介绍，知道了要实施微服务，首先要搞定RPC框架，RPC框架的职责要向【调用方】和【服务提供方】屏蔽各种复杂性：

（1）让调用方感觉就像调用本地函数一样

（2）让服务提供方感觉就像实现一个本地函数一样来实现服务

整个RPC框架又分为client部分与server部分：

RPC-client的部分流程如上图，要进行序列化反序列化（上图中的1、4），要进行发送字节流与接收字节流（上图中的2、3）。

通过上一篇文章的用户调研：

78%读者 -> 继续聊RPC框架技术细节

14%读者 -> 聊微服务其他实践

7%读者 -> 不聊微服务了，聊最终一致性

那么按照多数读者的意见，今天深入聊RPC的技术细节，本文先讨论RPC-client部分的【序列化反序列化】实施细节（笔者不是这方面的专家，有不对之处，欢迎大家指正，任何具有建设性意见的留言，将在下一章share给更多的小伙伴）。

 

一、为什么要进行序列化

工程师通常使用“对象”来进行数据的操纵：

class User{

         std::Stringuser_name;

         uint64_tuser_id;

         uint32_tuser_age;

};

 

User u = new User(“s