码迷,mamicode.com
首页 > 其他好文 > 详细

RPC

时间:2017-12-19 01:14:30      阅读:134      评论:0      收藏:0      [点我收藏+]

标签:客户   http协议   没有   推送   blob   构建   最大的   bsp   均衡   

 

一、前言

  在上一篇分布式系统系列中《分布式系统中的必备良药 —— 服务治理》中阐述了服务治理的一些概念,那么与服务治理配套的必然会涉及到RPC框架。在当前互联网的大背景下,RPC的运用应该大家或多或少都有涉及,国内外的RPC框架也是百花齐放。那么各个RPC框架各自有什么特点,另外RPC的核心点又是哪些,我们该如何去选择是本文需要讲述的内容。本文会围绕.Net技术栈来展开,暂不讨论诸如dubbo之类对.Net 不太友好的框架。

 

二、成熟的解决方案

  1.Google.gRpc(https://github.com/grpc/grpc

    大名鼎鼎的Google出品的RPC框架,基于Http2设计,支持双向流、消息头压缩、单 TCP 的多路复用、服务端推送等特性,这些特性使得 gRPC 在移动端设备上更加省电和节省网络流量。使用的时候需要通过定义proto文件生成客户端和服务端代码,可以跨平台(客户端和服务端生成代码时使用不同的语言)。如果大家已经被微软宠惯了,那么是不太习惯以一个纯txt方式编辑这个proto文件的,毕竟全部需要手打 ╮(╯_╰)╭

  2.Facebook.Thrift(https://github.com/apache/thrift

    同样是大厂Facebook出品的RPC框架,使用方式和gRpc类似,需要通过定义.thrift文件生成客户端和服务端代码,可以跨平台(客户端和服务端生成代码时使用不同的语言)。Thrift的缺点是无法生成async,await,Task<T>之类的泛型代码,这个对于当下大背景来说有一定的局限性(如果有小伙伴知道如何解决此问题,感谢赐教)。Thrift最大的特点是5种适用不同场景的服务模型,一图胜千言,直接上图,见图1:

技术分享图片

                    【图1】

     但是遗憾的是Apache在.Net下提供的实现并不是上面的5种模式,仅仅3种(TSimpleServer、TThreadPoolServer、TThreadedServer),特别是在Java下大规模宣传的NIO模式没有提供实现。

  3.Orleans(http://dotnet.github.io/orleans/

    这是微软在2015开源的构建分布式应用的框架。(什么意思?那它是RPC框架么?)我想这是大部分对Orleans不熟悉的同学的疑问,实际上Orleans的层次比RPC框架更高,它不仅仅解决了远程调用问题,其内部还包含了服务发现、负载均衡、高可用等一些处理机制。一般用Akka(有.net版本 Akka.net)和它对标,都是基于Actor模型设计的分布式框架,顺手附上一篇经典的对比文章:https://github.com/akka/akka-meta/blob/master/ComparisonWithOrleans.md 。Orleans最大的特点就是微软一向的风格,高度封装,提高生产力。面向OOP的设计,便于使用,大家可以在文末下载Demo感受一下,手感和WCF比较类似。

  4.WCF

    这应该是.net系下做分布式系统开发中的RPC标配了,随着.net framework3.5在2007年推出,可谓功能丰富,而且支持的协议相比其它框架也是最多(没有之一)。

  5.WebApi

    这是随着VS2012一起推出的REST化API的一项web服务。近几年随着整个大环境的变化,逐渐有代替WCF的趋势。跨平台(特别是针对移动端有很大优势)、便于开放共享和测试是他相对WCF的最大优势。

 

三、剖析

   上面的这些框架说不上孰优孰劣,都有各自适用的场景。那么我们来刨析一下如果要选择哪个RPC框架更适合的话从何处入手。一个RPC框架核心的概念是下面几个:

网络协议:

  这是RPC框架的核心,面向什么协议去设计,基本上也已经决定了框架最理想的适用场景了。协议又分为2个大类,分别对应OSI七层模型的应用层(http协议、ftp协议等)和传输层(tcp协议、udp协议)。这其中的协议又有各自的特点,这里就不展开说了。当然有些框架将协议这层做成可适配的,比如WCF(不同协议)、thrift(同协议不同实现),那么他们的覆盖场景肯定就更多,但是相应的框架的实现复杂度肯定也是相应增加,需要考虑是否能接收这带来的额外成本。

 

 序列化方式:

  序列化一般从3个维度去考虑,数据大小、可读性、传输效率(序列化反序列所消耗的时间)。属于可读性较好的序列化比如Json;属于数据压缩比比较好的序列化比如Protobuf;属于传输效率高的序列化比如MessageShark、MessagePack、Protobuf等。对于对性能十分执着的小伙伴们,这里有一份转载的基准测试报告,连接附上:https://www.cnblogs.com/shanyou/p/3294201.html 。大部分的框架都会序列化这层做成可适配的,相对网络协议,对序列化的个性化迫求是更强烈的。

 

四、性能测试

测试环境如下:

  CPU:I5-4300U 1.90GHz  2.50GHz

  内存:8G

  策略:10000次调用发送封装world字符串的对象HelloRequest,并等待接收返回封装Hello world字符串的HelloReply对象。

  网络:数据较小+本地调用,网络不是问题。想进一步测试局域网和大数据的可以基于文末的Demo项目自行改造。

  这里需要提一下,WCF的测试使用了http和tcp2种常见的模式,针对webapi的访问使用了HttpClient和HttpWebRequest2种方式。另外值得注意的是,由于Thrift和HttpWebRequest不支持多线程复用同一个实例,故在测试中都是使用每次实例化的方式进行(包括线程数1的时候)。

  由于数据比较多,直接付上2个动图,想进一步分析的可以在文末下载excel自行解决~。见图2,图3:

技术分享图片

                  【图2】

技术分享图片

                  【图3】

  

五、结语

  这个是我网上找到的一篇性能相关的文章,大家可以参考一下:http://blog.csdn.net/jek123456/article/details/53395206

  归根到底,大家在使用之前还是需要结合自己的实际情况,放到实际的场景去测一把,看看效果。下面奉上替大家迈出第一步的Demo,大家可以进行进一步的深入研究。

 

 

本文相关的测试数据excel在此:https://github.com/ZacharyFan/RpcTest/raw/master/PerfTest.xlsx

本文相关的Demo地址在此:https://github.com/ZacharyFan/RpcTest

RPC

标签:客户   http协议   没有   推送   blob   构建   最大的   bsp   均衡   

原文地址:http://www.cnblogs.com/Leo_wl/p/8059111.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
分享档案
周排行
mamicode.com排行更多图片
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!