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一较高下。因此，笔者仅对两者的同步方法调用的性能进行对比测试。

一、测试环境

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

  软件：JDK1.7、dubbo 2.6.1、mac-rpc 1.0.1

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

二、测试场景

  Dubbo可调参数众多，其调优过程本身就已非常复杂，费时费力。因此，本次测试将尽可能采用其默认参数。经过多轮测试，Dubbo在采用固定大小线程池时性能表现最佳，同时为了避免dubbo抛出线程池耗尽的异常，我们将服务方的线程池大小固定为600，在消费方使用300个线程并行发起调用。

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

  注：作为RPC框架，在方法调用时只传输小对象是可以的。但作为微服务框架，系统内服务的形式多种多样，如果限制所有服务都不能返回大对象，似乎有一些差强人意。在这一点上mac-rpc则更具优势。

三、测试要点

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

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

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

三、测试方法

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

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

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

四、测试结果

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

五、资源消耗

  资源上看，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 服务提供方资源消耗：

六、测试结论

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

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