緣起
在網絡編程中，經常出現如下場景：編寫特定邏輯服務器，該邏輯服務器依賴於后端的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