1、要实现的功能
书接上回，本回书我们要完成开放接口平台核心引擎的多Handler支持机制。
如图1所示。
图1 开放接口服务器端架构
2、Filter还是装饰模式
装饰者模式貌似是一个实现的候选，类似Java的I/O实现。
多“装饰”一层，就获得了新的功能，原来的功能还在。
对我现在的应用场景来说，这种实现方式过于复杂了。
相对而言，Filter更简洁。
当前的应用场景对性能是有极高要求的，不适合使用哪怕稍微复杂的模式。
3、Handler接口定义
我的Handler接口定义如下。
public interface Handler {
public void inWay(HttpServletRequest request,HttpServletResponse response);
public void outWay(HttpServletRequest request,HttpServletResponse response);
}更有节操的童鞋会自己定义Request、Response0，甚至Context对象。以便脱离Web容器的限制，进一步实现自己的底层通信协议。
我这里先偷个懒，等有时间了慢慢来。
Handler接口中，inWay方法对应图1左侧的向下箭头，outWay对应右侧的向上箭头。
这样，在同一个Handler定义进、出的逻辑。
对于实现序列化功能的Handler，inWay中实现反序列化，outWay中实现序列化。
对于实现加密功能的Handler，inWay中实现解密，outWay中实现加密。
对于实现压缩功能的Handler，inWay中实现解压缩的逻辑，outWay中实现压缩的逻辑。
这样，当不需要某个Handler的时候，直接去掉就好了。
当然，outWay中可以do nothing。
另外，非常重要的，Handler实现类不可以有自己的属性。Handler实例不能有“状态”。
我们需要Handler是线程安全的。
3、可配置
多个Handler是可配置的，每个Handler链可以服务于一个或多个接口。
在Handler无状态、线程安全的基础上，我们可以采用在每个JVM中Handler单例的方式，避免频繁创建、回收Handler对象的损失。
配置信息可以保存在properties文件中，可以保存在xml中，可以保存在数据中，范例如下：
openapi.handler.keys=surface,encrypt,auth
openapi.handler.surface=cn.hailong.common.openapi.handler.SurfaceHandler
openapi.handler.encrypt=cn.hailong.common.openapi.handler.EncryptHandler
openapi.handler.auth=cn.hailong.common.openapi.handler.AuthHandler配置系统中可能用到的所有Handler，并在系统启动时加载。
在上面的配置中，配置了每个Handler的类名，加载的时候，可以根据类名创建类的实例。
给每个Handler起了一个短名称，便于在配置Handler链的时候引用。
对应的加载代码为：
public class HandlerManager {
/**
* 保存系统中的所有Handler，key为handler短名，value为Handler实例。
*/
private static Map<String, Handler> handlersMap = new ConcurrentHashMap<String, Handler>();
static{
reloadHandlers();
}
public static synchronized void reloadHandlers(){
handlersMap.clear();
logger.info("Open Api Handlers load start ... ");
long begin = System.currentTimeMillis();
Properties props = ConfigManager.getProperties("openapi");
String handlerKeys = props.getProperty("openapi.handler.keys");
logger.debug("loading handlers : "+handlerKeys);
Handler handler = null;
if(!StringUtils.isEmpty(handlerKeys)){
String[] handlerKeyArray = handlerKeys.split(",");
if(handlerKeyArray!=null && handlerKeyArray.length>0){
for (String handlerKey : handlerKeyArray) {
String propertiesKey = "openapi.handler."+handlerKey;
String handlerClassName = props.getProperty(propertiesKey);
if(StringUtils.isEmpty(handlerClassName)){
continue;
}
handlerClassName = handlerClassName.trim();
Class<?> clz = Class.forName(className);
handler = BeanUtil.newInstance(Handler.class,clz);
if(handler!=null){
handlersMap.put(handlerKey,handler);
logger.debug(String.format("handler[%s] loaded : %s ", handlerKey,handler));
}
}
}
}
logger.info("Open Api Handlers load end , time costs "+(System.currentTimeMillis()-begin));
}
/**
*
*/
public static Hanlder get(String shortName){
return handlerMap.get(shortName);
}
}修改了Handler的配置，需要重新加载的时候，也无需重启服务器（在生产环境，这非常重要），再次调用HandlerManager.reloadHandlers()即可。
接下来是Handler链的配置，配置范例如下：
openapi.handler.chain.keys=full,idle
openapi.handler.chain.full=surface,encrypt,auth,traffic,config,validate
openapi.handler.chain.idle=idle,idle,idle,idle,idle加载逻辑与HandlerManager中代码逻辑类似。
4、Handler执行过程
Handler的执行过程如图1所示。
public class HandlerChain {
protected List<Handler> handlersList = null;
protected List<Handler> handlersReversedList = null;
protected Iterator<Handler> inIterator = null;
protected Iterator<Handler> outIterator = null;
public HandlerChain(List<Handler> handlers) {
setHandlers(handlers);
reset();
}
protected void setHandlers(List<Handler> handlers) {
if (handlers == null) {
return;
}
// 正向
this.handlersList = handlers;
// 反向
if (handlersReversedList == null) {
handlersReversedList = new ArrayList<Handler>();
} else {
handlersReversedList.clear();
}
for (int idx = handlers.size() - 1; idx > -1; --idx) {
handlersReversedList.add(handlers.get(idx));
}
}
public void reset() {
if (handlersList != null) {
inIterator = handlersList.iterator();
}
if (handlersReversedList != null) {
outIterator = handlersReversedList.iterator();
}
}
public void inWay(HttpServletRequest request, HttpServletResponse response) {
Handler nextHandler = null;
if (inIterator != null && inIterator.hasNext()) {
nextHandler = inIterator.next();
}
if (nextHandler != null) {
nextHandler.inWay(request, response);
this.inWay(request, response);//递归调用
} else {
logger.debug(String.format("In End Time:%s.",(System.currentTimeMillis() - this.time)));
}
}
public void outWay(HttpServletRequest request, HttpServletResponse response) {
Handler nextHandler = null;
if (outIterator != null && outIterator.hasNext()) {
nextHandler = outIterator.next();
}
if (nextHandler != null) {
nextHandler.outWay(request, response);
this.outWay(request, response);
} else {
logger.debug(String.format("Out End Time:%s.",(System.currentTimeMillis() - this.time)));
}
}
}HandlerChain 是有状态的，对每个请求创建一个实例。
调用 handlerChainInstance.inWay(req,resp)则执行了相应Handler链的所有inWay方法。
调用 handlerChainInstance.outWay(req,resp)则执行了相应Handler链的所有outWay方法。
5、消息格式参考实现
对接口的调用类似对方法的调用，传入参数包括：接口名称、参数值，传出参数可能是返回值，可能是异常消息。
定义如下接口。
interface RpcMessage{
Object getMeta();
/**
* @return 调用接口的名称。
*/
String getMethod();
/**
* @return 传入的参数值。
*/
List<Object> getParams();
/**
* @return 返回值。
*/
Object getResult();
/**
* @return 异常信息。
*/
Object getError();
}Meta中包含可能的调用者信息，授权信息等。
对于这样的数据结构，json-rpc(http://json-rpc.org/wiki/specification)是一个简单易用的序列化方案。
虽然解析效率不高，但json足够简单，作为参考实现是个好选择。在生产环境中，需要有更成熟的考虑。
采用json-rpc作为持久化方案的情况下。
请求信息可能如下所示：
{meta:{token:‘765959559266‘},method:‘getUserInfo‘,params:[‘32899688‘]}返回信息可能如下所示：
{result:{name:‘刘海龙‘,addr:‘人民大学北路‘}}或
{error:{code:‘AUTH_ERR‘,msg:‘Token过期‘}}对于每次请求应该创建一个 RpcMessage 的实例，可以保存在 Request 中，或者 ThreadLocal 中。
6、异常处理
现在需要考虑一个稍复杂的问题。
观察图1，考虑各个环节抛出异常的时候应该如何应对。考虑授权失败，或超出流量控制时应该如何应对。
首先明确一个问题，客户端是按照outWay的配置定制的。
outWay中如果有序列化和加密，客户端就会解密和反序列化。
生产环境采用的序列化方案一般是二进制的，开发环境可能采用JSON或XML。
加解密一般会针对不同用户采用不同的Key。
返回的消息如果没有经过特定格式的序列化或者加密，客户端将无法读取消息。
所以，我们得到的第一个结论是：异常消息也要报所有的Handler的outWay方法走一遍。
接下来，对图1流程中的每个环节逐个考虑。
6.1、inWay过程中的异常
通过如下代码可以捕捉到inWay过程中的异常，并保存到 rpcMessage 实例中。
try{
handlerChainInstance.inWay(req,resp)
}catch(Throwable e){
rpcMessage.addError("PRE_INVOKE_ERR",e.getMessage());
}
接下来，如果inWay中出现了异常，则跳过调用 业务逻辑 对象的代码。直接执行 outWay ，在outWay执行过程中，根据配置，该怎么序列化怎么序列化，该怎么加密怎么加密。
有一种情况是这样的，假如加密需要明确客户身份，才知道用哪个Key，但请求中未包含用户身份信息或者用户身份信息无效，这可怎么办？
为了解决这个问题，按如下两点做：
第一，用户身份标识不要在消息体中传递。否则识别不了身份，用什么Key解密都不知道，读不出来。
第二，身份无效的错误消息，定义特殊代码，明文传。客户端在执行所有Handler之前，先判断是不是这个错误。
6.2、调用业务逻辑过程中发生的异常
这个最简单，捕捉住，放到 rpcMessage 就可以了。
然后该怎么走outWay就怎么走。
6.3、outWay过程中的异常
这个最难处理。
应在开发过程中极力排除，并避免。
万一发生了，比如在加密、压缩过程中异常了，这时候也只能返回预定的消息，告诉调用方：“服务器出错了，客官请联系店小二”。
预定义的消息，根据 Handler链的配置自动生成，代码如下所示。
private static byte[] outWayErrorMessage = null;
outWayErrorMessage = buildResponseErrorMessage(handerList,"POST_ERR","服务器出错了，客官请联系店小二");