分享下我之前做的伺服器框架;  遊戲線上最高3萬;  物理機I7的3臺阿里雲分服;效能及其強勁;

框架: 底層基於比較流行的skynet,基礎採用c語言,指令碼lua,部分服務golang;

Skynet: 是一個基於C跟lua的開源服務端併發框架，這個框架是單程序多執行緒Actor模型。所以他對於機器的效能壓榨是很高的。

1. skynet為遊戲主邏輯服務;  

2. go微服務作為輔助服務; 

3. ​redis作為直連主資料層;

4. mysql作為冷備+關係查詢;

5. proxy支援tcp,udp,websocket(支援http和https)

6. 通訊協議Protobuf

特點:

1. 效能: 底層採用了多執行緒+多luastate+協程, 效能優秀

2. 簡單: 採用了actor模型,併發無鎖,上層coding無感知

3. 沙盒: 利用多執行緒中lua coroutine的應付IO密集型的優秀能力; 也用lua沙盒做到了環境的軟隔離;

 

缺點:

未引入分散式的zookeeper協調控制,採用了world的單點模型,容災性較差,服務發現也比較原始;

 

 

前端:

proxy： 代理層; 獨立程序部署, 主要由原生的go編寫；  用來相容接收多種socket  以便支援 tcp，udp， websocket;      負責橋樑搭建: 第一條:  client->proxy->gate; 第二條: client->proxy->ms service   gate:  閘道器層; 獨立服務, 支援橫向擴充套件,主要是進行client-proxy-gate之間的 連線管理;  與所有game程序直連;  也與ms service的閘道器相連

邏輯層:

game service： 遊戲邏輯服務, 支援橫向擴充套件; 主要是處理基於有狀態的相關模組:如戰鬥,技能,副本等;   ms service:   微服務模組; 抽象出 微服務gate,接收其他服務直連,轉發相關訊息至微服務叢集; 主要分擔gate的連線壓力,並且分擔邏輯方面game service的相關壓力 處理模組: 客戶端配置獲取, 簽到, 活動, 小紅點, 郵件, 聊天, 工會, 開關等等此類 無狀態的邏輯;

 

 

 

 

  world service:  頂層世界服務模組; 與幾乎所有的service進行連線; 主要是管理所有的服務,玩家狀態等等; 以及做一些廣播,組播; 也提供熱更的對外介面; 也提供一些簡單的業務邏輯: 諸如全服boss等;  會有slave保證高可用;

資料層:

 

 

 DB service:  資料層; 主要負責與redis進行直連;  也與mysql進行直連;  每個game service會定時將data的更新發送到DB service; ms service 則會根據業務情況決定是否直接找DB service進行資料交換還是 找game service進行資料交換;   redis:  採用了哨兵叢集模式,開啟 AOF   mysql:  作用有二:  1: 冷備, 回檔 2: 提供一些簡單的關係型查詢;一般是對實時性不敏感的需求;   append data service:     資料記錄; 主要是追加模式寫資料更新到db的記錄; 便於查檔,歸檔;   DB daemon service:  獨立程序,進行redis的"髒資料"寫入到mysql中,並且寫入成功後追加到append data中;  可以配置 以事務和批量的模式進行寫入;   輔助層: rabbit mq: 

1. 作為叢集的全域性佇列用; 

2. 叢集所有service(包括slave)都要定時傳送心跳/負載等資訊到mq

3. 微服務會定時消費以上的心跳/負載, 進行負載和程序掛掉的判定, 異常時進行廣播;

4. 所有服務會訂閱幾個關鍵資訊: 擇主, 重連, 主備切換, 負載上限

 

third sdk service:  第三方sdk服務; 如神策等等: skynet伺服器 --> third sdk service --> 按照json格式寫入log檔案 --> 提交給神策後臺

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

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

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

底層核心:

1. skynet是基於事件的高併發訊息處理框架。

2. 事件主要來源: 網路，定時器和訊號通知等

3. 當事件觸發時，skynet將這些事件統一編碼成訊息結構，派發給感興趣的服務處理；如果當前無事件,可以做到該服務0的CPU消耗

4. 核心資料結構是 skynet_context :

5. 併發解決方案: 訊息佇列：每個服務都有一個訊息佇列，當佇列中有訊息時，會主動掛到全域性連結串列。skynet啟動了一定數量的工作執行緒，不斷從全域性連結串列取出訊息佇列，派發訊息給服務的回撥函式去處理。(在 callback 函式呼叫回工作執行緒時,訊息佇列沒有被放回全域性佇列，其它工作執行緒沒有可能獲得這個 callback 函式所屬服務的訊息佇列,所以該服務也就不可能存在併發風險了)