一、服務器設計問題
1、認證問題
集羣設計了存儲，日誌，計算，網關-層，理論上這些層可以隨着業務量增長無限擴展。
因此我們在整體框架的設計上，自然不會把認證服獨立出來，這個業務可以在網關直接完成；
在實際運營過程中，我們會接入第三方渠道，渠道會要求認證服不能隨版本維護而停止運行，必須一直啓動並運行着；
在我們框架下如果一個渠道的服務器，需要獨立在另一個集羣中，我們就要實現充值轉發以及最近登錄等消息的歸併處理。
在一個項目中提出了臨時解決方案，我們擴展了一箇中控，通過它來做轉發；
而我們爲此得出的結論是認證服確實不能少（因爲之前做端遊沒有第三方的很多要求，所以認證服獨立出來發現多餘了）。
它需要包含：賬號信息管理，充值，認證。
2、場景問題
在我們的集羣框架下，MMORPG的場景應該在網關層，它的推送密集度比策略類場景多太多；
而公司另兩款策略和卡牌遊戲的大場景因大數據檢測較多，通信不密集所以設計在了計算層。
而另一款回合制，採用的是組合模式分線運行，所以場景也在不同線不同的網關節點上。
設計注意：
a、場景必須自己維護場景裏的數據，場景推動及AI檢測的運算非常密集；
b、場景推動中絕對不能存在同步通信業務，會降低幀率；
c、場景事件要合併壓縮後在幀尾推送。
3、結算問題
結算是一個持續過程，有10分鐘乃至更長時間運算，業務應當放在計算層。
4、緩存問題
緩存數據有，玩家數據，各大系統，服務器數據，這裏越把分層帶來的觀察性顯示得更重要。
通常玩家數據都是跟着會話走自然在網關層，系統數據基本都在計算層也不排除直接在存儲層的，
服務器數據便理所當然存儲層+全局緩存了；當然還有常規功能，不過也都是網關的瞬時業務沒有緩存可言。
二、業務數據分離和融合
我們理想是，存儲->計算->網關；自上而下，相同類型節點之間不應該業務串行。
情況一：
數據和業務結合在一起，以服務器爲單位，把玩家及該服務器的業務結合到一個節點。
目的，減少跨節點通信，提高運行效率，但如果節點掛了hash環出問題，會造成服務器之間理想的共享環境異常。
情況二：
如果，業務和數據不能在一起，那就要儘量減少高階訪問，唯一的方式就是緩存。
侷限功能的跨節點通信，如全局業務就只有大地圖和全局定時器的策略遊戲《異星帝國》，直接放在計算層，其他就在網關層。
我們產生業務事件無非只有，場景推動產生、玩家行爲、活動推動、系統結算。
如同：場景操作玩家數據，玩家數據在數據庫和會話進程，都在不同的節點的情況下你該怎麼做？
1、服務器hash歸併到一個節點，數據訪問透明化。
2、業務節點緩存大部分數據，用於系統操作，減少數據跨層訪問。
