用norbert来写高并发分布式服务框架
本来计划将sensei的相关源码系列搞完,但最近一段时间由于工作需求先调研了几种分布式的服务框架,做了简要的对比测试。根据我们自己的实际需要选取了norbert来做我们后台提供分布式服务的框架。因此,先整理一篇关于norbert框架的博文,也给自己留下个印记,以便以后来查阅。
Norbert简介
“Norbert is a library that provides easy cluster management and workload distribution. With Norbert, you can quickly distribute a simple client/server architecture to create a highly scalable architecture capable of handling heavy traffic. ”
这个是官方的描述,没有比这个更精准的了,norbert是一个提供分布式集群服务的开发框架,具备集群管理功能,对开发简单的通信架构,易扩展能承受高吞吐量的框架。
其中集群管理的功能利用了zookeeper来进行node状态的感知,通讯采用了nio的netty server,序列化采用的是protobuf。整体而言来做分布式的服务,应该是非常合适的。linkedin在他们的架构里面都用到了这个框架。其实现是scala来写的,但我们使用java版的调用。
下面是我给team同事做的一次介绍性的ppt,比较简单,从使用层面来讲的,仅供参考。
三种框架的对比
在进行技术选型的时候,我们主要考察了hessian,thrift,norbert:
1. hessian是相对最成熟,最可靠的方式,在很多工程里面都用到,在异构java应用间的调用也还比较高效,已经有一些关于它的序列化测试。 但由于是http的协议,在连接数上受制于resin或者其他web服务器的链接数。
2. thrift facebook开源的一个rpc的框架,主要特点是跨语言,现在贡献给了apache,市场上使用较多,在多语言开发的场景下很适合。走socket协议,没有集成zookeeper的管理,需要自己实现连接池之类。
3. norbert linkedin开源的框架,支持集群管理(zookeeper),走socket协议,protobuf的序列化支持。scala语言开发,不支持其他多语言,成熟度相对较低。
测试环境: 输入为一片文章,服务进行分词和统计词数,并且返回。
测试结果显示,在thread设置100,300,500,1000 并发进行压力测的时候,norbert与hessian相差无几;而当thread上1k的时候,hessian受限于resin的连接数抛出链接的异常。 thrift由另一同事进行同样的业务测试,测试结果与norbert稍逊,同样能撑1000以上的thread。
在选型的时候,我们的目标是能够撑住新鲜事的服务,搜索更新的服务。并发链接数可能很大,因此更倾向于socket协议的norbert和thrift,而进行开发过程中,暂无支持其他语言的需求,但如果能支持集群服务,则开发更加简单。
因此,打算采用norbert。
对Norbert的简易封装
目的:让其他开发同事只关注于业务的实现,而将服务调用的开发流程更加简化。默认支持一致性hash的负责均衡。
首先,对于一致性hash的使用,参考了xmemcahed客户端的KETAMA_HASH和redis客户端的MurmurHash。并且根据两种包装了一下,测试了两种在节点增减的情况下的负载性能和效率:
测试环境: 在原本的固定节点数 n=2,5,10,50 ,并且分别增加一个节点,减少一个节点,导致miss的比率。
50,51,49
Ketamahash:
Total Same percent in added case : 97.728035%
Total Same percent in reduced case : 97.91693%
used time: --- 815 miliseconds!
murmurhash:
Total Same percent in added case : 97.97288%
Total Same percent in reduced case : 98.00935%
used time: --- 664 miliseconds!
10,11,9
Ketamahash:
Total Same percent in added case : 91.03272%
Total Same percent in reduced case : 90.187935%
used time: --- 762 miliseconds!
murmurhash:
Total Same percent in added case : 90.67101%
Total Same percent in reduced case : 90.65535%
used time: --- 596 miliseconds
5,6,4
Ketamahash:
Total Same percent in added case : 83.67601%
Total Same percent in reduced case : 79.67246%
used time: --- 753 miliseconds!
murmurhash:
Total Same percent in added case : 82.390625%
Total Same percent in reduced case : 78.72605%
used time: --- 581 miliseconds!
2.3.1
Ketamahash
Total Same percent in added case : 70.222466%
Total Same percent in reduced case : 50.81403%
used time: --- 723 miliseconds!
murmurhash:
Total Same percent in added case : 68.841545%
Total Same percent in reduced case : 50.361725%
used time: --- 542 miliseconds!
结论: