dubbo vs mac-rpc 性能评测之同步调用

  Dubbo 是阿里巴巴开源的一款Java高性能分布式微服务框架。它以远程方法调用功能为基础，将系统中的服务以远程方法调用（RPC）的形式暴露并管理，提供配套的面向服务（SOA）的治理手段，从而造成完整的分布式微服务框架体系。

  Dubbo项目大概始于2009年，但不知出于什么缘由，官方于2012年中止了维护。很有戏剧性的是，墙内开花墙外香，Dubbo受到国内不少第三方厂商的欢迎，并在其项目中普遍使用。所以，官方于2017年重启Dubbo项目的维护，目前最新版本是2.6.1。

  mac-rpc是一款新的基于Java AIO的开源RPC框架，小巧精悍。强大的异步能力是它最大的亮点。Dubbo在异步支持上比较弱，而mac-rpc天生就是异步的，使得mac-rpc在异步方法调用的性能方面颇具优点。（了解其实现原理请访问官方网站 www.boarsoft.com）。

  做为RPC框架，大多数的应用场景都是同步方法调用。而mac-rpc在同步方法调用方面的性能也很是不俗，能够与dubbo一较高下。所以，笔者仅对二者的同步方法调用的性能进行对比测试。

    异步调用的评测见：《dubbo vs mac-rpc 性能评测之异步调用》

1、测试环境

  硬件：笔记本电脑一台 CPU Intel i5－6300HQ @2.30GHz，8G内存

  软件：JDK1.七、dubbo 2.6.一、mac-rpc 1.0.1

  注：笔记本电脑在CPU温度太高时会自动降频，致使测试结果的波动。笔者不得不采用轮流执行，屡次测试取平均值的方式进行。所得数据可能并不很准确，但能从大致上看出二者的性能水平。

2、测试场景

  Dubbo可调参数众多，其调优过程自己就已很是复杂，费时费力。所以，本次测试将尽量采用其默认参数。通过多轮测试，Dubbo在采用固定大小线程池时性能表现最佳，同时为了不dubbo抛出线程池耗尽的异常，咱们将服务方的线程池大小固定为600，在消费方使用300个线程并行发起调用。

  另外，dubbo在传输大对象时表现不佳，过大的数据量将致使dubbo的性能严重降低。所以咱们只让测试程序拼装并返回10~1万个字符。由于实际应用过程当中，绝大多数RPC方法调用，一次调用经过网络往返的数据量大体都位于这个区间内。

  注：做为RPC框架，在方法调用时只传输小对象是能够的。但做为微服务框架，系统内服务的形式多种多样，若是限制全部服务都不能返回大对象，彷佛有一些差强人意。在这一点上mac-rpc则更具优点。

3、测试要点

  在生产实践中，咱们能够看到这样一种现象，单笔测试时，只须要几个毫秒，甚至零毫秒的服务，在压力测试或生产环境下，延迟到几10、数百毫秒，有的甚至数秒，直到超过规定的响应时长。致使这一现象的缘由有不少，包括：磁盘IO、网络IO、线程切换、锁等待、CPU负载太高，内存不足，频繁GC、第三方系统时延等等。常常会发现系统吞吐量低，响应缓慢时，各项物理资源消耗却不多。

  为了更真实的模拟生产的运行环境，咱们在方法中经过Thread.sleep来模拟以上各类缘由形成的时延。观察RPC方法调用在受这些因素影响下的实际性能表现。此外，在大压力的状况下，输入输出数据量的大小对性能也有显著影响，咱们还须要测试不一样数据量下的性能表现。

  还有一个重要一因素就是微服务的粒度，服务粒度越小，灵活度越高，但在系统中相互调用的开销就越大，管理起来也更加复杂。适当的粒度对提升系统的吞吐量很是重要。

3、测试方法

  服务消费者使用300线程并行的发起同步RPC方法调用，服务提供者采用固定600个线程的线程池。模拟在0ms、10ms、20ms、50ms、100ms时延下，数据量在十、1000、5000、10000个字符时的表现。

  同时为了不磁盘IO和网络IO对性能的影响，测试程序不打日志，不写磁盘。服务消费者和服务提供者都在同一台电脑上。

  注：因为长时延和大数据量时，测试耗时急剧增长，为了节省时间，随着时延加长、数据量的加大，每线程的调用次数相应的被减小到5000次或2000次。

4、测试结果

  注：每线程 = 每线程发起的调用次数

  

5、资源消耗

  资源上看，Dubbo的线程池使用SynchronousQueue队列，这意味着服务消费者经过300个线程发起调用时，服务提供者对应的也会调起300个线程来执行。而mac-rpc的线程池默认使用LinkedBlockingQueue,使得服务消费者的线程数对服务提供者无影响。同时，mac-rpc默认采用CallerRunsPolicy做为线程不足的处理策略，而dubbo则采用AbortPolicy，除非采用cached线程池，不然当线程不足时，dubbo将抛出RejectedExecutionException。不管从配置方便程度，仍是灵活度，mac-rpc都更优。

  在使用固定600个线程的线程池的状况下，mac-rpc在CPU使用（25%）上略高于dubbo（20%），在内存使用上则显著优于dubbo（50~200M），稳定在50M左右。

dubbo 服务提供方资源消耗：

mac-rpc 服务提供方资源消耗：

6、测试结论

  当时RPC方法的时延较小，且数据量也较小，在此例中约为小于15ms，字节数小于大约2000~3000个时，Dubbo较mac-rpc有明显优点。以后随着时延和数据量的增长，mac-rpc的优点逐渐显现，响应时间和TPS都相对平稳，而dubbo的性能则显著降低，差距较大。继续增大压力，dubbo的表现会更糟糕，mac-rpc则相对更好一些。

  综合来看，mac-rpc在同步方法调用方面，相较dubbo，有着更优秀的性能表现，稳定性也更好，可以更好的承受压力。目前mac-rpc已具有了简单的微服务治理能力，但因为做者精力有限，发展时间较短，在功能性和治理手段方面还有待完善和增强。