架構之美第三章

問題、品質需求

1. 系統的伸縮性需求。如大型在線游戲，需要滿足大量用戶。在線用戶數量短時間內可能有很大的變化。
這其中隱含的需求是：
多用戶
并行
分布式系統，系統運行在多臺機器上
高可擴展性（用于加入新的故事情節，意味著新的代碼）
高穩定性、可靠性（一個用戶崩潰，不影響其他用戶）
數據一致性（多個用戶看到同一個東西的狀態應該是一樣的）

2. 架構設計目標
即另外一個需求，對其他開發者部署出一個簡單的編程模型，程序員可以將系統視為一個單機開發環境。
隱藏分布式和并發是一件困難的事。需要一種嚴格限制的編程模型。

典型的游戲服務器開發模型：反應式
客戶端（游戲機）（生成事件） - 服務端的事件監聽器（監聽事件，并生成任務） - 此任務可與多個客戶端進行交互
或者是服務端自己周期性生成任務。
這是一種典型的胖客戶端機制，適用于游戲和虛擬世界，也適用于J2EE和Web服務的應用。

區別另外一種經典的企業級架構：
瘦客戶端 - 胖客戶端 - 更胖的數據庫服務器。服務器保存客戶端的絕大部分信息，絕大多數真正的工作在服務器上完成。

在游戲的軟件架構中。不被修改的數據都被放在客戶端完成，只有共享的數據才放在服務器，服務器盡量保持簡單，減少計算。保持共享事實的最終來源，防止玩家作弊。客戶端只訪問少量的狀態數據，但訪問的數據大部分會被改寫。

而另外一種架構是90%的數據都是只讀的，大多數任務會讀取大量數據，再修改少量數據。

3. 延遲的需求
游戲架構要求用戶體驗好，大的延遲不被接受，甚至犧牲吞吐量換取少的延遲。
而企業環境的架構重在吞吐量，管理業務。有一點延遲可以接受。

一般情況下，處理擁塞的解決方案：
1. 基于地理位置來實現。游戲設計包含不同的游戲區域，每個虛擬區域運行一臺服務器，每個區域擁有自我限制功能，當人數過多時，服務擁塞，游戲變慢，趣味性下降，用戶就轉向更有趣的區域，響應時間就會得到改進。（對于棋牌類游戲，每個房間或區域有人數限制，滿的房間可以限制進入）
這種開發方法的問題：游戲設計時，需要決定哪些區域放在一臺服務器上，而添加新的區域時比較容易，若改動原來的區域，可能需要改動代碼，這些都是開發的工作量。

2. 分區sharding。一個分區是一個區域的副本，運行在自己的服務器上，獨立于其他分區，不同的玩家進入同一個區域的不同副本（分區）。這樣的缺點時，不允許不同副本的玩家彼此進行交互。

3.?Darkstar架構就是克服以上缺點，支持隨時伸縮，同時又不要求游戲邏輯受到伸縮影響。支持動態響應負載，而不是放在游戲設計中完成。

Darkstar的架構

DarkStar是由一組服務組成。每個服務定義為一個小的編程接口。這些接口很像經典操作系統的服務，支持對服務端的訪問持久存儲、調度并執行任務、與游戲的客戶端進行通信。
這些服務的程序不會受低層實現變更的影響，因為每個服務由一個接口來描述。當接口不變時，一個服務的變更，不會影響其他服務的實現。這是一個"分治"的過程。
另外，將基礎設施設計為一組服務，可以將這些服務在不同場景下進行不同的組合，更加靈活，復用性強。一組服務可以組成一個Darkstar棧，Darkstar棧中具體包含哪些服務可以由一個配置文件來設置。

從宏觀結構上來看

（分層、模塊化、通信機制）

每個Darkstar棧運行在一個服務器上，Darkstar棧就是服務的副本和游戲邏輯的副本。客戶端連接到其中一個服務器，與該世界的抽象表示進行交互。

每個副本可以與客戶端獨立的交互，不需要處理相同事件。復制主要是用于支持伸縮性。游戲邏輯也不知道其他服務器上的副本。而不同服務器上的副本協作是由Darkstar項目的基礎設施完成的。
游戲客戶端與服務端的通信機制包含兩種，一種是直接通信，另外一種是"發布-訂閱"模式。
Darkstar棧由一組元服務來協調，這是一組網絡訪問服務，對游戲程序員是不可見的。這些服務支持在線的副本相互協作，共同運營整個游戲。而且副本間相互獨立，某副本失效，會發起失效恢復操作。

此外，這些Darkstar元服務會跟蹤各副本的負載，在需要的時間重新分配負載，或隨時添加服務器，增加總體容量。

基本的組件/服務

對于游戲程序員而言，可見的架構就是棧中包含了一組服務，而4個基本服務是必須的。數據服務、通道服務、客戶端會話服務、任務服務。

數據服務
數據存儲、數據讀取、數據操作。
特征：大部分都是持久化數據、數據間靜態關系少、很少有復雜查詢、需要對延遲進行優化、需要修改的數據多
選型：與標準數據庫的使用方式有區別、數據庫簡單的命名策略，編程語言上對對象的引用


任務服務

