近期开始研究分布式架构，会涉及到一个最核心的组件：RPC（Remote Procedure Call Protocol）。这个东西的稳定性与性能，直接决定了分布式架构系统的好坏。RPC技术，我们的产品中其实早就已经应用。但是产品中经常出现访问失败等错误，在没有细致研究的情况下，大家怀疑是选用的RPC组件不稳定引起。今天也借这个机会给这个组件正名一下吧。

选型的思路很简单，先baidu找业界最有名的RPC框架，看各种牛人的的对比分析，然后到github上搜索排名和评价靠前的组件，确定一个选型的大致范围，然后进行一轮测试。当然，我们是有特性要求的：

1.最好支持TCP、HTTP两种通讯协议。即使不支持也可以扩展，或者集成两种RPC组件。

2.最好支持异步、同步两种调用方式。

3.性能要尽可能的好。

4.通讯层最好要有失败重试的机制或者类似的补偿机制。

5..net技术路线。

经过筛选，大致确定了5个组件：Thrift、gRPC、Halibut、SCS、Shuttler.net（这是按照知名度排序的）。前两个大家都很熟，后3个比较陌生吧。其中Halibut是Octopus deploy产品中的组件，已经在各种场景中验证过了，对其也寄予一定的厚望（Octopus deploy是自动化部署的产品，微软也在用，是个好东西）。

我的测试方法有些特殊，分为本机和局域网两种网络环境测试（我们的局域网是无线。300M带宽？好像是！）。每种环境在细分为两种场景：无限制、加入10MS延迟和1%丢包。

Thrift情况如下：

单连接 本机调用：100次耗时（毫秒） 局域网调用：100次耗时（毫秒）
无限制 丢包率：1%,延迟：10ms 无限制 丢包率：1%,延迟：10ms
响应时间 失败次数 响应时间 失败次数 响应时间 失败次数 响应时间 失败次数
第一次测试 79.1 0.0 10879.9 0.0 3816.1 0.0 8221.7 0.0
第二次测试 83.1 0.0 10613.9 0.0 3410.8 0.0 9189.4 0.0
第三次测试 80.6 0.0 12221.1 0.0 3726.1 0.0 9662.5 0.0
平均 80.9 0.0 11238.3 0.0 3651.0 0.0 9024.5 0.0
每次访问
新建连接		 本机调用：100次耗时（毫秒） 局域网调用：100次耗时（毫秒）
无限制 丢包率：1%,延迟：10ms 无限制 丢包率：1%,延迟：10ms
响应时间 失败次数 响应时间 失败次数 响应时间 失败次数 响应时间 失败次数
第一次测试 81.6 0.0 19414.9 0.0 3298.6 0.0 13124.0 0.0
第二次测试 83.1 0.0 22372.1 0.0 3200.1 0.0 13680.2 0.0
第三次测试 82.1 0.0 21589.0 0.0 3958.9 0.0 15757.5 0.0
平均 82.2 0.0 21125.3 0.0 3485.9 0.0 14187.2 0.0

gRPC情况如下：

单连接 本机调用：100次耗时（毫秒） 局域网调用：100次耗时（毫秒）
无限制 丢包率：1%,延迟：10ms 无限制 丢包率：1%,延迟：10ms
响应时间 失败次数 响应时间 失败次数 响应时间 失败次数 响应时间 失败次数
第一次测试 200.8 0.0 16899.8 0.0 3990.4 0.0 9199.9 0.0
第二次测试 200.2 0.0 18200.1 0.0 4099.9 0.0 9200.1 0.0
第三次测试 200.4 0.0 16801.0 0.0 3800.2 0.0 9599.6 0.0
平均 200.5 0.0 17300.3 0.0 3963.5 0.0 9333.2 0.0
每次访问
新建连接		 本机调用：100次耗时（毫秒） 局域网调用：100次耗时（毫秒）
无限制 丢包率：1%,延迟：10ms 无限制 丢包率：1%,延迟：10ms
响应时间 失败次数 响应时间 失败次数 响应时间 失败次数 响应时间 失败次数
第一次测试 20522.1 0.0 66560.1 0.0 41991.2 0.0 38106.0 0.0
第二次测试 20713.1 0.0 51348.0 0.0 40517.2 0.0 41988.8 0.0
第三次测试 20751.5 0.0 56108.4 0.0 42404.0 0.0 52477.6 0.0
平均 20662.2 0.0 58005.5 0.0 41637.5 0.0 44190.8 0.0

Halibut情况如下：

