异步服务器框架设计

缘起

在网络编程中，经常出现如下场景：编写特定逻辑服务器，该逻辑服务器依赖于后端的N种服务器。比如需要获取N种服务数据，或者需要N个步骤。对于这样的应用，同步调用将导致逻辑服务器的性能极低，异步调用是首选。问题：如何抽象通用的异步服务器网络框架，降低编写特定逻辑服务器的工作量？

分析

要抽象这样的异步服务器网络框架，需要处理如下问题：

1）session管理(通讯管理和数据管理)；

2）超时处理；

3）异常处理；

4）状态管理(流程抽象)。

为了简化分析，从依赖单个后端服务器的情景开始分析。对于只需一次网络调用的逻辑服务，只需要考虑：session管理、超时处理、异常处理，session数据管理+简单的定时器+超时回调函数 即可满足该需求。这种服务器状态简单: 正常流程：发包、回包、获取请求数据、处理流程、返回用户请求； 异常流程： 超时、获取请求数据、处理流程、返回用户请求。

对于需要N个网络调用的逻辑服务，其每个网络调用也可以简化成上述单次网络调用的流程。问题是如何组织这N个网络调用，如何管理由这N个调用组成的各种状态？

异步服务器框架设计思路

方法一：抽象状态，利用“状态 <=> 回调函数 映射表”实现各种状态和动作间的转换关系。这种方法并不好，原因在于全局状态过多，不利于抽象。

方法二：State模式。封装每一个网络调用成Context(维护每个调用自身的状态)，每个Context拥有如下统一动作(接口): 发包函数、回包处理函数、超时处理函数。通过组合Context实现对状态的管理。若N个调用不存在时序关系，则将每个调用Context组成一个更大的Context，该Context代表一个更大的状态。当所有的子Context调用完成后，则该Context完成，无状态转移。若N个调用存在时序关系，则按照调用时序，将各个Context组成一个状态转移链，依次处理各个Context并转移到下一个Context，当最后一个Context完成后，则整个请求完成。

参考

设计模式学习（五）：行为型模式

敏捷软件开发              2003