1.6　一張地圖的極限

我們已經(jīng)知道怎樣編寫分布式程序（見1.4節(jié)），也知道了程序運行的底層原理（見1.5節(jié)）。如果不考慮程序?qū)崿F(xiàn)的復(fù)雜度（即1.4.4節(jié)提到的各種異常情況處理），不考慮硬件成本，只要搭建好分布式系統(tǒng)，就能支撐無數(shù)玩家。

但現(xiàn)實依然是殘酷的！

手機游戲的多人組隊對戰(zhàn)，多數(shù)是3V3、5V5，這是為什么呢？MMORPG要分區(qū)、分服務(wù)器，每個場景能容納的人數(shù)依然有限，這又是為什么呢？

1.6.1　難以分割的業(yè)務(wù)

實現(xiàn)分布式程序的前提是游戲邏輯能夠分割。如果游戲規(guī)則復(fù)雜，各個功能緊密相連，則不容易找到分割的方案。圖1-24是一款策略游戲的截圖，在近乎無限大的地圖上，玩家可以控制多支隊伍在任何地點與其他玩家的隊伍作戰(zhàn)。

請思考一下，如果讓你設(shè)計這樣一款游戲，怎樣讓一張地圖支撐幾千上萬的玩家（按照1.3.2節(jié)的分析，單個場景只能支持幾十名玩家呢）？這是一個貫穿全書的問題。

如果沒有很明顯的分割方法，部分功能依然要靠單點的性能支撐，比如開房間對戰(zhàn)類游戲的每一個房間、MMORPG的每一個場景等，那么單點（單個進程、單個線程）的運算能力依然會限制服務(wù)端的承載量。為了提高性能，一些服務(wù)端邏輯依然要用C/C++編寫，Skynet提供了這種能力。

圖1-24　策略類游戲示意圖

1.6.2　在延遲和容量間權(quán)衡

多個程序協(xié)作意味著消息延遲。回到圖1-14的全服聊天，聊天消息需由場景服務(wù)器發(fā)送到聊天服務(wù)器上，再由聊天服務(wù)器上轉(zhuǎn)發(fā)到各個場景服務(wù)器上，每一層轉(zhuǎn)發(fā)都需要時間。對于聊天功能，消息延遲幾毫秒不會有任何影響，但某些功能對消息即時性要求很高（比如幀同步，第8章會介紹），因此需要權(quán)衡增多一層轉(zhuǎn)發(fā)的代價。