Thrift多路复用的设计与实现
Upcoming SlideShare
Loading in...5
×
 

Thrift多路复用的设计与实现

on

  • 543 views

 

Statistics

Views

Total Views
543
Views on SlideShare
543
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Thrift多路复用的设计与实现 Thrift多路复用的设计与实现 Document Transcript

  • Thrift 服务(Server)复用的设计与实现 作者:billowqiu@163.com 介绍 Thrift 作为一个跨语言的 rpc 框架,为后端服务间的多语言混合开发提供了高可靠,可 扩展,以及高效的实现。但是自从 2007 年 Facebook 开源后的 6 年时间内一直缺少一个多路 复用的功能(Multiplexing Services),也就是在一个 Server 上面实现多个 Service 调用。比如 要实现一个后端服务,很多时候不仅仅只是实现业务服务接口,往往还会预留一些调试, 监 控服务接口,以往要实现多个 Service 在一个 Server 上面调用,要么将多个服务糅合成一个 庞大的服务(图 1) ,要么将多个 Service 分摊到不同的 Server 上(图 2) 。最近的版本 0.9.1 终于实现内置的多路复用, 本文简要分析一下该功能的设计与实现, 并提供一个简单的示例。 图1
  • 图2  第一种方式将所有的接口放到一个服务中,会导致新接口增加时的代码维护成本  第二种方式采取将不同的 Service 绑定到不同的 Server,因为多个 Server 会监听多个端 口,最后导致运维方面的管理和维护成本增加(端口在某些时候是一个有限资源) 设计 Thrift 的架构如下: 图3 Thrift 采取了很优雅的分层设计,下面简述各层的主要功能:
  •  Transport 负责传输数据的接口,有文件,内存,套接字等实现。  Protocol 负责数据的协议交互接口,有二进制,Json 等实现。  Processor 负责输入输出数据处理的接口,其实就是对 Protocol 的处理。  Server 包括了上面各层的创建和管理, 并提供网络服务的功能, 网络服务这块目前有四个实现, 分别是最简单的单线程阻塞,多线程阻塞,线程池阻塞和基于 libevent 的非阻塞模式。 实现多路复用有以下几个需要注意的地方:  代码接口兼容  协议实现兼容  不依赖任何 Server 层代码,也不需要新的 Server 实现 0.9.1 之前版本不能多个 Service 在同一个 Server 上面调用, 主要是因为在协议层只把 Service 的函数名打包, 没有将 ServiceName 打包进去, 所以在 Processor 层默认只能处理一个 Service。 新版本中通过新增以下设计(红色部分)完成了 Service 的多路复用:
  • 图4 图5  Client 增加一个 MultiplexProtcol 实现,在原有协议基础上增加 ServiceName 的打包  Server 增加一个 MultiplexProssor 实现,分离不同的具体服务 实现 从 Release-Notes 看到目前已经有 Java,Delphi,C#,C++几个语言实现了该功能,具体到 C++实现按照 THRIFT-1902 的介绍,是直接移植的 java 版本。 新增代码 protocol/TMultiplexedProtocol.h protocol/TMultiplexedProtocol.cpp
  • protocol/TProtocolDecorator.h processor/TMultiplexedProcessor.h 主要逻辑 1) TMultiplexedProtocol 类重写 writeMessageBegin_virt 方法, Service 的函数名前新增了 在 ServiceName,并附带了一个分隔符;该类采取了 Decorator 模式将绝大部分操作转发到 实际的 protocol 对象。 2) TMultiplexedProcessor 类增加了一个存放 service 的 map, typedef std::map< std::string, shared_ptr<TProcessor> > services_t; key 为 ServiceName , 这 样 在 process 方 法 中 先 解 出 TMultiplexedProtocol 传 递 过 来 的 ServiceName, 通过该 key 查找到对应的 Processor 对象, 再调用该 Processor 的 process 方法, 这样就完美的实现了多个 serivice 的共存。 使用示例 IDL: namespace cpp thrift.multiplex.demo service FirstService { void blahBlah() } service SecondService { void blahBlah() } Server: int port = 9090; shared_ptr<TProcessor> processor1(new FirstServiceProcessor (shared_ptr<FirstServiceHandler>(new FirstServiceHandler()))); shared_ptr<TProcessor> processor2(new SecondServiceProcessor (shared_ptr<SecondServiceHandler>(new SecondServiceHandler()))); //使用 MultiplexedProcessor
  • shared_ptr<TMultiplexedProcessor> processor(new TMultiplexedProcessor()); //注册各自的 Service processor->registerProcessor("FirstService", processor1); processor->registerProcessor("SecondService", processor2); shared_ptr<TServerTransport> serverTransport(new TServerSocket(port)); shared_ptr<TTransportFactory> transportFactory(new TBufferedTransportFactory()); shared_ptr<TProtocolFactory> protocolFactory(new TBinaryProtocolFactory()); TSimpleServer server(processor, serverTransport, transportFactory, protocolFactory); server.serve(); Client: shared_ptr<TSocket> transport(new TSocket("localhost", 9090)); transport->open(); shared_ptr<TBinaryProtocol> protocol(new TBinaryProtocol(transport)); shared_ptr<TMultiplexedProtocol> mp1(new TMultiplexedProtocol(protocol, "FirstService")); shared_ptr<FirstServiceClient> service1(new FirstServiceClient(mp1)); shared_ptr<TMultiplexedProtocol> mp2(new TMultiplexedProtocol(protocol, "SecondService")); shared_ptr<SecondServiceClient> service2(new SecondServiceClient(mp2)); service1->blahBlah(); service2->blahBlah(); 总结 Thrift 通过在客户端采取的 decorator 模式巧妙的在协议层将 ServiceName 传递到服务端,服 务端通过常见的手段将 ServiceName 和具体的 Processor 进行映射,完美的解决了 Server 对 Service 的多路复用问题。 参考资料 1. 2. 3. 4. http://thrift.apache.org/docs/concepts/ https://issues.apache.org/jira/browse/THRIFT-1902 https://issues.apache.org/jira/browse/THRIFT-563 http://bigdata.impetus.com/whitepaper