为什么会想通过Netty构建一个HTTP代理服务器？这也是笔者发表这篇文章的目的所在。
其主要还是源于解决在日常开发测试过程中，一直困扰测试同学很久的一个问题，现在我就来具体阐述一下这个问题。
在日常开发测试过程中，为了确保上线项目的万无一失，集成测试通常有部署，测试环境和回归环境这两套环境。开发人员根据需求编写代码模块，自测通过之后，由测试的同学更新到测试环境，进行测试。如果测试通过，确定项目具备上线条件，后续会在回归环境，进行回归测试。回归验证通过的项目，才具备上线条件。
由于模块的复杂性和多样性，我们系统要跟外系统进行一些数据的交互，这通常是通过HTTP协议方式完成的。现在由于某些条件的限制，通常只有测试环境的网络和端口是和外系统是打通的，回归环境的这块网络链路是关闭的。这样就产生了一个很尴尬的问题：如果一个模块有跟外系统进行交互，回归环境是不具备回归条件的，这样就要测试的同学，额外把模块更新到测试环境来验证，这样不仅耗时耗力。并且由于测试环境和回归环境系统数据的差异，往往可能导致项目的潜在风险没有被及时地发现。
现在迫切希望有一个HTTP代理服务器，能够路由回归环境的请求到测试环境。更进一步地，如果能根据请求报文的某些关键字来过滤，决定最终路由的地址，这个当然是最好了。
基于这些因素，考虑到HTTP代理服务器的主要用途是转发URL请求，可选的方案有很多种。比如Apache、Nginx等等。但是最终都没有被采用，主要基于以下几点考虑：
Apache服务器不能根据某些指定的关键字过滤转发URL请求，只能做简单的代理转发。
Nginx相比Aapche服务器单纯进行请求转发而言，通过OpenResty（），可以把lua解析器内嵌到Nginx，这样可以编写lua脚本的关键字过滤规则，但是要测试同学短时间内学会配置不太现实。
有没有通过简单的几个配置，就可以达到目的的可行方案呢？
我首先想到了使用Netty这个NIO框架，来实现一个轻量级的HTTP代理转发服务器，同时只要简单地配置过滤规则，就可以实现请求的规则路由。
本文要求你熟悉Netty网络框架的工作流程，基本原理。有兴趣的朋友，可以认真研读一下《Netty in Action》这本书，对提高Netty的功力有很大帮助。
言归正传，下面是这个HTTP代理转发服务器的工作流程图：
这里我简单描述一下：
首先是Netty的服务端连接器（Acceptor）线程接收到HTTP请求，然后会把这个请求放入后端Netty专门负责处理I/O操作的线程池中。这个也是Netty经典的主从Reactor多线程模型的应用。
I/O处理线程先对HTTP请求，调用HttpRequestDecoder解码器进行解码。
HttpRequestDecoder把解码的结果，通知给路由规则计算的核心模块（GatewayServerHandler），核心模块根据配置加上请求报文中的关键字，计算出要转发的URL地址。
通过HTTP POST方式把请求，转发给计算出来的URL地址。
获取HTTP POST的获得到的应答结果。
然后通过HttpResponseEncoder编码器，把应答结果进行HTTP编码，最后透传给调用方。
流程描述很简单，现在关键是，如何设计关键字路由规则配置模块。
我是通过属性配置文件（.properties）方式来实现的，主要有两个配置文件。
netty-gateway.properties配置文件，主要是用来描述URL中的路径、以及其没有和请求URL路径匹配成功时，默认转发的URL地址。
配置文件的配置参考说明：
#配置说明参考： #netty-gateway.config1.serverPath ==> URL路径关键字。 #netty-gateway.config1.defaultAddr ==> 请求报文中的关键字没有匹配成功时，默认转发的URL地址。 #config的数字后缀顺序递增即可。 netty-gateway.config1.serverPath=fcgi-bin/UIG_SFC_186 netty-gateway.config1.defaultAddr=http://10.46.158.10:8088/fcgi-bin/UIG_SFC_186 netty-gateway.config2.serverPath=fcgi-bin/BSSP_SFC netty-gateway.config2.defaultAddr=http://10.46.158.10:8089/fcgi-bin/BSSP_SFC