gRPC是谷歌最新发布的开源软件，基于最新的HTTP2.0协议，支持多种常见的编程语言。 我们知道HTTP2.0是基于二进制的HTTP协议的升级版本，目前各大浏览器都在快速支持。 想象一下，将来浏览器将支持HTTP2.0，并且可以通过现有的开源序列化库(例如protobuf )直接高效地与各种语言的服务进行交互。 这是多么“精彩”的场面啊。
作为gPRC的Java实现基础的网络库是Netty，是最新的netty5.0.0. alpha 3的开发版本。 因为最新版本针对HTTP/2进行了很多改良。 为了语言间，gPRC也和其他方案一样，采用旧的IDL这样的接口记述语言，利用自己的Protobuf项目所具有的protoc编译器生成框架代码。 这是目前最受欢迎的Facebook开源，与目前Apache顶级项目Thrift的原理一致。
我很好奇这个新诞生的框架的性能如何，与现有的RPC开源方案相比如何。 简单的比较花了时间。 我选择了五种开源项目进行测试： gRPC、Thrift、Wildfly、Dubbo和JBoss EAP。 为了简化，测试用例可以使用项目附带的demo或sample等简单地进行修改，使进程间网络调用次数一致。
从Github master主干网获得最新版本，并按照手册进行编译。 如上所述，网络框架是Netty5，基于最新的HTTP/2。
其中，选择getFeature方法，删除不使用的句子和画面输出，进行10，000次同时调用。
testclientsyncclient=newtestclientsync (' localhost '，8980 )； try{
finallongstarttime=system.nano time (；
for(inti=0； I
client.getfeature(409146138，-746188906；
finallongendtime=system.nano time (；
信息(method 1: ) (结束时间-开始时间)； }
publicvoidgetfeature(intlat，intlon ) {
try{
point request=point.new builder (.set latitude ) (lat ).set longitude (lon ).build )；
eature feature=blocking stub.get feature (request )；
}catch(runtimeexceptione ) {
logger.log(level.warning，' RPCfailed '，e )；
throwe
}
多次运行，记录所需时间。
gRPC还提供了无阻塞的调用方法，但由于时间有限，为了简化测试，我们采用了只通过标准服务器启动的方式。 由于asyncStub在大规模并发访问时会出现错误，而且使用时间也很长，因此此次测试没有该方法的结果数据。
从Apache站点获取最新的0.9.2版，而本机编译器获取C的编译器和Java运行时环境。
intdiff； finallongstarttime=system.nano time (； try{
for(inti=0； I
DIFF=client.calculate(1，work )； }catch(invalidoperationio ) {
system.out.println (invalid operation : ) io.why )； } finallongendtime=system.nano time (； system.out.println (method 1: ) (endtime-starttime )；
Thrift采用经典的基于网络端口的RPC，效率最高，可以在最后的总结数据中看到。
Wildfly是JBossAS改名后的JBossAS服务器，实现了完整的JavaEE规范。 我知道JavaEE上的远程RPC调用是在EJB规范中定义的。 这里测试Wildlfy的远程EJB调用功能。
选择的Wildfly8.2是当前发布的最新稳定版本。 此版本还支持端口复用服用。 这意味着EJB远程调用在HTTP端口复用中进行，并利用HTTP的Upgrade机制在二进制运行时协商和升级。 虽然不是纯粹的HTTP/2，但工作机制也相差无几。
测试示例选择jboss-eap-quickstarts项目的远程ejb调用示例RemoteEJBClient.java
纯Java RPC方案的优点在于，它不需要IDL文件定义和编译代码生成过程。 协商一下接口就行了
publicinterfaceremotecalculator
intadd(inta，intb )； }
intsum=0； finallo
ng startTime = System.nanoTime();for (int i = 0; isum = statelessRemoteCalculator.add(a, b);}final long endTime = System.nanoTime();System.out.println("method 1 : " + (endTime - startTime));
调用无状态的SessionBean方法10,000次,对应的远程EJB服务是部署在Wildfly应用服务器中的EJB。
Dubbo是阿里集团开源的一个极为成员的RPC框架，在很多互联网公司和企业应用中广泛使用。协议和序列化框架都可以插拔是及其鲜明的特色。同样的远程接口是基于Java Interface，并且依托于spring框架方便开发。可以方便的打包成单一文件，独立进程运行，和现在的微服务概念一致。
采用github中master主干，目前版本是 2.5.4-SNAPSHOT
测试例子选用其中的demo进行修改 DemoAction.java
public interface DemoService {
String sayHello(String name);}
final long startTime = System.nanoTime();for (int i = 0; i
try {
String hello = demoService.sayHello("world" + i);
} catch (Exception e) {
e.printStackTrace();
}}final long endTime = System.nanoTime();System.out.println("method 1 : " + (endTime - startTime));
调用完毕后查看输入log文件获得运行时间。
Redhat JBoss EAP 6.3.2 Link
EAP是JBossAS的商业版本，实现了完整的JavaEE规范。
EAP6基于AS7.2以后的版本构建，红帽提供商业支持。
AS7在7.2以后，社区版没有再发布，具备能力的企业可以从源码进行编译使用，EAP6.3基于AS7.4分支构建，很快发布的EAP6.4基于AS7.5分支构建，不出意外这个会是最后一个EAP6的minor版本。
AS7还没有像Wildfly完全采用端口复用的方式，短程EJB调用通过独立端口完成，基于JBossRemoting3的网络连接管理能力。
测试例子依然选用jboss-eap-quickstarts项目中的远程ejb调用例子
public interface RemoteCalculator {
int add(int a, int b);}
记录一万次调用后的时长。
数据结果。
最终经过4轮测试，不间断运行10,000次远程RPC调用后的结果如下：
我们可以看到Thrift的效率最高，大概领先一个数量级。而其他三个项目的性能数据在同数量级中，由高到低分别为JBossEAP, dubbo, wildfly和gRPC。
需要说明的有以下几点：
为了简化测试，我并没有选择同样的调用接口，而是顺手用了项目自带的，方便修改的示例程序。其中gRPC和Thrift的接口有对象传递，稍微复杂一些。
不是严格的性能测试流程，比如没有做预热过程，以及测试都运行在我的桌面用机上，没有完全恢复成“干净”的状态。
都是简单的服务器单一进程实例，标准示范例子，没有做特别优化和设置多个线程池之类的。而客户端调用也是最简单的阻塞式多次调用压力测试。应该是用多个机器多连接，多个线程，以及异步非阻塞的调用多种环境进行测试更为客观，有机会再继续完善。
之前没有看到过基于HTTP/2的RPC调用性能比较，理论上是应该低于经典的基于端口的RPC方案的。这个测试结果可以简单印证这个猜想。Thrift的数据遥遥领先.gRPC还在开发之中，基于的Netty还是alpha版本，而且非阻塞的方式还没有最后的数据。我想耐心一些，给gRPC一些时间，它会让我们惊艳的。
Wildfly表现良好，要知道它的服务端可是完整的JavaEE服务器啊。不过有时间的化，我试试看经典RMI连接的效率如何，要是能和thrift一个数量级就更好了。
dubbo性能也很出色，而且协议层可以更换的话，应该还能有更大提升。
我的测试在一台过时的笔记本上，受条件限制，没有先进的G级网络和多台服务器进行标准化性能测试。如果哪位在互联网或者企业工作的朋友有条件，也愿意充分完成这个测试，请和我联系，我会完整介绍我的测试搭建环境，共享代码，并帮助完成。我想那个结果会更有意义。