說起架構，分為兩塊，乙個是軟體層次的**架構，另外乙個是硬體層次的系統架構。軟體層次的，模組劃分、**重構及業務層的架構為主。系統層次的，以網路、部署、伺服器集群為主。軟體層次的架構，在於前期**研發。硬體層次的系統架構，在於後期的伺服器部署上線。今天的內容主要偏向於遊戲領域的系統架構。
談起系統架構，無外乎就那些技術，什麼負載均衡啊，什麼資料庫垂直、水平分割槽啊、前端/後端快取、nosql什麼什麼的。幾乎任何行業裡面的架構，都離不開這些技術。今天要說的是遊戲架構，我不想再費勁的介紹那些傳統的架構技術，也沒什麼新鮮感。要說某個領域的架構，我覺得這個領域相比其他領域的架構有什麼鮮明特點，這才是最有價值的部分。
遊戲架構相比傳統b/s、c/s應用架構，鮮明特點在於：
遊戲架構特有的「分割槽」概念。
為了解決玩家的延時，傳統idc機房的遊戲架構，一般分為電信和聯通兩個大的分割槽。然後在兩個大分割槽中，又分類似「北京分割槽」「上海分割槽」「江蘇分割槽」等等。這種邏輯層次的按照地域的分割槽，其實在物理層次，是把伺服器對應部署在不同地域的機房中。這樣部署，也主要是為了解決遊戲玩家的延遲性。打個比方，北京電信的玩家登陸上海電信的伺服器，延時肯定是很高的。
遊戲分割槽的架構特性，決定了遊戲的架構一般不是分布式集群的架構（以下簡稱為集群架構）。身為玩家的你們都知道，比如我是北京電信的玩家，然後登陸上海電信的遊戲伺服器，這個時候，一般你都會發現你的遊戲角色的屬性都會回歸你剛註冊的時候（針對絕大數遊戲，當然有些遊戲也不是這樣設計的，這裡就不做過多介紹）。從這點我們可以判斷出，不同地域的遊戲部署，應用層和資料庫都是獨立分開部署的。而我們傳統的分布式集群架構，不管你從北京登陸，還是從上海登陸，你的使用者資料都是唯一的。因為這種集群架構，底層資料庫並沒有獨立開。
遊戲分割槽的架構特性，決定了遊戲架構的擴充套件性非常好。所謂的資料庫垂直分割槽、水平分割槽，又比如mysql的主從讀寫分離，這種資料庫層次的擴充套件，是很繁瑣的，一般都是應用於我們的集群架構中。而我們的遊戲架構呢，簡單點的話，我們只需要一台伺服器部署應用，一台伺服器部署資料庫即可。如果使用者量增加，比如上海電信的使用者量增加，一台伺服器和一台資料庫扛不住的時候。這個時候，我們簡單增加乙個區即可，再獨立部署一台應用和一台資料庫即可。因而就有了上海電信一區，上海電信二區這樣的區分了。
傳統idc 機房部署遊戲，地域之間訪問的延時性，因而就形成了這種很強的地域性分割槽。如果我們通過雲來部署，這種分割槽上有什麼區別呢？我們知道，雲主機網路都是bgp（多家運營商接入），從而就有效解決了傳統機房部署遇到的問題——不同地域不同運營商的玩家訪問的延時問題。所以我們通過雲來部署的遊戲應用的分割槽，就沒有北京電信分割槽、上海電信分割槽之說了。我們就可以簡單的叫為一區、二區、三區等，然後我們還可以為不同區取個好聽的別名。比如一區之風雲再起，二區之逐鹿中原，三區之雄霸天下。
分割槽只是遊戲行業乙個很突出的特點，幾乎所有型別的遊戲都具有這個特點。但不同遊戲的型別，在架構及技術上是有所區別的。遊戲按照應用劃分，主要分為頁遊、手遊和端遊。但頁遊、手遊和端遊具體在架構及技術上有什麼區別呢？
頁遊、手遊、端遊的技術區別：
頁遊、手遊、端遊後端的技術的話，可能都相差不多，主要技術區別在於前端。頁遊的話，採用html5、flash等前端技術。而手遊，如果是android系統的話，採用j**a技術。如果是ios，主要採用object c。那端遊呢，當然c++是首先了。
遊戲引擎架構選摘之第五章 遊戲支援系統
每個遊戲都需要一些底層支援，以管理一些例行卻關鍵的任務。例如啟動及終止引擎 訪問 多個 檔案系統 訪問各種不同的資產型別 網格 紋理 動畫 音訊等 以及為遊戲團隊提供除錯工具。5.1 子系統的啟動和終止 遊戲引擎是複雜軟體，由多個互相合作的子系統結合而成。當引擎啟動時，必須一次配置及初始化每個子系統...
遊戲引擎架構
大綱 什麼是架構？軟體架構是乙個系統的草圖，軟體架構描述的物件是直接構成系統的抽象元件。各個元件之間的連線則明確和相對細緻地描述元件之間的通訊。在實現階段，這些抽象元件被細化為實際的元件，比如具體某個類或物件。在物件導向領域中，元件之間的連線通常用介面來實現。什麼是遊戲引擎？引擎 定義元件最重要的是...
原創 遊戲雲間之一 彈性擴充套件
文 肖凱 前言雲計算從幾年前的概念炒作到今天各種公私有云的蓬勃發展，越來越多的使用者開始接觸並嘗試將雲作為業務運營的載體，已有不少敢於嘗鮮的使用者體驗了雲計算所帶來的靈活性和成本優勢。我自己也從最初對雲的模糊認識到嘗鮮，再到大規模的使用雲平台，有很多感觸，雲計算技術和平台目前也處於逐步完善和穩定中，...