“失敗”項目的審視：架構

近年來移動應用開發正在迅速增長。有無數的移動Web應用程序在互聯網上公布，所以了解關於移動開發框架的信息變得尤為重要。下面就讓我們來了解一下“失敗”項目的審視：架構。

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

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

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

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日志數據庫中提取相關日志，並將信息進行匯總後以短信(郵件)的方式發送給相關責任人。

以上就是精品為您准備的關於“失敗”項目的審視：架構的信息，希望對您的生活工作有幫助，祝您生活愉快。