facebook/swift:构建thrift http server(1)

如何基于facebook/swift构建一个支持HTTP访问的thrift服务?说来话长。我将用分几篇博客介绍这个问题的解决思路和具体实现。

背景说明

我有一个项目facelog，是基于facebook/swift框架(java)开发的。在实际的项目应用时，需要从浏览器端能调用facelog的接口方法，要实现这个功能，一个笨办法就是专门写一个java web应用，相当于一个二传手，对浏览器需要访问的facelog方法，提供GET/POST调用接口供浏览器调用，现在我们就是这么干的，这么做无疑增加了开发工作量，能不能让浏览器直接调用facelog服务的接口方法呢？
如果能这样实现将好处多多：
不需要java web应用设计作为转发用途的POST/GET接口，减少了开发工作量同时也减少了系统的响应延迟及复杂度。

Node.js方案

facebook/swift是基于thrift的java平台的RPC框架。thrift是一种支持广泛开发语言的RPC框架，自然也是支持javascript访问的。
thrift的官方网站的《Javascript Tutorial》详细介绍了如何用在浏览器上用javascript访问thrift服务。参照这个教程可以就可以构建一个node.js服务，浏览器则通过javascript访问node.js提供的thrift接口，在这个tutor中，前端使用javascript，服务端则是用Node.js实现的。

所以参照上面的教程在浏览器上用javascript访问facelog服务是完全可以实现的。然而仔细评估之后，觉得《Javascript Tutorial》提供的这个方案对于我的facelog项目并不是最佳解决方案，原因嘛，总得来说就是更麻烦，如下：

1. 开发工作量更大
   《Javascript Tutorial》方案中，后端是一个node.js服务。而facelog是一个java平台的服务。如果采用这个方案，我需要重写一个node.js服务作为代理服务转所有的HTTP请求到facelog(java)。对于拥有100多个接口方法的facelog服务，再重写一个一样的node.js转发服务也是不小的工作量，这同样增加了项目的复杂度和系统响应延迟，后续维护的工作量也相应增加。
2. 部署运维更复杂
   facelog(java)的部署很简单，系统依赖很简单，只需要java虚拟机就可以在命令行直接运行，如果增加一个node.js服务，就需要多一个node的运行平台。对于项目部署和运维都增加了难度和工作量。

所以对于我来说，理想的方案就是运行一个支持XHR(XML Http Request)访问的facelog(java)服务，它占用一个新的端口号，web端通过javascript用浏览器的XMLHttpRequest对象直接调用这个XHR服务。这样对于facelog来说只是增加一个新的端口号而已，新的XHR服务还是在java平台运行。没有中间商赚差价，web端的系统响应迟延与java client是一样的。

TServlet方案

那么thrift的java框架有没有提供HTTP访问能力呢？答案是有的。
请关注org.apache.thrift.server.TServlet这个类。
下面是TServlet的部分代码

public class TServlet extends HttpServlet {
	private final TProcessor processor;
	private final TProtocolFactory inProtocolFactory;
	private final TProtocolFactory outProtocolFactory;
	private final Collection<Map.Entry<String, String>> customHeaders;

	public TServlet(TProcessor processor, TProtocolFactory inProtocolFactory, TProtocolFactory outProtocolFactory) {
		this.processor = processor;
		this.inProtocolFactory = inProtocolFactory;
		this.outProtocolFactory = outProtocolFactory;
		this.customHeaders = new ArrayList<Map.Entry<String, String>>();
	}

	public TServlet(TProcessor processor, TProtocolFactory protocolFactory) {
		this(processor, protocolFactory, protocolFactory);
	}

	protected void doPost(HttpServletRequest request, HttpServletResponse response)
			throws ServletException, IOException {
		TIOStreamTransport inTransport = null;
		TIOStreamTransport outTransport = null;
		try {
			TIOStreamTransport transport;
			response.setContentType("application/x-thrift");
			if (null != this.customHeaders) {
				for (Map.Entry<String, String> header : this.customHeaders) {
					response.addHeader(header.getKey(), header.getValue());
				}
			}
			ServletInputStream in = request.getInputStream();
			ServletOutputStream out = response.getOutputStream();
			inTransport = transport = new TIOStreamTransport((InputStream) in, (OutputStream) out);
			outTransport = transport;
			TProtocol inProtocol = this.inProtocolFactory.getProtocol((TTransport) inTransport);
			TProtocol outProtocol = this.outProtocolFactory.getProtocol((TTransport) outTransport);
			this.processor.process(inProtocol, outProtocol);
			out.flush();
		} catch (TException te) {
			throw new ServletException((Throwable) te);
		}
	}

	protected void doGet(HttpServletRequest request, HttpServletResponse response)
			throws ServletException, IOException {
		this.doPost(request, response);
	}
}

如果你熟悉thrift,在TServlet类的代码中看到TProcessor，TProtocol类就明白，这个类继承自javax.servlet.http.HttpServlet,可以将一个thrift接口服务(TProcessor)封装为一个Servlet。有了Servlet，就可以在所有支持Servlet的web容器(比如tomcat)上运行thrift服务了.

当初看到这个类，我好一阵兴奋，庆幸自己这么容易就找到了答案。但深入了解之后，得出一个令人沮丧的结论，TServlet方案也不是适合我的方案。

1. TProcessor非ThriftServiceProcessor
   对，org.apache.thrift.TProcessor非com.facebook.swift.service.ThriftServiceProcessor，前一个是thrift(java)定义的接口，后者则是facebook/swift定义的接口，我的facelog项目基于facebook/swift设计，服务接口封装为ThriftServiceProcessor实例，并不能直接作为参数被TServlet封装为Servlet
2. 额外的Servlet容器
   就算想办法将ThriftServiceProcessor封装为TProcessor丢进TServlet封装为Servlet，也需要tomcat这样的Servlet容器才能运行。原本facelog只需要一个standalone的jar包就能在JVM上运行，项目部署极简单，现在凭空多了个tomcat，配置运行tomcat对于项目部署运维就增加了很多的工作量，所以tomcat对于我来说太重了。
   那么jetty呢？Jetty 是一个开源的servlet容器，可以将Jetty容器实例化成一个对象，可以迅速为一些独立运行（stand-alone）的Java应用提供网络和web连接。但同样要增加一些依赖包不是么？我对jetty并不熟悉，为了解决问题学习jetty的成本也要考虑进去。风险也不小。

Netty http server

这也不行，那也不行，你到底要闹哪样啊？
不想增加tomcat,甚至不想增加额外的依赖库，只基于facebook/swift实现一个XHR服务，让浏览能直接访问thrift服务接口。
对，这就是我的最理想的方案。
太晚了，写不下去了。
请看我的下一篇博客。

《facebook/swift:构建thrift http server(2)–HttpServerCodec》
《facebook/swift:构建thrift http server(3)–CORS跨域》
《facebook/swift:构建thrift http server(4)–ThriftXHRDecoder,ThriftXHREncoder》