单连接 本机调用：100次耗时（毫秒） 局域网调用：100次耗时（毫秒）
无限制 丢包率：1%,延迟：10ms 无限制 丢包率：1%,延迟：10ms
响应时间 失败次数 响应时间 失败次数 响应时间 失败次数 响应时间 失败次数
第一次测试 75.1 0.0 15593.3 0.0 1056.6 0.0 13457.4 0.0
第二次测试 83.1 0.0 16775.7 0.0 775.9 0.0 9023.0 0.0
第三次测试 81.6 0.0 16857.4 0.0 891.4 0.0 10739.2 0.0
平均 79.9 0.0 16408.8 0.0 908.0 0.0 11073.2 0.0
每次访问
新建连接		 本机调用：100次耗时（毫秒） 局域网调用：100次耗时（毫秒）
无限制 丢包率：1%,延迟：10ms 无限制 丢包率：1%,延迟：10ms
响应时间 失败次数 响应时间 失败次数 响应时间 失败次数 响应时间 失败次数
第一次测试 1237.4 0.0 46431.4 0.0 17210.6 0.0 25839.7 0.0
第二次测试 1237.9 0.0 44134.8 0.0 10440.8 0.0 34425.2 0.0
第三次测试 1232.4 0.0 43727.5 0.0 22320.3 0.0 26654.1 0.0
平均 1235.9 0.0 44764.6 0.0 16657.2 0.0 28973.0 0.0

SCS情况如下：

单连接 本机调用：100次耗时（毫秒） 局域网调用：100次耗时（毫秒）
无限制 丢包率：1%,延迟：10ms 无限制 丢包率：1%,延迟：10ms
响应时间 失败次数 响应时间 失败次数 响应时间 失败次数 响应时间 失败次数
第一次测试 67.0 0.0 15465.6 0.0 685.6 0.0 7179.0 0.0
第二次测试 68.0 0.0 18709.0 0.0 819.1 0.0 11511.9 0.0
第三次测试 69.0 0.0 14791.2 0.0 703.3 0.0 7319.3 0.0
平均 68.0 0.0 16321.9 0.0 736.0 0.0 8670.1 0.0
每次访问
新建连接		 本机调用：100次耗时（毫秒） 局域网调用：100次耗时（毫秒）
无限制 丢包率：1%,延迟：10ms 无限制 丢包率：1%,延迟：10ms
响应时间 失败次数 响应时间 失败次数 响应时间 失败次数 响应时间 失败次数
第一次测试 74.1 0.0 20980.5 0.0 757.4 0.0 8978.9 0.0
第二次测试 70.0 0.0 22169.9 0.0 770.6 0.0 10990.9 0.0
第三次测试 77.6 0.0 16133.7 0.0 1019.4 0.0 14943.6 0.0
平均 73.9 0.0 19761.4 0.0 849.1 0.0 11637.8 0.0

Shuttler.net情况如下：

Shuttler是支持TCP和HTTP两种协议的，但是TCP的错误太多了，我就不贴了

每次访问
新建连接（HTTP）		 本机调用：100次耗时（毫秒） 局域网调用：100次耗时（毫秒）
无限制 丢包率：1%,延迟：10ms 无限制 丢包率：1%,延迟：10ms
响应时间 失败次数 响应时间 失败次数 响应时间 失败次数 响应时间 失败次数
第一次测试 46.5 0.0 46950.1 0.0 3062.8 0.0 37665.3 0.0
第二次测试 40.5 0.0 42380.0 0.0 2016.0 0.0 42242.0 0.0
第三次测试 39.5 0.0 47681.7 0.0 2080.4 0.0 35739.7 0.0
平均 42.2 0.0 45670.6 0.0 2386.4 0.0 38549.0 0.0

实际环境中，肯定是局域网环境，所以我把局域网部分的结果统计了一下。因为失败次数都为0，所以只统计了耗时。

项目(100次调用响应时间MS，局域网环境) Thrift Thrift（Teld） gRPC Halibut SCS Shuttler.net
单链接 无限制 3651.0 3774.8 3963.5 908.0 736.0 0.0
丢包率：1%,延迟：10ms 9024.5 9586.7 9333.2 11073.2 8670.1 0.0
多链接 无限制 3485.9 3777.6 41637.5 16657.2 849.1 2386.4
丢包率：1%,延迟：10ms 14187.2 9154.8 44190.8 28973.0 11637.8 38549.0

通过统计结果来看，SCS有三项第一，一项第二。特别是没有加入丢包和网络延迟的情况下，性能表现非常好。下一步对它和Thrift进行深入的研究。

