五星宏輝遊戲項目小結

五星宏輝遊戲項目小結

web服務端和game服務端的區別

Server的定義和分類

wiki對Server的定義：

In computing, a server is a computer program or a device that provides functionality for other programs or devices, called "clients". This architecture is called the client–server model, and a single overall computation is distributed across multiple processes or devices.

分類：Typical servers are

• Database Server
• File Server
• Mail Server
• Print Server
• Web Server
• Game Server
• Application Server

異同

Web Server，典型例子是淘寶。
特色：

• 全部流程均由客戶端發起，客戶端發個請求，服務端返回個響應——請求響應模式
• 根據客戶端訪問的服務不一樣，客戶端能夠向不一樣的具體服務端節點發起請求

Game Server，典型例子是魔獸世界。
特色：

• 有一個肉眼能感受到的鏈接握手的過程，創建鏈接後，流程有多是服務端發起（好比給你展現周邊玩家），也有多是客戶端發起（好比你移動了一下）——交互性
• 同時，若是你手邊有抓包工具，能夠看到，若是你選中了某個玩家，在該玩家的頭像框消失以前，一直是同一個場景服務器在跟你通訊。——常鏈接

Application Server，典型例子是QQ。
特色：

• 介於Web Server和Game Server之間，看着像一個web服務器，可是又有遊戲服務器的特色。

服務端在client-server模型中的扮演角色：

服務端，在物理上表現爲一或多臺主機，在邏輯上向客戶端暴露一組host:port二元組，接受客戶端鏈接，爲每一個客戶端鏈接維持鏈接會話（Session）。客戶端與服務端藉助鏈接會話傳遞消息，消息按必定的協議序列化與反序列化，客戶端與服務端的邏輯模塊由消息的內容驅動運轉。
不管是Web Server，仍是Game Server，在運做流程上都大致相同。而在流程中的細節上，有共同點，也有不一樣點。下面就分開說道說道。

共同點：

• 都是爲客戶端提供多種服務

  • 好比淘寶既提供搜索服務，又提供商品頁查詢服務。

    魔獸世界既提供登陸服務，又提供讓你在場景裏戰鬥、走跑跳的服務。

• 都須要鏈接會話概念

  • 會話是創建在鏈接之上的概念，其實本質上是服務端爲某個特定客戶端維持的數據結構與狀態信息。

    Game Server自沒必要說，玩家登陸以後，服務端須要有一個專門的全局服務器維護玩家狀態與玩家的部分較熱的存檔信息，玩家進入到某個場景，場景服務器還須要專門維護一份玩家的場景相關的狀態信息。

    Web Server，鏈接會話一樣存在，最直觀的理解是淘寶登陸以後服務端會爲客戶端保持一個會話上下文。

• 服務端的每臺物理機服務多個客戶端

  • 這是服務器的誕生基礎，發展到如今，已經沒人再討論是異步IO仍是多路複用，如今成熟的解決方案已經不存在孰優孰劣的問題，徹底是哪一個網絡庫用的順手就默認接受這個網絡庫底層的IO模型。

• 都具備分佈式結構

  • 架構的演化老是類似的，Web服務端與遊戲服務端在發展過程當中相互學習相互演進，目前造成的主流架構基本都至少應該將專門管鏈接的、專門管邏輯、專門管存儲的作必定程度的物理隔絕。

    能夠像skynet同樣，利用luaState作隔絕；能夠像Erlang同樣，利用actor作隔絕；也能夠最簡單的，按進程隔絕。只要能保證其中之一掛掉不會產生連鎖反應致使其餘都掛掉就能夠了。

• 開發語言

  • 實際上也是近幾年手遊開發火起來以後開發語言才趨於統一的。web開發一直是百家爭鳴，而遊戲開發在之前是C++一家獨大。

    可是如今，客戶端的邏輯層已經基本見不到C++的影子了，服務端純用C++的也愈來愈少了。lua、python、java、C#、Erlang、js甚至ruby的工業級遊戲服務端框架都有出現，web服務端和遊戲服務端的開發語言已經趨同。

不一樣點：

