手写RPC框架，我学会了什么？（三）：埋坑

这一系列的小文章要暂时告一段落了，这一篇会挖很多坑，留着以后慢慢填。
（前面的两篇请直接拉到最后的传送门。）

到目前为止也没有贴代码，主要是因为单纯用最简单的实现，网上随便一搜一大吧。我也只是在 Java实现简单的RPC框架 的基础上做了一些小改进。

比如在博客中，每一次请求会生成一个新的接口实现类：

Object result = method.invoke(serviceClass.newInstance(), arguments);

我觉得完全可以把实现类缓存起来，减小内存的开销；再比如把服务提供方和消费方分开实现在两个不同的子工程，和诸如此类。

因此代码本身并不是重点，重点在于对原理的理解和概念的理解，当你真正理解概念之后，就不再会问出：

客户端register这边你能拿到HelloServiceImpl.class吗？应该不行吧？

这样的问题，因为 第一篇 已经说了，客户端拿到的只是一个动态代理生成的“傀儡”。也不再会问出：

我想知道，客户端是怎么有HelloService.class这个类的呢。
知道一个“HelloService”（字符串）就可以了吧？

这样的问题，因为 第二篇 也说过，服务接口需要以jar包的形式发布出去。
（画外音，这个问题本身很好，因为我自己的实现就是通过字符串的形式传递的，跟某框架更像一点）。

之前一直信奉的箴言 Talk is cheap, show me the code. 近些年来有些动摇，因为感觉talk跟code一样重要，有些概念不梳理清楚代码本身一定会很混乱。而梳理概念最简单的做法，就是不停的跟别人说，说，说。

当然，看别人的博客一万遍，也代替不了把这些概念自己实现出来，当然未必真的要从0开始，适当的站在别人打好的基础上先快速实现一个原型，再不停的迭代改进，也不失为一个好的原则。

既然说了是“原型”，就一定有很多可以值得大刀阔斧的砍掉重写的地方，比如：

• 采用基于Google protobuf的序列化机制，其实几年前就对它有所耳闻，也一直没有机会试一试。
• 采用Netty，这个也不多说了，一直没有用它开发过东西，说起来觉得挺丢人的。
• 引入独立的配置中心，现在的实现只是点对点的，要完成集群式的调用，还缺少服务发现这一环。
• 接上一条，负载均衡策略也不得不考虑，服务发布者怎么实现平滑重启。
• 目前的实现入侵性太重，更优雅的实现基于AOP通过类似：

@ServiceConsumer()

的方式一行搞定。那么是不是可以再实现一个boot-starter呢？

感觉坑已经多到可以出个年度连载了，那么就留待以后 一个个，慢慢填 。
（技术上我是个慢性子，虽然可能几个月后再来写一篇，但是，每个坑我一定会填上！）

传送门：
手写RPC框架，我学会了什么？（一）
手写RPC框架，我学会了什么？（二）