.net RPC框架选型的更多相关文章

  1. Atitit.js javascript的rpc框架选型

    Atitit.js javascript的rpc框架选型 1. Dwr1 2. 使用AJAXRPC1 2.2. 数据类型映射表1 3. json-rpc轻量级远程调用协议介绍及使用2 3.1. 2.3 ...

  2. net框架平台下RPC框架选型

    net RPC框架选型 近期开始研究分布式架构,会涉及到一个最核心的组件:RPC(Remote Procedure Call Protocol).这个东西的稳定性与性能,直接决定了分布式架构系统的好坏 ...

  3. .net RPC框架选型（一）

    近期开始研究分布式架构,会涉及到一个最核心的组件:RPC(Remote Procedure Call Protocol).这个东西的稳定性与性能,直接决定了分布式架构系统的好坏.RPC技术,我们的产品 ...

  4. 老王讲自制RPC框架.(一.前言与技术选型)

    (#)背景 随着互联网的发展,网站应用的规模不断扩大,常规的垂直应用架构已无法应对,分布式服务架构以及流动计算架构势在必行,亟需一个治理系统确保架构有条不紊的演进. 单一应用架构 当网站流量很小时,只 ...

  5. 服务化实战之 dubbo、dubbox、motan、thrift、grpc等RPC框架比较及选型

    转自: http://blog.csdn.net/liubenlong007/article/details/54692241 概述 前段时间项目要做服务化,所以我比较了现在流行的几大RPC框架的优缺 ...

  6. dubbo、dubbox、motan、thrift、grpc等RPC框架比较及选型

    概述 前段时间项目要做服务化,所以我比较了现在流行的几大RPC框架的优缺点以及使用场景,最终结合本身项目的实际情况选择了使用dubbox作为rpc基础服务框架.下面就简单介绍一下RPC框架技术选型的过 ...

  7. 轻量级分布式 RPC 框架

    @import url(/css/cuteeditor.css); 源码地址:http://git.oschina.net/huangyong/rpc RPC,即 Remote Procedure C ...

  8. 【转】轻量级分布式 RPC 框架

    第一步:编写服务接口 第二步:编写服务接口的实现类 第三步:配置服务端 第四步:启动服务器并发布服务 第五步:实现服务注册 第六步:实现 RPC 服务器 第七步:配置客户端 第八步:实现服务发现 第九 ...

  9. 为什么说要搞定微服务架构，先搞定RPC框架？

    今天开始聊一些微服务的实践,第一块,RPC框架的原理及实践,为什么说要搞定微服务架构,先搞定RPC框架呢? 一.需求缘起 服务化的一个好处就是,不限定服务的提供方使用什么技术选型,能够实现大公司跨团队 ...

随机推荐

  1. IO流04--毕向东JAVA基础教程视频学习笔记

    Day20 01 File概述02 File对象功能-创建和删除03 File对象功能-判断04 File对象功能-获取05 File对象功能-文件列表106 File对象功能-文件列表207 列出目 ...

  2. Java Gradle入门指南之gretty插件（安装、命令与核心特性）

        Java Web应用开发时常使用Gradle来进行项目管理,可以十分便利地解决包依赖等问题.war插件的出现,让项目部署成为一个复制粘贴的过程,那有没有办法让Java web应用的部署,就像w ...

  3. jQuery自动完成组建Autocomplete

    一,属性介绍 * minChars (Number) 在触发autoComplete前用户至少需要输入的字符数.Default: 1,如果设为0,在输入框内双击或者删除输入框内内容时显示列表* wid ...

  4. python之递归实现

    一.递归函数 概念:递归算法是一种直接或者间接的调用自身算法的过程.在计算机编写程序中,递归算法对解决一大类问题是十分有效的. 特点: ①递归就是在过程或者函数里调用自身. ②在使用递归策略时,必须有 ...

  5. Hadoop生态圈以及各组成部分的简介

    1.Hadoop是什么? 适合大数据的分布式存储与计算平台 HDFS: Hadoop Distributed File System分布式文件系统 MapReduce:并行计算框架 解决的问题: HD ...

  6. vue相关的 helloword示例

    <!DOCTYPE html><html> <head> <title></title> <script src="http ...

  7. 烂泥：vcenter5.5无AD下的安装与配置

    本文由ilanniweb提供友情赞助,首发于烂泥行天下 想要获得更多的文章,可以关注我的微信ilanniweb. 公司现在的虚拟化使用的基本上都是vsphere,目前大约有7台物理机,为了更好的管理虚 ...

  8. 关于CocoaPods update/CocoaPods install 慢、没反应、卡住的解决方案(Pods升级步骤)

    pod管理第三方库带来的便利大家有目共睹,但是--,估计有很多人会遇到这样一种尴尬情况: Pod install 或 Pod update  执行之后,就不动了,一直一个界面简直要崩溃... 网上有很 ...

  9. Linux磁盘管理之日志文件系统和非日志文件系统08

    略. 查看linux支持的文件系统命令: ls /lib/module/`uname -r`/x86/fs blkid查看文件系统的类型 mkfs.ext2  == mkfs –t ext2

  10. QT学习第2天

    回顾: 1.构建一个QT工程步骤 (1)qmake -project (2)qmake (3)make   2.两个常用的组件 QLabel 标签 QPushButton 按钮   --------- ...