手写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框架,我学会了什么?(二)

    原文作者:日更专用小马甲
    原文地址: https://www.jianshu.com/p/66e2ffa0573a
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