游戲服務器非功能性需求
靈活性：支持可替換的通信協議；可替換的持久化設備（如數據庫）；可替換的緩存設備（如 memcached/redis）；以靜態庫和頭文件的方式發布，不對使用者代碼做過多的要求。游戲的運營環境比較復雜，特別是在不同的項目之間，可能會使用不同的數據庫、不同的通信協議。但是游戲本身業務邏輯很多都是基于對象模型去設計的，所以應該有一層能夠基于“對象”來抽象所有這些底層功能的模型。這樣才能讓多個不同的游戲，都基于一套底層進行開發。
部署便利性：支持靈活的配置文件、命令行參數、環境變量的引用；支持單獨進程啟動，而無須依賴數據庫、消息隊列中間件等設施。一般游戲都會有至少三套運行環境，包括一個開發環境、一個內測環境、一個外測或運營環境。一個游戲的版本更新，往往需要更新多個環境。所以如何能盡量簡化部署就成為一個很重要的問題。我認為一個好的服務器端框架，應該能讓這個服務器端程序，在無配置、無依賴的情況下獨立啟動，以符合在開發、測試、演示環境下快速部署。并且能很簡單的通過配置文件、或者命令行參數的不同，在集群化下的外部測試或者運營環境下啟動。
性能：很多游戲服務器，都會使用異步非阻塞的方式來編程。因為異步非阻塞可以很好的提高服務器的吞吐量，而且可以很明確的控制多個用戶任務并發下的代碼執行順序，從而避免多線程鎖之類的復雜問題。所以這個框架我也希望是以異步非阻塞作為基本的并發模型。這樣做還有另外一個好處，就是可以手工的控制具體的進程，充分利用多核 CPU 服務器的性能。當然異步代碼可讀性因為大量的回調函數，會變得很難閱讀，幸好我們還可以用“協程”來改善這個問題。
擴展性：支持游戲服務器之間的通信，進程狀態管理，類似 SOA 的集群管理。自動容災和自動擴容，其實關鍵點是服務進程的狀態同步和管理。我希望一個通用的底層，可以把所有的游戲服務器間調用，都通過一個統一的集權管理模型管理起來，這樣就可以不再每個項目去關心集群間通信、尋址等問題。【艾娜】