1. 系統的伸縮性需求。如大型在線游戲，需要滿足大量用戶。在線用戶數量短時間內可能有很大的變化。
這其中隱含的需求是：
多用戶并行分布式系統，系統運行在多臺機器上
高可擴展性（用于加入新的故事情節，意味著新的代碼）
高穩定性、可靠性（一個用戶崩潰，不影響其他用戶）
數據一致性（多個用戶看到同一個東西的狀態應該是一樣的）?
2. 架構設計目標
即另外一個需求，對其他開發者部署出一個簡單的編程模型，程序員可以將系統視為一個單機開發環境。
隱藏分布式和并發是一件困難的事。需要一種嚴格限制的編程模型。?
典型的游戲服務器開發模型：反應式
客戶端（游戲機）（生成事件） - 服務端的事件監聽器（監聽事件，并生成任務） - 此任務可與多個客戶端進行交互
或者是服務端自己周期性生成任務。
這是一種典型的胖客戶端機制，適用于游戲和虛擬世界，也適用于J2EE和Web服務的應用。?
區別另外一種經典的企業級架構：
瘦客戶端 - 胖客戶端 - 更胖的數據庫服務器。服務器保存客戶端的絕大部分信息，絕大多數真正的工作在服務器上完成。?
在游戲的軟件架構中。不被修改的數據都被放在客戶端完成，只有共享的數據才放在服務器，服務器盡量保持簡單，減少計算。保持共享事實的最終來源，防止玩家作弊。客戶端只訪問少量的狀態數據，但訪問的數據大部分會被改寫。?
而另外一種架構是90%的數據都是只讀的，大多數任務會讀取大量數據，再修改少量數據。?
3. 延遲的需求
游戲架構要求用戶體驗好，大的延遲不被接受，甚至犧牲吞吐量換取少的延遲。
而企業環境的架構重在吞吐量，管理業務。有一點延遲可以接受。?
一般情況下，處理擁塞的解決方案：
1. 基于地理位置來實現。游戲設計包含不同的游戲區域，每個虛擬區域運行一臺服務器，每個區域擁有自我限制功能，當人數過多時，服務擁塞，游戲變慢，趣味性下降，用戶就轉向更有趣的區域，響應時間就會得到改進。（對于棋牌類游戲，每個房間或區域有人數限制，滿的房間可以限制進入）
這種開發方法的問題：游戲設計時，需要決定哪些區域放在一臺服務器上，而添加新的區域時比較容易，若改動原來的區域，可能需要改動代碼，這些都是開發的工作量。?
2. 分區sharding。一個分區是一個區域的副本，運行在自己的服務器上，獨立于其他分區，不同的玩家進入同一個區域的不同副本（分區）。這樣的缺點時，不允許不同副本的玩家彼此進行交互。?
3.?Darkstar架構就是克服以上缺點，支持隨時伸縮，同時又不要求游戲邏輯受到伸縮影響。支持動態響應負載，而不是放在游戲設計中完成。?

Darkstar的架構

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

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

轉載于:https://www.cnblogs.com/liying123/p/6415836.html

總結

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

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