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

红太狼 2022-02-04 23:51 177阅读 0赞

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

# 背景说明 #

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

## Node.js方案 ##

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

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

1.  开发工作量更大  
    [《Javascript Tutorial》][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][facebook_swift]定义的接口，我的facelog项目基于[facebook/swift][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][facebook_swift]实现一个XHR服务，让浏览能直接访问thrift服务接口。  
对，这就是我的最理想的方案。  
太晚了，写不下去了。  
请看我的下一篇博客。

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

[facebook_swift]: https://github.com/facebookarchive/swift
[facelog]: https://gitee.com/l0km/facelog
[thrift]: https://github.com/apache/thrift
[Javascript Tutorial]: http://thrift.apache.org/tutorial/js
[org.apache.thrift.server.TServlet]: https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/server/TServlet.java
[facebook_swift_thrift http server_2_HttpServerCodec]: https://blog.csdn.net/10km/article/details/89810011
[facebook_swift_thrift http server_3_CORS]: https://blog.csdn.net/10km/article/details/89816763
[facebook_swift_thrift http server_4_ThriftXHRDecoder_ThriftXHREncoder]: https://blog.csdn.net/10km/article/details/89819201