• 會話的存在形式（本質區別）

  • 這一點是web服務端與遊戲服務端最本質的區別

    web服務端的客戶端與客戶端之間交互很是有限，所以，服務端能夠將會話狀態保存在外部存儲服務，好比一些緩存中間件、文件系統中間件，而後等再用到的時候再拿出來就能夠了。

    而遊戲服務端的客戶端與客戶端之間交互很是頻繁，好比，同場景的其餘玩家會不停作不規律移動，戰鬥時一個技能就會對複數個玩家形成影響。

    這時若是將會話狀態保存在外部，會形成頻繁的狀態存取，嚴重影響服務器吞吐量。所以對於遊戲服務端來講，會話一般保存在進程內。

• 交互頻率與數據流向

  • Web Server的頻率低，並且數據的流動是由客戶端驅動的，流向一般是客戶端請求了，服務端才返回。

    Game Server的頻率高，數據的流動一部分由客戶端驅動，一部分由服務端驅動。流向除了服務端對客戶端請求的響應，還有服務端的主動推送。

• 通訊協議基礎

  • 通訊協議基礎就是客戶端和服務端通訊的協議所依賴的協議基礎。

    按常識理解的話，web通訊的基礎在應用層是http協議。因爲小說君對web開發並不太熟悉，因此不太清楚目前私有協議在web開發中的應用，可是想必即便是私有協議，也必定是套在http協議的某些字段裏面的，這跟遊戲的客戶端服務端通訊有本質區別。

    遊戲一般會實現私有的序列化協議，能夠簡單理解爲應用層定義協議包結構平鋪成字節流或者是串行序列化字節流。若是要支持必定程度的協議版本兼容，會用二進制json或者protobuf來實現協議序列化，可是通訊協議自己是沒有「基礎」可言的，純私有化協議，不具普適性，也沒有必要定義成一種專門的協議。

• 對第三方組件的依賴程度

  • web服務端發展速度快，從業者多，同技術棧的從業者交流更深刻更頻繁。所以，web服務端出現、而且還會出現愈來愈多的第三方獨立組件。web服務端的從業者甚至只須要在本身的技術棧不一樣層次上選擇不一樣的第三方組件，黏合起來，就能造成一整套的解決方案，很是方便。

    遊戲服務端正相反，比較封閉，基本上每一個項目組要麼是從頭至尾重寫，要麼是從其餘項目組拿來整套技術棧直接改改。基本不存在第三方獨立組件的狀況，在技術開放氛圍好些的公司還好，畢竟你們能夠複用同一套框架，不然的話，公司內的框架多種多樣，各類造輪子出來的，各類空降團隊從原來公司帶過來的，技術沒法複用，團隊成員流動更是一大難題。

Firefly框架

在遊戲服務器端，每每須要處理大量的各類各樣的任務，每一項任務所需的系統資源也可能不一樣。而這些複雜的任務只用一個單獨的服務器進程是很難支撐和管理起來的。因此，遊戲服務器端的開發者每每須要花費大量的時間精力在諸如服務器類型的劃分，進程數量的分配，以及這些進程的維護，進程間的通信，請求的路由等等這些底層的問題上。而Firefly徹底能夠完成這些重複而繁瑣的工做，從而將上層的遊戲開發者解放出來，把精力更多的放在遊戲邏輯的實現上面。

Firefly是免費、開源、穩定、快速擴展、能「熱更新」的分佈式遊戲服務器端框架，採用Python編寫，基於Twisted框架開發。

Firefly特性

1. 採用單線程多進程架構，支持自定義的分佈式架構
2. 方便的服務器擴展機制，可快速擴展服務器類型和數量
3. 與客戶端採用TCP長鏈接，無需考慮粘包等問題

Firefly思路

一個最基本的服務器就是一個在不停運行着的應用程序。

在分佈式遊戲服務器中，咱們須要的服務器具備的功能有：

• 監聽客戶端的鏈接
• 監聽其它服務進程的消息
• 鏈接其它服務進程
• 數據庫鏈接和緩存服務

Net connect 作客戶端鏈接

