介绍

有心想把RPC开源给分享出去，虽然目前性能虽不如Dubbo，但它还有很大的空间可以去优化。

拷打

  • RPC框架的性能优化过程是比较枯燥和烦躁的，但我没有放弃，并最终天不负我，至少达到自己的一个小预期。
  • 刚1.0版本开始全副武装借用Jmeter来宣告胜利时，性能只有260左右。
  • 当时还没有应用超时重试、注册中心集群，性能就如此低，然后就扩展了这两块功能，性能直线下降，只剩下120左右。
  • 后面疯狂从服务器下手，使用主从Reactor多线程模型，业务处理也采用线程池，性能总算有了回升，到了150左右。
  • 但跟SpringCloud还有较大的差距，SpringCloud有300-400tps。
  • 服务端这里还有个一直待优化的地方，就是异步调用没能实现。
  • 接着想着是客户端的原因导致服务端大材小用了，客户端使用线程池，发现动态代理是线程安全的，必须串行执行，并发上无计可施。
  • 于是又从预加载上手，将注册中心的加载提前加载，并且整个各功能模块冗余加载，统一到配置类中共享，性能提升一点点。
  • 还是不满意，又从底层传输上入手，改变传输序列化协议，kryo是序列化字节数最少的序列化方式，改变hessian。发现新大陆，kryo虽然大，但在压测输出下，稳定性不如于hessian，性能没有提升反而原地踏步。
  • 接着再将16字节的自定义协议改成8字节，性能有所提升，但还只是个位数的回升。 于是想到之前加入超时重试性能下降范围这么大，于是又把重心放在它身上。
  • 发现用了第三方Redis依赖问题，导致Io延时高，而且我虽然用了异步更新操作，于是又转移注意力到包标志上，这样就无需从第三方缓存判断了，性能直接提升到250上了，还没到之前的270。
  • 又想着超时可以继续优化，由于超时直接调用，cpu一直占用，超时说明存在负载，应该不让它占用cpu，于是让超时线程睡眠1s以让出cpu，降低负载。接着又发现线程池还待优化，采用无核心线程的缓存型线程池，任务无长度，只能订阅通知来置取，减少内存损耗并增强了稳定性。
  • 吞吐量到了354左右。
  • 后面我将继续努力，超过400的SpringCloud，并以此为跳板，突破60%以上性能。

展望未来

  • 目前经过多轮功能测试和性能测试，在200并发线程模拟50ms任务的特定情况下。它的平均吞吐量能保持在354左右，最高事务处理数达到530tps。
  • 给出在理想状态下平均吞吐量最高的本地调用，平均达到900左右tps。
  • Dubbo目前的2.0版本平均吞吐量达到了望之却步的600tps以上。

知识传播

博主年度评选 一款分布式RPC框架的年度评选活动 希望能得到大家的支持和喜欢。 我会继续坚持创作和努力！