近期开始研究分布式架构,会涉及到一个最核心的组件: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情况如下:
gRPC情况如下:
Halibut情况如下:
SCS情况如下:
Shuttler.net情况如下:
实际环境中,肯定是局域网环境,所以我把局域网部分的结果统计了一下。因为失败次数都为0,所以只统计了耗时。
通过统计结果来看,SCS有三项第一,一项第二。特别是没有加入丢包和网络延迟的情况下,性能表现非常好。下一步对它和Thrift进行深入的研究。