本來很想按順序寫下來，到了第五篇是打算先寫架構的，無奈這東西暫時沒辦法弄的比較通透，拖了很久也還是覺得寫起來有困難。有一個客觀因素是這陣子有點忙，很多東西要做，也沒辦法留出許多時間用來學習。

        還是先寫已經有點概念的東西吧....

關於架構：

        一個複雜系統開始施工前首先要設計其架構，但這個暫時沒能力說太細，所以只簡單一提。

        什麼是架構呢？

        我理解的架構就是一組能夠描述服務端功能的概念模型，它能把複雜的問題使用相同統一的方式進行描述，或者說可以把一個複雜的現實問題轉化為相對可控的工程問題。它甚至不需要任何程式碼，不需要複雜的UML圖，不管通過任何方式只要能夠簡化並描述問題。而且並不是只有最上層的架構才叫架構，我覺得它應該是一棵決策樹

        對於一套完整的服務端架構來說，應該包含軟體架構和硬體架構。有時候一些軟體上極難解決的問題卻可以通過硬體方案輕鬆解決，所以對於網路遊戲這種相對大型的軟體來說，硬體方案設計也是不可缺少的。

        對架構的要求包含兩個方面，第一個是硬性要求，要求能夠在這套架構的基礎上完成預期的遊戲功能並具有一定程度的可用性；第二個是優化要求，條件允許的情況下儘可能的使得架構基礎上的功能開發清晰簡單，儘可能做到對未知需求具有良好的伸縮性，儘可能的對執行期效率有所保障等等（你所能想到的好的方面）。

系統分層：

        系統分層是軟體架構設計的一個重要方面，分層的思想在《程式碼大全》裡有相對詳細的描述，應該是比較早就提出了，是降低系統複雜度的一種比較常見的做法。

        分層的粒度是根據問題的複雜程度以及具體的業務內容來決定的，對於簡單問題使用過細的分層不只是殺雞用牛刀的問題，實現起來也會變得囉嗦冗長，簡單的問題會被搞複雜。這可以理解為對簡單問題賦予了太多的概念，概念這種東西最好保持精簡，這是設計範疇的問題了。 

        遊戲的服務端根據遊戲的型別和公司的實際情況會有許多差異，限於個人知識沒辦法一一比較說明，我只寫我相對熟悉的MMOARPG的服務端設計。

一般也是類似軟體業比較經典的三層劃分（沒記錯的話應該是 系統層、業務邏輯層、表現層），首先是系統層，然後是引擎層，最後是邏輯層。下面分別介紹：

· 系統層：

        之所以需要有這麼一層主要是因為程式語言層面能夠提供的功能十分有限，更強力的功能常常要通過作業系統獲得（比如執行緒和執行緒的各種鎖）。當然您也可以試試避免直接從作業系統獲得這些功能，而全部改用第三方庫來解決問題，但他們的底層特性肯定也只能是來自作業系統，區別只是是不是你自己來做這些事情而已。

        該層設計的目標是要把所有依賴特定系統的邏輯全部隔離在這一層內，防止上層邏輯對作業系統產生直接依賴。同時，根據上層需求向上層提供足夠多的底層功能。大概不會涉及比較複雜的程式編碼，但這層實現起來也是相當不輕鬆的，因為現在基本都會有跨平臺的需求，所以一定要在系統層考慮好程式移植問題，把程式規劃好，儘量在移植的時候只需要按定義好的介面用最少量的程式碼再實現一個該系統的版本。同時，開發系統層也是需要對主流作業系統程式設計有一定經驗（因為這個地方常常許多坑），防止系統API誤用導致後期BUG追查起來十分困難。

        一定要處理的乾淨穩定，這樣才稱得上是為上層開發打下一個良好基石了。

· 引擎層：

        遊戲的邏輯層有著海量的遊戲邏輯，所以為了簡化問題，還是把其中一些和遊戲內容關聯不大但必不可少的功能抽取出來單獨作為一層。即去掉具體遊戲邏輯的血肉，剩下來的其實都可以囊括到引擎中去。除此之外，設計引擎層也是比較經濟的做法，因為和具體遊戲邏輯不關聯，又包羅永珍集合了許多公共元件，它日做其他專案的時候可以完完全全的複用起來。引擎層鋪設在系統層的基礎上，與作業系統相隔離。

        一般而言引擎層會涉及的問題：通訊、日誌、資料庫、場景管理、配置管理、主迴圈、腳本系統、計時器、記憶體管理、執行緒管理、容錯機制、基礎遊戲物件、視野管理等。具體專案不一定這麼劃分，但一般認為這套功能是MMOARPG服務端標配了。各個模組意思也很清晰，所以我想不用一一介紹也不影響理解引擎層是怎樣的東西。

· 邏輯層：

        邏輯層建立在引擎層的基礎上，一般不需要操心除遊戲功能以外的東西（如果不是的話通常暗示結構設計不合理）。到了邏輯層當然就是指那些與遊戲內容密切關聯的程式了，專案對遊戲功能的要求越高，邏輯層的程式碼就越多。多是一定的，但具體多多少，增長的快不快還是一定程度上取決於開發者對遊戲的理解，看看是否能對一些功能進行簡單合理的抽象。

        邏輯層的主要就堆堆邏輯（十分瑣碎），一般對編碼能力要求不高，但實際上對設計的要求頗高，程式碼多則BUG多，太多功能寫起來要命維護起來就更要命了...但據觀察寫邏輯的一般是程式部門人數比重最大的，而且對編碼能力又沒那麼高的要求，所以一般都拿來控制成本了，所以良好設計什麼的是不能有太多期待。要麼就是先派一倆強力黨先把核心功能寫好，避免讓後期純粹來寫邏輯的人來設計模組，這樣可能還比較穩妥些。

        邏輯層一般包括：具體遊戲物件（玩家、NPC）、基本遊戲行為（聊天、戰鬥，移動常常會被抽到引擎層去）、幫會、任務、道具、技能、副本、寵物、好友、PK等。

        關於邏輯層的設計有許多東西可以講，這裡先不展開。