实现一个RPC框架，过程中我的思路与收获

oneRPC

想通过写一个RPC框架，来锻炼自己的网络编程和工程设计能力，同时这个project也作为自己本学期学校的课题设计。代码放到了 GitHub 上了，自己想着写点东西，记录下实现过程中自己得到的收获，同样也很喜欢能与别人分享下自己的见解。（本人java语言）

GitHub: https://github.com/onemsg/oneRPC

博客今天先定个开头，今后有时间详细地更新

思路

1. 自己的项目/实习经历并不丰富，并没实际地使用过任何rpc框架，只是看过不好介绍rpc的文章，看过 dubbo 的入门案例。所以，刚开始觉得要写的时候，我去搜索了很多rpc的介绍（infoQ、知乎、博客、gRPC官网），看了这些资料后，头脑里就有个大概设计方向了：我要选择什么传输协议，TCP还是HTTP？我要选择什么序列化协议？搜了很多Java相关的协议，去一一了解并比较了下。

2. 开始选了tcp和kryo，tcp服务器/客户端用的 vertx，写的时候发现遇到了困难，tcp需要自己定义应用层协议，并拆包什么的，很麻烦；kryo呢，用起来也不够方便。

3. 本着“最小化可行产品”原则，我放弃了原先的tcp+kryo方案，选择了http+msgpack，http服务端用的还是vertx，客户端用的jdk11 HttpClient，msgpack 用的是和 -jakson。这次实现起来顺畅多了，自己还第一次用了 maven 的多模块开发，分为 client、core、server、registry、example，模块解耦。

4. client 调用 server 实现后，想着所有 rpc 框架都有服务发现功能，就又用 etcd 做了服务发现。好吧，etcd 比 zk 确实好用，但是尴尬的是，我实现了一个 rpc 却用到了另一个 rpc （etcd 的 java client 用 gRPC 和服务器通信）。

收获

• 最小可行话产品 思想很有用，它鼓励你快速搭建一个可用的产品，之后再进行优化、迭代，对于从0开始完成一个项目来说很有用。

• jackson 的 ObjectMapper，在把如 "[1,2,3,4]" json字符串序列化为 java 对象时，如果没有显式指定，那么会被默认序列化为 List 对象。（这种情况发生在这时候，一个 pojo 的某个属性 value 是 Object 类型，你传给它的值是 new int[]{1,2,3,4},objectMapper 把 pojo 序列化为 json 字符串后，再反序列化为 java 对象，这时候这个 pojo 的 value 类型为 List）

• 学习并多写点 unit testing，能又快又能复用的测试自己的代码改动。

todo …