謝邀，手遊頁遊和端遊的伺服端本質上沒區別，區別的是遊戲型別。
型別1：卡牌、跑酷等弱互動伺服端
卡牌跑酷類因為互動弱，玩家和玩家之間不需要即時面對面PK，打一下對方的離線數據，計算下排行榜，買賣下道具即可，所以實作往往使用簡單的 HTTP伺服器：
登入時可以使用非對稱加密（RSA, DH），伺服器根據客戶端uid，當前時間戳還有伺服端私鑰，計算哈希得到的加密 key 並行送給客戶端。之後雙方都用 HTTP通訊，並用那個key進行RC4加密。客戶端收到key和時間戳後保存在記憶體，用於之後通訊，伺服端不需要保存 key，因為每次都可以根據客戶端傳上來的 uid 和 時間戳 以及伺服端自己的私鑰計算得到。用模仿 TLS的行為，來保證多次 HTTP請求間的客戶端身份，並透過時間戳保證同一人兩次登入金鑰不同。
每局開始時，存取一下，請求一下關卡數據，玩完了又送出一下，驗算一下是否合法，獲得什麽獎勵，資料庫用單台 MySQL或者 MongoDB即可，後端的 Redis做緩存（可選）。如果要實作通知，那麽讓客戶端定時15秒輪詢一下伺服器，如果有訊息就取下來，如果沒訊息可以逐步放長輪詢時間，比如30秒；如果有訊息，就縮短輪詢時間到10秒，5秒，即便兩人聊天，延遲也能自適應。
此類伺服器用來實作一款三國類策略或者卡牌及酷跑的遊戲已經綽綽有余，這類遊戲因為邏輯簡單，玩家之間互動不強，使用 HTTP來開發的話，開發速度快，偵錯只需要一個瀏覽器就可以把邏輯偵錯清楚了。
型別2：第一代遊戲伺服器 1978
1978年，英國著名的財經學校University of Essex的學生 Roy Trubshaw編寫了世界上第一個MUD程式【MUD1】，在University of Essex於1980年接入 ARPANET之後加入了不少外部的玩家，甚至包括國外的玩家。【MUD1】程式的原始碼在 ARPANET共享之後出現了眾多的改編版本，至此MUD才在全世界廣泛流行起來。不斷完善的 MUD1的基礎上產生了開源的 MudOS（1991），成為眾多網遊的鼻祖：
MUDOS采用 C語言開發，因為玩家和玩家之間有比較強的互動（聊天，交易，PK），MUDOS使用單執行緒無阻塞套接字來服務所有玩家，所有玩家的請求都發到同一個執行緒去處理，主執行緒每隔1秒鐘更新一次所有物件（網路收發，更新物件狀態機，處理超時，重新整理地圖，重新整理NPC）。
遊戲世界采用房間的形式組織起來，每個房間有東南西北四個方向可以移動到下一個房間，由於歐美最早的網遊都是地牢迷宮形式的，因此場景的基本單位被成為 「房間」。MUDOS使用一門稱為LPC的手稿語言來描述整個世界（包括房間拓撲，配置，NPC，以及各種劇情）。遊戲裏面的高級玩家（巫師），可以不斷的透過修改指令碼來為遊戲添加房間以及增加劇情。早年 MUD1上線時只有17個房間，Roy Trubshaw畢業以後交給他的師弟 Richard Battle，在 Richard Battle手上，不斷的添加各種玩法到一百多個房間，終於讓 MUD發揚光大。
使用者使用 Telnet之類的客戶端用 Tcp協定連線到 MUDOS上，使用純文字進行遊戲，每條指令用回車進行分割。比如 1995年國內第一款 MUD遊戲【俠客行】，你敲入："go east"，遊戲就會提示你：「後花園 - 這裏是歸雲莊的後花園，種滿了花草，幾個莊丁正在澆花。此地乃是含羞草生長之地。這裏唯一的出口是 north。這裏有：花待 阿牧（A mu），還有二位莊丁（Zhuang Ding）」，然後你繼續用文字操作，檢視阿牧的資訊：「look a mu」，系統提示：「花待 阿牧（A mu）他是陸乘風的弟子，受命在此看管含羞草。他看起來三十多歲，生得眉清目秀，端正大方，一表人才。他的武藝看上去【不是很高】，出手似乎【極輕】」。然後你可以選擇擊敗他獲得含羞草，但是你吃了含羞草卻又可能會中毒死亡。在早期網上資源貧乏的時候，這樣的遊戲有很強的代入感。
使用者數據保存在檔中，每個使用者登入時，從文字檔案裏把使用者的數據全部載入進來，操作全部在記憶體裏面進行，無需馬上刷回磁盤。使用者結束了，或者每隔5分鐘檢查到數據改動了，都會保存會磁盤。這樣的系統在當時每台伺服器承載個4000人同時遊戲，不是特別大的問題。從1991年的 MUDOS釋出後，全球各地都在為他改進，擴充，結束新版本，隨著 Windows圖形機能的增強。1997遊戲【UO】在 MUDOS的基礎上為角色增加的x,y座標，為每個房間增加了地圖，並且為每個角色增加了動畫，形成了第一代的圖形網路遊戲。
因為遊戲內容基本可以透過 LPC指令碼進行客製，所以MUDOS也成為名副其實的第一款伺服端引擎，引擎一次性開發出來，然後制作不同遊戲內容。後續國內的【萬王之王】等遊戲，很多都是跟【UO】一樣，直接在 MUDOS上進行二次開發，加入房間的地圖還有角色的座標等要素，該架構一直為國內的第一代 MMORPG提供了穩固的支持，直到 2003年，還有遊戲基於 MUDOS開發。
雖然後面圖形化增加了很多東西，但是這些MMORPG後端的本質還是 MUDOS。隨著遊戲內容的越來越復雜，架構變得越來越吃不消了，各種負載問題慢慢浮上水面，於是有了我們的第二代遊戲伺服器。
型別3：第二代遊戲伺服器 2003
2000年後，網遊已經脫離最初的文字MUD，進入全面圖形化年代。最先承受不住的其實是很多小檔，使用者上下線，頻繁的讀取寫入使用者數據，導致負載越來越大。隨著線上人數的增加和遊戲數據的增加，伺服器變得不抗重負。同時早期 EXT磁盤分區比較脆弱，稍微停電，容易發生大面積數據遺失。因此第一步就是拆分檔儲存到資料庫去。
此時遊戲伺服端已經脫離陳舊的 MUDOS體系，各個公司在參考 MUDOS結構的情況下，開始自己用 C在重新開發自己的遊戲伺服端。並且指令碼也拋棄了 LPC，采用擴充套件性更好的 Python或者 Lua來代替。由於主邏輯使用單執行緒模型，隨著遊戲內容的增加，傳統單伺服器的結構進一步成為瓶頸。於是有人開始拆分遊戲世界，變為下面的模型：
遊戲伺服器壓力拆分後得意緩解，但是兩台遊戲伺服器同時存取資料庫，大量重復存取，大量數據交換，使得資料庫成為下一個瓶頸。於是形成了資料庫前端代理（DB Proxy），遊戲伺服器不直接存取資料庫而是存取代理，再有代理存取資料庫，同時提供記憶體級別的cache。早年 MySQL4之前沒有提供儲存過程，這個前端代理一般和 MySQL跑在同一台上，它轉化遊戲伺服器發過來的高級數據操作指令，拆分成具體的資料庫操作，一定程度上代替了儲存過程：
但是這樣的結構並沒有持續太長時間，因為玩家切換場景經常要切換連線，中間的狀態容易錯亂。而且遊戲伺服器多了以後，相互之間數據互動又會變得比較麻煩，於是人們拆分了網路功能，獨立出一個閘道器服務 Gate（有的地方叫 Session，有的地方叫 LinkSvr之類的，名字不同而已）：
把網路功能單獨提取出來，讓使用者統一去連線一個閘道器伺服器，再有閘道器伺服器轉發數據到後端遊戲伺服器。而遊戲伺服器之間數據交換也統一連線到網管進行交換。這樣型別的伺服器基本能穩定的為玩家提供遊戲服務，一台閘道器服務1-2萬人，後面的遊戲伺服器每台服務5k-1w，依遊戲型別和復雜度不同而已，圖中隱藏了很多不重要的伺服器，如登入和管理。這是目前套用最廣的一個模型，到今天任然很多新計畫會才用這樣的結構來搭建。
人都是有慣性的，按照先前的經驗，似乎把 MUDOS拆分的越開效能越好。於是大家繼續想，閘道器可以拆分呀，基礎服務如聊天交易，可以拆分呀，還可以提供web介面，資料庫可以拆分呀，於是有了下面的模型：
這樣的模型好用麽？確實有成功遊戲使用類似這樣的架構，並且發揮了它的效能優勢，比如一些大型 MMORPG。但是有兩個挑戰：每增加一級伺服器，狀態機復雜度可能會翻倍，導致研發和找bug的成本上升；並且對開發組挑戰比較大，一旦計畫時間吃緊，開發人員經驗不足，很容易弄掛。
比如我見過某上海一線遊戲公司的一個 RPG上來就要上這樣的架構，我看了下他們團隊成員的經驗，問了下他們的上線日期，勸他們用前面稍微簡單一點的模型。人家自信得很，認為有成功計畫是這麽做的，他們也要這麽做，自己很想實作一套。於是他們義無反顧的開始編碼，計畫做了一年多，然後，就沒有然後了。
現今在遊戲成功率不高的情況下，一開始上一套比較復雜的架構需要考慮投資報酬率，比如你的遊戲上線半年內 PCU會去到多少？如果一個 APRG遊戲，每組伺服器5千人都到不了的話，那麽選擇一套更為貼近實際情況的結構更為經濟。即使後面你的計畫真的超過5千人朝著1萬人目標奔的話，相信那個時候你的計畫已經掙大錢了 ，你數著錢加著班去逐步叠代，一次次拆分它，相信心裏也是樂開花的。
上面這些型別基本都是從拆分 MUDOS開始，將 MUDOS中的各個部件從單機一步步拆成分布式。雖然今天任然很多新計畫在用上面某一種類似的結構，或者自己又做了其他熱點模組的拆分。因為他們本質上都是對 MUDOS的分解，故將他們歸納為第二代遊戲伺服器。
型別4：第三代遊戲伺服器 2007
從魔獸世界開始無縫世界地圖已經深入人心，比較以往遊戲玩家走個幾步還需要切換場景，每次切換就要等待 LOADING個幾十秒是一件十分破壞遊戲體驗的事情。於是對於 2005年以後的大型 MMORPG來說，無縫地圖已成為一個標準配置。比較以往按照地圖來切割遊戲而言，無縫世界並不存在一塊地圖上面的人有且只由一台伺服器處理了：
每台 Node伺服器用來管理一塊地圖區域，由 NodeMaster（NM）來為他們提供總體管理。更高層次的 World則提供大陸級別的管理服務。這裏省略若幹細節伺服器，比如傳統資料庫前端，登入伺服器，日誌和監控等，統統用 ADMIN概括。在這樣的結構下，玩家從一塊區域走向另外一塊區域需要簡單處理一下：
玩家1完全由節點A控制，玩家3完全由節點B控制。而處在兩個節點邊緣的2號玩家，則同時由A和B提供服務。玩家2從A移動到B的過程中，會同時向A請求左邊的情況，並向B請求右邊的情況。但是此時玩家2還是屬於A管理。直到玩家2徹底離開AB邊界很遠，才徹底交由B管理。按照這樣的邏輯將世界地圖分割為一塊一塊的區域，交由不同的 Node去管理。
對於一個 Node所負責的區域，地理上沒必要連線在一起，比如大陸的四周邊緣部份和高山部份的區塊人比較少，可以統一交給一個Node去管理，而這些區塊在地理上並沒有聯系在一起的必要性。一個 Node到底管理哪些區塊，可以根據遊戲即時執行的負載情況，定時維護的時候進行更改 NodeMaster 上面的配置。
於是碰到第一個問題是很多 Node伺服器需要和玩家進行通訊，需要問管理伺服器特定UID為多少的玩家到底在哪台 Gate上，以前按場景切割的伺服器這個問題不大，問了一次以後就可以緩存起來了，但是現在伺服器種類增加不少，玩家又會飄來飄去，按UID尋找玩家比較麻煩；另外一方面 GATE需要動態根據座標計算和哪些 Node通訊，導致邏輯越來越厚，於是把：「使用者物件」從負責連線管理的 GATE中切割出來勢在必行於是有了下面的模型：
閘道器伺服器再次退回到精簡的網路轉發功能，而使用者邏輯則由按照 UID劃分的 OBJ伺服器來承擔，GATE是按照網路接入時的負載來分布，而 OBJ則是按照資源的編號（UID）來分布，這樣和一個使用者通訊直接根據 UID計算出 OBJ伺服器編號發送數據即可。而新獨立出來的 OBJ則提供了更多高層次的服務：
整個伺服器主體分為三層以後，NODE專註場景，OBJ專註玩家物件，GATE專註網路。這樣的模型在無縫場景伺服器中得到廣泛的套用。但是隨著時間的推移，負載問題也越來越明顯，做個活動，遠來不活躍的區域變得十分活躍，靠每周維護來調整還是比較笨重的，於是有了動態負載均衡。
動態負載均衡有兩種方法，第一種是按照負載，由 Node Master 定時動態移動修改一下各個 Node的邊界，而不同的玩家物件按照先前的方法從一台 Node上遷移到另外一台 Node上：
圖11 動態負載均衡
這樣 Node Master定時尋找地圖上的熱點區域，計算新的場景切割方式，然後告訴其他伺服器開始調整，具體處理方式還是和上面物件跨越邊界移動的方法一樣。
但是上面這種方式實作相對復雜一些，於是人們設計出了更為簡單直接的一種新方法：
圖12 基於網格的動態負載均衡
還是將地圖按照標準尺寸均勻切割成靜態的網格，每個格子由一個具體的Node負責，但是根據負載情況，能夠即時的遷移到其他 Node上。在遷移分為三個階段：準備，切換，完成。三個狀態由Node Master負責維護。準備階段新的 Node開始同步老 Node上面該網格的數據，完成後告訴NM；NM確認OK後同時通知新舊 Node完成切換。完成切換後，如果 Obj伺服器還在和老的 Node進行通訊，老的 Node將會對它進行糾正，得到糾正的 OBJ將修正自己的狀態，和新的 Node進行通訊。
很多無縫動態負載均衡的伺服端宣稱自己支持無限的人數，但不意味著 MMORPG遊戲的人數上限真的可以無限擴充，因為這樣的體系會受制於網路頻寬和客戶端效能。頻寬決定了同一個區域最大廣播上限，而客戶端效能決定了同一個螢幕到底可以繪制多少個角色。
從無縫地圖引入了分布式物件模型開始，已經完全脫離 MUDOS體系，成為一種新的伺服端模型。又由於動態負載均衡的引入，讓無縫伺服器如虎添翼，容納著超過上一代遊戲伺服器數倍的人數上限，並提供了更好的遊戲體驗，我們稱其為第三代遊戲伺服端架構。網遊以大型多人角色扮演為開端，RPG網遊在相當長的時間裏一度占據90%以上，使得基於 MMORPG的伺服端架構得到了蓬勃的發展，然而隨著玩家對RPG的疲憊，各種非MMORPG遊戲如雨後春筍般的出現在人們眼前，受到市場的歡迎。
型別5：戰網遊戲伺服器
經典戰網伺服端和 RPG遊戲有兩個區別：RPG是分區分服的，北京區的使用者和廣州區的使用者老死不相往來。而戰網，雖然每局遊戲一般都是 8人以內，但全國只有一套伺服器，所有的玩家都可以在一起遊戲，而玩家和玩家之使用 P2P的方式連線在一起，組成一局遊戲：
玩家透過 Match Making 伺服器使用：建立、加入、自動匹配、邀請 等方式組成一局遊戲。伺服器會選擇一個人做 Host，其他人 P2P連線到做主的玩家上來。STUN是幫助玩家之間建立 P2P的牽引伺服器，而由於 P2P聯通情況大概只有 75%，實在聯不通的玩家會透過 Forward進行轉發。
大量的連線對戰，體育競技遊戲采用類似的結構。P2P有網狀模型（所有玩家互相連線），和星狀模型（所有玩家連線一個主玩家）。復雜的遊戲狀態在網狀模型下難以形成一致，因此星狀P2P模型經受住了歷史的考驗。除去遊戲數據，支持語音的戰網系統也會將所有人的語音數據發送到做主的那個玩家機器上，透過混音去重再編碼的方式返回給所有使用者。
戰網類遊戲，以競技、體育、動作等型別的遊戲為主，較慢節奏的 RPG（包括ARPG）有本質上的區別，而激烈的遊戲過程必然帶來到較 RPG復雜的多的同步策略，這樣的同步機制往往帶來的是很多遊戲結果由客戶端直接計算得出，那在到處都是破解的今天，如何保證遊戲結果的公正呢？
主要方法就是投票法，所有客戶端都會獨立計算，然後傳遞給伺服器。如果結果相同就更新記錄，如果結果不一致，會采取類似投票的方式確定最終結果。同時記錄本劇遊戲的所有輸入，在可能的情況下，找另外閑散的遊戲客戶端驗算整局遊戲是否為該結果。並且記錄經常有作弊嫌疑的使用者，供營運人員封號時參考。
型別7：休閑遊戲伺服器
休閑遊戲同戰網伺服器類似，都是全區架構，不同的是有房間伺服器，還有具體的遊戲伺服器，遊戲主體不再以玩家 P2P進行，而是連線到專門的遊戲伺服器處理：
和戰網一樣的全區架構，使用者數據不能象分區的 RPG那樣一次性load到記憶體，然後在記憶體裏面直接修改。全區架構下，為了應對一個使用者同時玩幾個遊戲，使用者數據需要區分基本數據和不同的遊戲數據，而遊戲數據又需要區分積分數據、和文件數據。勝平負之類的積分可以直接送出增量修改，而更為普遍的文件類數據則需要提供讀寫令牌，寫令牌只有一塊，讀令牌有很多塊。同帳號同一個遊戲同時在兩台電腦上玩時，最先開始的那個遊戲獲得寫令牌，可以操作任意的使用者數據。而後開始的那個遊戲除了可以送出勝平負積分的增量改變外，對使用者數據采用唯讀的方式，保證遊戲能執行下去，但是會提示使用者，遊戲數據釘選。
型別8：現代動作類網遊
從早期的南韓動作遊戲開始，傳統的戰網動作類遊戲和 RPG遊戲開始嘗試融合。單純的動作遊戲玩家容易疲倦，留存也沒有 RPG那麽高；而單純 RPG戰鬥卻又慢節奏的乏味，無法滿足很多玩家激烈對抗的期望，於是二者開始融合成為新一代的：動作 + 城鎮 模式。玩家在城鎮中聚集，然後以開副本的方式幾個人出去以動作遊戲的玩法來完成各種 RPG任務。本質就是一套 RPG伺服端+副本伺服端。由於每次副本時人物可以控制在8人以內，因此可以獲得更為即時的遊戲體驗，讓玩家玩的更加爽快。
說了那麽多的遊戲伺服器型別，其實也差不多了，剩下的型別大家拼湊一下其實也就是這個樣子而已。遊戲伺服端經歷了那麽多結構上的變遷，內部開發模式是否依然不變？究竟是繼續延續傳統的開發方式？還是有了更多突破性的方法？經歷那麽多次架構變遷，後面是否有共通的邏輯？未來的發展還會存在哪些困難？遊戲伺服端開發如何達到最終的彼岸？請看下節：技術的演進。
技術的演進
（歡迎加入「遊戲伺服端架構交流」 QQ群 457576286，共同討論相關問題）
（待續）
