中國 div 組件 理想 而且 下單 否則 角度 客戶端遊戲

我們團隊建立伊始，是從原來的Web產品團隊抽調人員組成的，在開發遊戲的過程中，遭遇了慘痛的教訓，在解決這些問題的過程中，本人對遊戲系統和Web系統的本質區別做了深入思考。特通過三篇文章來記錄思考所得，雖然本人沒有大型遊戲經歷，結論難免有偏頗支出，希望對同行有一些價值。 說明：我們遊戲服務器是使用java技術棧來實現的，文中不可避免涉及spring、redis這些技術因素，但不影響其普遍性。 這裏要講遊戲系統的封閉性是對比web系統的開放性，對於從web轉型做遊戲的技術團隊，理解這一點非常關鍵，如果照搬web系統的技術方案和解決問題思路，後果會慘不忍睹。 web系統的特點： 常見的web系統一般是解決現實世界某個特定需求的軟件系統，這個系統是一個復雜業務鏈條中的一個環節，因此它必須能夠與其他環節進行互操作。 以現在最常見的電商平臺為例，思考一下它提供服務的過程中牽涉到的外部環節： 1）瀏覽商品信息 商品信息是從哪來的？一定是相關人員在系統的運行過程中不斷錄入的，在系統上線的時候，我們不可能預知有多少商品，最多預定義一下商品信息的格式 2）下單 這裏就有一個庫存問題，庫存的變化是由商品的供貨方提供的 3）用戶下單支付 填寫好發貨信息後，選擇某種支付方式進行支付，支付服務的提供者是誰？支付寶、微信、銀行等，反正一定是一個第三方平臺。 5）發貨收貨 訂單支付成功後，系統通知商品的供貨方發貨，後續還要從快遞公司拉取物流信息。 真實的情況可能比上面還要復雜得多，這裏要強調的關鍵點是這個系統是開放的，在運行的過程中，需要與用戶、商品供貨方、支付平臺、快遞公司以及相關運營人員不斷交換數據。 這種開放性對技術實現方案產生了極大的影響 1、整個系統被劃分成很多獨立性很高的業務子系統 每個子系統解決各自的問題，這樣有益於降低整個系統的復雜度，方便各個子系統單獨部署和上線。 2、無狀態服務成為最理想方案 數據盡量都放在數據庫或緩存系統裏面，方便各個子系統共享必要的數據，同時由於數據完全獨立於業務邏輯，那麽這些子系統可以很方便地發布、重啟，而不影響在其他業務。 3、對性能相對不敏感 用戶使用web系統對性能要求不是特別高，用戶通過若幹的步驟以達成一個目標，每一個步驟1s以內的延遲是可以接受的。 4、技術標準化 把整個業務鏈放在一起考慮，其規模、復雜性、不可控性是令人恐怖的，需要多個公司、多個團隊參與才能完成開發。因此每個獨立的系統最好符合某種行業標準規範，對外提供標準的接口。進而導致各種標準的技術組件和技術方案層出不窮。 遊戲系統的特點： 遊戲系統是一個和現實世界沒啥關聯的虛擬系統（文化藝術上的關聯對系統的技術實現不會有直接影響，這裏不討論），它試圖構造一個虛擬世界，讓用戶沈浸其中。這個虛擬的世界是基本封閉的，它不與外部世界溝通，遊戲角色的所有活動完全在這個世界內部完成。 從技術角度分析這裏有兩個重要的特點 1）遊戲系統基本不與外部系統交互，所以在運行過程的所有的數據狀態變化都在本系統內部完成，理論上可以一切盡在掌握 2）玩家在這個封閉世界中的活動應該非常的流暢自然，才能有沈浸的感覺，服務器的響應性能必須非常地高。 3）除非單機遊戲，否則玩家與玩家之間的互動非常頻繁，進一步增加了服務器的響應壓力 由此導致了一系列的技術特點： 1）采用有狀態的服務模式 玩家在遊戲中的活動是連續的，他的狀態連續地發生著快速的變化，無狀態的服務系統是無法滿足這樣的性能需求的，所以遊戲系統基本上都采用有狀態的服務模式。所謂有狀態的服務，就是用戶的數據狀態是駐留在服務器內存的，這樣才能保證快速完成操作並響應客戶端。只有在某些節點，用戶的數據才會持久化到數據庫。可以反面想一下，為什麽web服務無法采用這種模式呢？原因就在於“開放性”上，一個不斷和外部交換數據的系統，如果使用有狀態的服務模式的，基本無法保證數據的一致性。 2）各個子服務之前獨立性差 現在的遊戲系統也是比較復雜的，也是一個分布式的計算系統；依據不同的場景將遊戲系統先劃分為若幹子系統，每個子系統依據實際需要，部署一臺或多臺服務器實例，用戶的數據和遊戲指令在各服務器之間高速地流動，形成一個封閉的計算環境。但是，對比web系統，子系統相互之間的獨立性相對“差很多”，為了保證性能，數據在各臺服務器之間的流動是經過精心規劃的，這樣就導致系統的橫向擴容能力沒那麽好，於是就需要分服機制。舉個簡單例子，在一個扔骰子博彩遊戲裏，大量玩家聚集在一個房間下註，那麽一個房間的承載玩家數量必然是很有限的，你沒辦法通過添加硬件來擴充這個容量。 在這種情況下，為了針對各自的業務模式實現性能最大化，各大遊戲開發商都形成自己一套特有的解決方案，開放的技術框架比較少。 3）前後端使用二進制通訊協議 另一方面，為了保證高性能，服務器到用戶側的通訊量也要盡量地少，於是通訊上一般采用二進制的格式，更多地考慮效率而不是可讀性、兼容性。遊戲系統避免考慮客戶端版本的兼容，在PC遊戲時代，客戶端都具備自我更新的功能，在手遊時代都是用腳本來編寫客戶端遊戲邏輯。 4）開發人員素質要求 對開發人員的要求，從技術廣度上要求較低，在這個領域，新的技術或方案更新挺慢的。但是對網絡、算法、內存調優等技能有更高要求。因此，一旦後臺框架建設完成，遊戲領域經常出現開發者同時編寫前後端邏輯的情形。 封閉系統的一扇門： 一個完全封閉的系統的是沒有社會意義的，遊戲系統唯一開放的部分就是“登錄支付”。每個遊戲系統基本都會有一個獨立的登錄支付系統，而且在中國特殊的國情下，這個系統有時候還蠻復雜，甚至超過遊戲本省，因為要支持的渠道實在太多了。登錄支付系統就好像遊戲系統的一扇大門，大門背後是一個完全不同的虛擬世界。登錄支付功能雖然重要，但要從遊戲本質上來說，屬於邊緣子系統，訂單、支付這樣的功能從來不應該給系統造成性能壓力（否則老板半夜要笑醒了）。

遊戲服務器的思考之一：遊戲系統的封閉性