用于調度、執行任務。

任務來源：響應某個事件、或游戲內部邏輯觸發的。常見任務的操作包括：從數據服務中讀取、修改一些數據，可能會有一些通信、或者生成其他的任務。

時間限制：執行任務的時間必須很短。配置中可以設置，默認值是100ms。
底層特征：Darkstar的底層在盡量的調度最多的任務。但對游戲程序員，因事件只響應一個任務。
并行性：客戶端產生的任務、服務端響應邏輯的任務是并行執行的。
數據競爭：由并行性帶來的數據競爭，同步、事務性操作（一個操作要么全部成功，要么回退）
通信機制：若任務包含事務操作，通信機制也必須支持事務


通信服務、會話服務：
登錄、認證后建立會話，監聽客戶端消息，并響應生成任務。會話也負責維持消息的順序，前一消息未處理完，后一消息就先不提交。這樣也讓"任務服務"得到了簡化。因為任務服務假定其任何時候觸發的任務都是并發的。


通道服務：
一對多的通信機制。客戶端之間可以交互，這種方式不能采取讓客戶端直接通信的方式，雖然這樣會減輕服務端的負載，但容易產生作弊行為。所有通道信息都必須經過服務器。


這些抽象層不會暴露客戶端或服務端的真實端點，這樣Darkstar系統能將服務端的通信端點從一個服務器上移到另外一個機器上，同時又不改變客戶對通信的感覺。底層的基礎設施可以根據需要進行動態調整。

任務的可移動性

要實現負載的動態均衡能力，就應該實現任務的可移動性，從一臺機器移到另外一臺機器上。這是系統伸縮性的要求和目標。
技術要求：
1. 任務是由java寫成，這樣物理機器上運行JVM，任務就可以運行
2. 任務數據來源。任務的數據都來自數據服務。而數據服務是所有游戲實例和Darkstar棧所共享的。
3. 通信由"會話服務"或"通道"來實現中介。其抽象能力，使得特定的會話由一個服務器移向另外一個服務器。
4. 負載的監控。Darkstar元服務的工作，這是網絡層面的服務，對程序員不可見，但對Darkstar棧中的服務是可見的。不會影響游戲的邏輯性，而能實現系統的伸縮性。
5. 利用伸縮機制來實現系統的高容錯能力。由于任務和通信機制是與具體機器無關的，且任務本身也是持久對象，保存在"數據服務"中。若任務中斷，等同于事務中斷，系統會重新調度不同的機器運行。這樣的后果是延遲有點長，但系統的正確性不變。

游戲架構的思考、改進

游戲與虛擬架構的特點：
1. 由于此行業的保密性，專用性， 其性能測試，數據指標比較難獲取，另外很多偶然性的因素，使得無法對不同的基礎設施做比較，對通用基礎設施的測試更加困難。
2. 很多服務器的架構都是定制的，很少有可復用的基礎設施假設，不注重這方面的積累。


Darkstar架構是圍繞服務器性能做出了很多關鍵決定。

1. Darkstar拒絕在服務器中存放任何重要信息。

所有生存周期超過一個任務的數據都需要放入"數據服務"中統一管理。這是Darkstar的核心。為什么？因為它能檢測數據的并發問題，對游戲程序員隱藏這些細節，讓服務器能利用多核架構，并實現整體是伸縮性。

2. 延遲的分析。

以上對并行性的處理，會引發一些延遲。將數據放入內存，才能將延遲最小化，是主流觀點。

而采用"數據服務"的方式會影響性能，訪問數據會引入一定延遲。但比其他方法會更有競爭力：1）持久化存儲可以利用數據庫緩存和一致性，盡量減少數據訪問延遲。2）將相關聯的玩家放到一個服務器上去，也可以利用數據庫的標準緩存技術，減少訪問和保存持久數據的延遲。（與基于地理位置的技術不同，這部分工作無需放入游戲開發工作中，而是根據運行時進行優化,（類似于編譯優化與運行優化））

3. 可靠性更高。

利用高并發來彌補持久化存儲的延遲損失，方案總體上是更有優勢，也更符合未來芯片基礎架構發展的方向。另外，持久化"數據服務"將服務器失效而導致的數據丟失減少到了最小。

4. 簡化游戲程序員工作。
當同時要求支持伸縮性和減少延遲的開發目標，那么開發者需要編寫自己的分布式和多線程基礎架構和代碼，這對開發者的要求更高，且工作量更大。而Darkstar將所有任務封裝到事務中，并在"數據服務"中檢測數據沖突，開發者就能享受多線程的好處，又不必在他們的代碼中引入鎖協議、同步和信號量。 Darkstar提供透明的負載平衡。

但是開發者還是需要了解Darkstar的底層并發和分布式實質，需要遵循一定編程模型，盡量利用數據服務的并發性，提升游戲的整體性能。

-----------------

筆記后感：Darkstar的介紹還是比較通俗易懂的，本以為能很快看完，但是發現里面的信息量還很大的，需要比較細致的思考。不管這個項目最終結果如何，它提供了一種思路，將基礎設施和上層應用邏輯分來，很有參考價值。

總結

以上是生活随笔為你收集整理的架构之美读书笔记之三的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。