首页 > 代码库 > Thrift 个人实战--Thrift 服务化 Client的改造

Thrift 个人实战--Thrift 服务化 Client的改造

 

前言:
  Thrift作为Facebook开源的RPC框架, 通过IDL中间语言, 并借助代码生成引擎生成各种主流语言的rpc框架服务端/客户端代码. 不过Thrift的实现, 简单使用离实际生产环境还是有一定距离, 本系列将对Thrift作代码解读和框架扩充, 使得它更加贴近生产环境. 本文主要讲解thrift的服务化改造, 这边侧重于阐述对client(服务调用方)的改造和设计思想.

基础概念:
  传统对client的优化, 主要是Client Manager化, 优化方式包括引入连接池, 支持Failover/LoadBalance机制. 这部分内容可以参考flume sdk文章, 里面对client的优化, 细心到了极致.
  PRC服务化, 对于client(服务调用方)而言, 应该隐藏client和server端的交互细节(包括failover/loadbalance), 唯一需要暴露/使用的是服务方提供的接口. 简而言之, 通过service接口进行rpc服务, 而不是采用client的api去访问.
  用thrift api作为例子

// *) Client API 调用(EchoService.Client)client.echo("hello lilei");	 ---(1)// *) Service 接口 调用	(EchoService.Iface)service.echo("hello lilei");	 ---(2)

  评注: (1) Client API的方式, 不推荐, (2) Service接口的方式(服务化), 推荐

面向接口编程:
  先来看下thrift生成的类有那些

namespace java mmxf.thriftservice EchoSerivce {  string echo(1: string msg);}

  其生成的类有如下所示:

// *) Thrift生成的EchoService代码, 省略了函数和具体实现public class EchoSerivce {  // *) 接口类Iface, 同步接口   public interface Iface {}  // *) 接口类AsyncIface, 异步接口  public interface AsyncIface {}  // *) 具体类, 同步Client  public static class Client {}  // *) 具体类, 异步Client	  public static class AsyncClient {}	}

  评注: EchoService.Iface就是同步EchoSerivce的接口定义, 而EchoService.Client则是与服务端交互的具体客户端实例.
  面向接口编程, 采用装饰者模式(Decorator Pattern, 接口+组合), 借助实现EchoService.Iface接口, 握有EchoService.Client实例的方式去实现. 这样能达到服务化的初步雏形, 但这远远不够.

服务化的基本特征:
  RPC Client服务化的基本特征(个人观点), 可以分为如下:
  1). 泛型化, 作为一个服务框架存在, 不而是只用于具体模块
  2). 内部封装的client需要实现client-manager化, 即支持连接池/failover/loadbalance
  3). 通过订阅服务的方式, 透明的调用服务提供方(不需要知道服务提供方的server ip:port 列表)
  本文主要阐述思路, 服务订阅放在后续的文章, 弱化Client-Manager, 但支持泛型化来实现一个简单的client service解决方案.

解决方案:
  对泛型Thrift Service的支持, 采用JDK自带的动态代理来实现.

public interface InvocationHandler {  public Object invoke(Object proxy, Method method, Object[] args);}

  评注: Object proxy: 指被代理的对象, Method: 要调用的方法, Object[] args: 方法调用时所需要的参数

public class DynamicClientProxy<T> implements InvocationHandler {  // *) 引入类Class, 以及RpcServer配置  public Object createProxy(Class<T> ts, RpcServerConfiguration configuration) {  // *) 静态类Proxy生成动态代理实例    return Proxy.newProxyInstance(ts.getClassLoader(), ts.getInterfaces(), this);  }  @Override  public Object invoke(Object proxy, Method method, Object[] args)        throws Throwable {    // *) 外循环是简单的failover机制, 用于失败时重试    for ( ServerNode serverNode : serverNodes ) {      // *) 创建TSocket对象      TSocket tsocket = new TSocket(ip, port);      tsocket.setTimeout(timeout);      // *) 二进制协议      TProtocol protocol = new TBinaryProtocol(tsocket);      // *) 借助反射(构造函数)来产生实例对象      Class[] argsClass = new Class[] {            TProtocol.class        };      Constructor<T> cons = (Constructor<T>) ts.getConstructor(argsClass);      T client = (T)cons.newInstance(protocol);      tsocket.open();      // *) 反射调用, 这个最重要      return method.invoke(client, args);    }  }}

  评注: 上述代码中省略了不少, 大致是如上代码所述的思路, 具体的代码详见附件.

  创建定义DynamicClientProxy<T> 泛型类, 用于动态代理对象的创建.
  调用代码如下所示:

RpcServerConfiguration configuration = new RpcServerConfiguration();configuration.getServerNodes().add(new ServerNode("127.0.0.1", 9010));DynamicClientProxy<EchoService.Client> proxy = 		new DynamicClientProxy<EchoService.Client>();EchoService.Iface service = (EchoService.Iface)		proxy.createProxy(EchoService.Client.class, configuration);service.echo("hello dynamic");

  评注: 是不是简洁了不少, 对泛型的支持也比较优雅.

继续改进: 

  上述的泛型代码虽然灵活了不少, 但需要硬编码, 是否可以借助spring来实现配置优化呢?
  首先我们引入DynamicClientProxyFactory类, 该类用于产生具体的代理类

public class DynamicClientProxyFactory {  public static Object createIface(String clazzIfaceName, List<String> servers) {    // *) 内部类的表, 不用‘.‘, 而使用‘$‘分割    int idx = clazzIfaceName.lastIndexOf(‘$‘);	    // *) 创建内部类Iface     String clazzClientName = clazzIfaceName.substring(0, idx) + "$Client";    Class clientClazz = Class.forName(clazzClientName);    // *) 创建代理对象	    DynamicClientProxy proxy = new DynamicClientProxy();    return proxy.createProxy(clientClazz, configuration);	  }}

  同时spring中, 我们采用如下的方式来配置service接口的bean, 这边采用了Bean Factory的方式创建实例对象

<bean id="echoService" class="com.lighting.rpc.core.client.DynamicClientProxyFactory" factory-method="createIface">  <constructor-arg>    <value>mmxf.thrift.EchoService$Iface</value>  </constructor-arg>  <constructor-arg>    <list>      <value>127.0.0.1:9000</value>      <value>127.0.0.1:9001</value>    </list>  </constructor-arg></bean>

  评注: 具体的参数是服务类的接口, 以及server ip:port列表. 同时采用@Resource的方式来注册这个service bean即可.

 服务体验:

编写测试用例

ClassPathXmlApplicationContext applicationContext = 	new ClassPathXmlApplicationContext("application_context.xml");		EchoService.Iface service = (EchoService.Iface)	applicationContext.getBean("echoService");		System.out.println(service.echo("lilei"));

评注: 是不是很简单明了.

总结: 
  RPC服务化方便编程, 也隐藏了服务端/客户端的交互细节. 另一个好处是方便测试, 使用stub, 模拟各种异常和交互. 当然使用Client也可以, 不过这需要借助bug级神奇Mockito. 总得来说RPC服务话, 对rpc服务调用方而言, 大大降低了开发门槛和难度.

当前的不足:
  1). 没有实现对象池, 若实现了ThriftClientObjectPool, 代码的整体架构会显得更加简单.
  2). 没有使用订阅服务列表, 使得在配置中, 需要指定ip:port列表.
后续:
  后续会编写发布/订阅服务列表的实现方案, 这部分需要和服务端编写一起讲述, 并实现ThriftClient的对象池. 敬请期待.

代码下载链接: http://download.csdn.net/download/mmstar/7699445