理解 skynet 架構

對於 skynet 架構的理解

Intro

最近迷上了雲風的 skynet 框架，但苦於 skynet 上手難度確實比較高，因而就萌生了搞清楚 skynet 的設計，而後本身拿 python 抄一個架構相似的遊戲服務器的想法。

因而，就此機會，我從我的使用體驗、文檔、被處處轉載的 blog 的基礎上，稍微作了一些思考。

skynet 的消息機制

首先要提起的是 skynet 中服務的概念。

skynet 的服務是一個個 lua 文件，固然根據 wiki 的說法，也能夠是其餘任意一種隨你喜歡的語言編寫。

引用自wiki - GettingStarted

最後是服務工做階段，當你在初始化階段註冊了消息處理函數的話，只要有消息輸入，就會觸發註冊的消息處理函數。這些消息都是 skynet 內部消息，外部的網絡數據，定時器也會經過內部消息的形式表達出來。

從 skynet 底層框架來看，每一個服務就是一個消息處理器。

從這裏能夠看到，服務的主要用法是消息回調。skynet 框架分發消息給服務，服務是 consumer，但同時服務也能夠發出消息，所以服務也是 producer。

skynet 的服務處理消息回調的方式是啓動一個 co-routine，每一個消息都分別啓動一個 co-routine，而後在 co-routine 裏調用使用skynet.dispatch綁定的消息處理方法。

顯然，用 co-routine 的處理方式是不夠高效的，由於 co-routine 的計算並非真正並行，因此在服務之上，還有多線程的調度器，容許多個Lua虛擬機裏的 co-routine 同時運行。

注意是多個Lua虛擬機——因此虛擬機內的co-routine並不會出現數據競爭，service 之間以 actor 模式通訊，線程間高效地傳遞數據，也就是服務間的消息機制。所以 skynet 的 wiki 文檔纔會說，單個進程內的 skynet 有最高效的並行性能。

大致來講，skynet的架構是這樣子的。

層級	名稱	責任
調度層	skynet進程	調度線程輪流執行lua虛擬機。
消息層	消息隊列	分發消息給服務
服務層	服務	發佈消息，設置消息處理回調
回調層	消息回調	每一個消息回調都會啓動一個新的 co-routine 執行回調函數

和雲風演講中提到的 skynet 就是個小的操做系統不謀而合。線程就是CPU，Lua虛擬機就是skynet這個「操做系統」下被調度的進程，輪流佔用CPU。