Root監聽其餘服務進程消息

Node鏈接其餘服務進程，db數據庫，cache緩存

是否須要監聽客戶端鏈接，是否監聽其餘服務進程消息等這是都是能夠在config.json中進行配置。包括各個服務器的名稱以及各個服務器之間的鏈接關係。這樣就能夠自定義出本身的分佈式架構。

Firefly結構

從功能職責上來看，Firefly框架結構以下圖所示：

1. management：Firefly 是個多進程、分佈式的遊戲服務器。所以各遊戲server(進程)的管理和擴展是firefly很重要的部分，框架經過抽象使服務器的擴展很是容易。
2. Network：客戶端鏈接通訊、server進程間的通訊等構成了整個遊戲框架的脈絡，全部遊戲流程都構建在這個脈絡上。與客戶端的通訊採用的是請求/響應式的，全部收到的客戶端的請求，服務端都會給出相應的迴應，服務端也能主動的推送，廣播給客戶端消息。這些請求是基於指令號的請求（例如定義101爲登錄指令）。server進程之間的通訊時採用的異步回調的方式，這樣就減小了的進程間經過網絡通訊中的時間消耗。
3. Data: 數據處理是網遊的重要部分。在網遊有大量的數據須要存儲，須要更新，這使得數據庫的讀寫效率成爲服務器的最大的性能瓶頸。Firefly的db處理可以將數據庫表中的數據緩存到memcache中並能以對象的形式進行調用相應的對象方法對數據進行操做。能夠在不一樣的進程中經過實例化相同的名稱的緩存實例，獲得同步的數據。並能將緩存對象中的數據寫回數據庫中。

Firefly流程

1. 從config.json中讀取配置數據
2. 根據配置中定義的服務端的架構，啓動相應的服務進程。並創建節點之間的鏈接。有配置數據庫的，實例化數據庫鏈接池。有配置memcached的，創建memcached的鏈接。
3. 根據配置相應的的進程啓動的入口模塊。

Python遊戲後端架構

設計方案

• 性能卓越和高可用性
  1. 分佈式架構（客戶端到服務端全部環節避免單點問題、有效負載均衡）
  2. 支持高併發寫（db緩存，部分模塊改成批量操做，減緩DB壓力）
  3. 遊戲推送機制可靠快速，無延遲
  4. 分佈式代理，故障發生時自動切換
  5. 遊戲服務熱更新
  6. DDos防禦
• 監控運維
  1. 用戶行爲模擬（開發實現模擬大量真實用戶行爲機器人程序）
  2. 通知模塊（獨立語音、短信、郵件通知服務模塊）
  3. 遊戲異常監控系統（異常出現時實時通知相關人員）
  4. Linux上線操做腳本自動化，遠程部署
  5. ELK體系（引入kafka、elasticsearch、kibana，記錄分析遊戲日誌信息）

整體架構

Web服務代碼架構

預警系統體系

Client端（各待預警的子項目）數據上報（只需1步）：

1. 在用戶操做的先後調用已經封裝好的日誌agent上報原始操做的信息（信息格式參考後續的接口文檔）；

Server端（分析預警系統）：

1. 收到client發送過來的請求後，首先進行鑑權驗證；
2. 驗證經過後，根據類型（異常錯誤類和信息記錄類）分類存儲到不一樣的消息隊列；

​ 異常錯誤類：上報過來的信息通常爲須要進行預警通知，錯誤的驗證邏輯由上報者本身內部判斷；

​ 信息記錄類：上報者只是上報原始記錄信息，具體是否觸發預警的邏輯驗證由預警後臺程序驗證；

1. 不一樣類型的worker持續從對應的消息隊列中獲取最新消息，產生分析結果；
2. 根據分析結果決定是否調用Notice服務通知產品開發、運營人員；

週期性任務：

該部分主要指預警後臺週期性（天/小時/分鐘）執行各類統計分析任務，對可能出現異常的分析結果進行預警；某種程度上能夠很好的起到數據埋點實時預警的第二道保障做用；

預警系統主體表結構設計：

項目代碼