[[117843]]

衡量一個產品的成敗，往往所站的角度不同理解也就不同。站在一個開發人員的角度來看，判斷一個產品是否成功，往往首先判斷這款產品是否滿足用戶的需求。對于有性能擴展要求的產品，則還要考慮其是否具有較高的性能、是否便于后期擴展；對于具有代碼潔癖的開發者來說，則還要看代碼編寫是否規范等等。

今天我們先來了解一下這款產品的架構是如何設計的，再說說它的各服務器的功能。

首先我簡單說明一下架構中需要重點考慮的幾點：

1：網吧斷網時的處理：架構設計中要考慮到網吧和中心服務器斷網的情況，所以簡單的按照MMO游戲的設計方式是不可行的（這種情況雖不常見，但是經常會由于網絡不穩定而出現，有時也會因為一些其它原因而導致，例如某地區曾出現一整年斷網情況），所以架構設計時需要處理：當網吧服務器和中心服務器斷開后，網吧要能進行正常的業務處理；同時，當網吧服務器和中心服務器重新建立連接以后，需要將網吧在斷線時間段內所處理的所有數據重新的發送到中心服務器上，并進行繼續處理。

2：網吧業務連續性：對于網吧業務來說會存在一定的業務連續性，例如網吧的業務一定是先上機，后下機。這種業務如果處理順序錯亂，后果不堪設想。

3：網吧數據不準確：由于可能出現網吧網管勾結外部人員修改網吧營業數據的情況，因此網吧本地的數據不存在可信性（這里的數據指的是諸如營業流水等數據），需要中心服務器記錄網吧所有的營業情況，并以重新計算得到的數據為準。

4：網吧數據產生的時段性：去過網吧的人都知道，網吧在一天之中業務數據產生的時間并非都是均勻的，例如在晚上10點以后到第二天7點左右（各網吧情況不同而定）一般是很少產生業務數據的，因為這段時間屬于通宵包機時間；而在早晨8-9點屬于網吧清場開業時間，這段時間會有數據大量產生。同時在周末的時候網吧也會出現業務數據產生的高峰期。基于以上的情況，架構的設計要能處理網吧業務數據瞬間變高的情況。

以上4點是系統設計時所要重點考慮的，尤其是***點（是不是覺得考慮得很周到？但我要劇透的是，這種面面俱到的考慮其實是華麗麗的自虐。這個問題我以后會詳說）。

我設計的架構圖是這樣的：
 

在這個架構中每個核心服務器的功能概要說明：

1：網關服務器：

（1）：用來接收大量的并發網吧服務端連接請求。

（2）：接收網吧服務端的業務請求后，根據請求類型進行分析，并將請求發送給相應的后端業務處理服務器。

（3）：接收后端業務處理服務器返回的業務處理數據，并將此數據轉發給相應的網吧服務端。

2：帳號服務器：

（1）：對網吧的帳號信息進行合法性驗證。

3：上報服務器：

（1）：接收網吧業務中需要上報的業務（例如：用戶上機、下機、加錢、積分轉換等等）進行業務邏輯處理。

（2）：由于網吧業務存在前后邏輯關系，因此在處理的時候需要對網吧上傳的業務進行順序性處理。

4：同步服務器：

（1）：檢測網吧服務端相關數據是否和中心數據庫中的一致（費率數據、會員數據、營業流水等等），對于不一致的數據，采用同步方式強行讓網吧數據和中心數據庫數據一致。

外圍服務器功能概要說明：

1：負載均衡服務器：

（1）：針對網吧帳號、所在區域等等信息對網吧應該連接的反向代理服務器的IP和端口進行指定。

（2）：為了防止惡意連接反向代理服務器，負載均衡服務器為每一個網吧生成具有一定時效性的session。

（3）：接收反向代理服務器的消息，對網吧帳號和session進行認證。

2：日志服務器：

（1）：記錄所有服務器的日志信息。

（2）：對所有日志進行相關分析，提取出Error級別的日志，并將此類日志保存在數據庫中。

3：監控服務器：

（1）：監控所有服務器的運行情況，對于出現異常而宕掉的服務器程序進行自動運行，并向相關負責人發送短信報警。

（2）：定時從Error日志數據庫中提取相關日志，并將信息進行匯總后以短信（郵件）的方式發送給相關責任人。