對於 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。