• Feeds

  • Posts Tagged ‘thrift’


    服务管理框架的尝试

    大型软件系统开发需要模块化,在分布式系统中,模块化通常是将功能分成不同的远程服务(RPC)来实现。比如可以用Java RMI、Web Service、Facebook开源的Thrift等一些技术。同样,在一个大型系统中,服务化之后服务的可维护、可管理、可监控以及高可用、负载均衡等因素同服务本身同样重要。

    服务管理目前并无直接解决方案,Thrift作者Mark Slee提到

    It’s also possible to use Thrift to actually build a services management tool. i.e. have a central Thrift service that can be queried to find out information about which hosts are running which services. We have done this internally, and would share more details or open source it, but it’s a bit too particular to the way our network is set up and how we cache data. The gist of it, though, is that you have a highly available meta-service that you use to configure your actual application server/clients.

    Source: [Thrift] Handling failover and high availability with thriftservices

    如果开发一个自己的服务管理框架,需要具备以下功能

    • 快速失败,这个在本厂意义重大,很多远程服务调用是在关键路径中,它可以容忍失败,但是不能容忍堵塞
    • failover,客户端failover支持,并支持自动失效探测及恢复调用
    • 中心化配置及推送功能,所有client在同一时刻配置的一致性,并且client会跟配置中心保持长连
    • 负载均衡策略:支持round robin,least active, consistent hash,或者基于脚本的动态路由策略。这个都是由配置中心来控制
    • 动态启用及停用服务及节点:可以动态启动及停用服务(热发布),由于有推送功能,相对容易实现
    • 跨语言:支持client能使用常见主流语言来访问
    • 版本管理:同一服务可以有不同的版本并存
    • 访问统计及动态运行参数查看:可以对方法级别进行访问统计及实时观察

    访问策略

    服务框架倾向于直连的方案,即client是直接连接server,而不会增加中间物理上的代理层,服务框架只做中心配置、访问策略、服务发现、配置通知等职责。

    路由的特殊需求

    通常的服务访问,使用上述round robin等3种策略即可,但是在实际工程实践中,我们发现有些不同的需求。比如计数这样的远程服务,读操作可随机访问一台远程节点,但写操作需要访问所有的服务节点才能实现。因此我们需要有广播式的访问需求。由于计数服务对实时性和一致性要求较高,不适合采用异步如Pub/Sub这样方式去实现,因此在client还需要支持同步的广播调用。

    耦合及侵入的矛盾

    在设计服务管理系统之前,我们希望不跟一种具体的技术(如Thrift)绑定,比如client和server服务实现方不需要太多关心底层技术。但是在实际实现过程中碰到不少矛盾。

    IDL侵入

    在使用Thrift之后服务实现很难绕过Thrift IDL,使用方需要自己维护IDL以及Thrift生成的代码,服务框架支持将Thrift服务注册到配置系统中。虽然也可以绕过IDL来实现服务,但是框架相关功能的实现和维护成本比较高。

    RPC框架的侵入

    Thrift Transport可以使用TCP(Socket)或者是HTTP
    这个也是非常好的特性,在某些情况Transport使用HTTP会带来很多便利,使用HTTP虽然有一些额外开销,但是HTTP的周边配套设施的完善足够抵消这种开销。使用TCP很多状态实时监控都需要服务系统从头做起。

    Thrift的Version与服务的version存在一定的重复
    服务牵涉到版本管理,我们希望通过发现服务来管理,但是Thrift本身也有版本的设计。

    这些矛盾的本质就是服务框架需要的一些功能是自己实现还是依赖Thrift来实现,很多Thrift使用方如Twitter rpc-client干脆就直接在Thrift框架基础上增强。

    虽然存在上述一些待解决问题,厂内第一个使用服务框架管理的服务即将上线,很快每天会有数十亿的调用将会在此之上产生,同时也会有新的挑战出现。


    Figure 1: Facebook Service Management Console
    (来源:http://www.slideshare.net/adityaagarwal/qcon Slide 27)

    Thrift and Protocol Buffers performance in Java Round 2

    In my last test Thrift and Protocol Buffers performance in Java, Some comments told me that there are some tuning parameter for Protocol Buffer which can improve performance magically. The parameter was not turn on by default. I added
    option optimize_for = SPEED
    to the proto file, and re-generated the Java class, and the result:

    Thrift Loop    : 10,000,000
    Get object     : 14,394msec
    Serdes thrift  : 37,671msec
    Objs per second: 265,456
    Total bytes    : 1,130,000,000
    
    ProtoBuf Loop  : 10,000,000
    Get object     : 8,170msec
    Serdes protobuf: 33,054msec
    Objs per second: 302,535
    Total bytes    : 829,997,866
    

    From the result, Protocol Buffers is 1.1 times faster than Thrift!

    And from the Google Protocol Buffers group, why the optimize for speed was not turn on by default.

    When using C++ or Java protocol buffers, for best performance you need to add a line to your .proto files:

    option optimize_for = SPEED;

    Otherwise, by default, the compiler optimizes for code size.  Optimizing for code size results in generated code that around a half to a third of the size, but runs an order of magnitude slower…

    Here is the original post

    Thrift and Protocol Buffers performance in Java

    I’ve used Thrift for some log client in our system. I’m going to use Protocol Buffers as the internal communication protocol between our XMPP servers. But I am hard to believe from the thrift and protocol buffers Python performance comparison, that that Protocol Buffers is 4-10 slower than Thrift. I’m going to do some similar tests on Java.

    The test is very similiar as the Python test. the .proto and .thrift file are copied from the above python test.

    The .thrift content:

    struct dns_record {
    1: string key,
    2: string value,
    3: string type = 'A',
    4: i32 ttl = 86400,
    5: string first,
    6: string last
    }
    
    typedef list<dns_record> biglist
    
    struct dns_response {
    1: biglist records
    }
    
    service PassiveDns {
    biglist search_question(1:string q);
    biglist search_answer(1:string q);
    }

    The .proto content

    package passive_dns;
    
    message DnsRecord {
    required string key = 1;
    required string value = 2;
    required string first = 3;
    required string last = 4;
    optional string type = 5 [default = "A"];
    optional int32  ttl = 6 [default = 86400];
    }
    
    message DnsResponse {
    repeated DnsRecord records = 1;
    }

    From the document, I learn that the optional and default values are one of the benefits of both serialization libraries. A record that matches the default value does not need to be included in the serialized output.

    I wrote up a simple test program to compare thrift, protocol buffers. I tested the serialize and deserialize together, because this is the most called part in most scenarioes.

    Test 1: 10,000,000 times

    ProtoBuf Loop  : 10,000,000
    Get object     : 15,130msec
    Serdes protobuf: 68,600msec
    Objs per second: 145,772
    Total bytes    : 829,996,683
    
    Thrift Loop    : 10,000,000
    Get object     : 12,651msec
    Serdes thrift  : 36,904msec
    Objs per second: 270,973
    Total bytes    : 1,130,000,000

    Test 2: 1,000,000 times

    ProtoBuf Loop  : 1,000,000
    Get object     : 1,094msec
    Serdes protobuf: 7,467msec
    Objs per second: 133,922
    Total bytes    : 83,000,419
    
    Thrift Loop    : 1,000,000
    Get object     : 524msec
    Serdes thrift  : 5,969msec
    Objs per second: 167,532
    Total bytes    : 113,000,000

    The serde_* functions are the times needed to serialize, and de-serialize the java object to and from a byte[].

    The result in Java was that Protocol Buffers 1.2-2 times slower than Thrift. (in the python test was 4~10 times). And PB binary size is smaller than Thrift. I think this is acceptable, and Google may improve the Protocol Buffers performance in the future version.

    Download my test code in Java: thrift-protocol-buffers-java.tgz,

    More information about thrift and protocol buffers: Thrift, Protocol Buffers installation and Java code howto

    Update: There is another Thrift vs. Protocol Buffers compare non-performance factors.

    UPDATE 2 (Apr 17): There is a performance tuning parameter optimize_for = SPEED (thanks Steve Chu) for Protocol Buffers, please see my next performance tests Thrift and Protocol Buffers performance in Java Round 2

    12