这一系列的小文章要暂时告一段落了,这一篇会挖很多坑,留着以后慢慢填。
(前面的两篇请直接拉到最后的传送门。)
到目前为止也没有贴代码,主要是因为单纯用最简单的实现,网上随便一搜一大吧。我也只是在 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呢?
感觉坑已经多到可以出个年度连载了,那么就留待以后 一个个,慢慢填 。
(技术上我是个慢性子,虽然可能几个月后再来写一篇,但是,每个坑我一定会填上!)