core_framework —— 基於libev的輕量級lua網絡開發框架

時間 2019-11-19

標籤 core framework 基於 libev 輕量級 lua 網絡開發框架欄目 Lua 简体版

原文原文鏈接

大道至簡, 返璞歸真.前端

前言

在發表這篇博文的前夕, 還有一些小夥伴在提問一些如下相關的問題:node

性能怎麼樣？mysql
是否容易上手?react
開發目標在哪?git
如何反饋問題?github
對比行業內的lua開源項目有何優點?web

等等, 以上問題會在本文中一一介紹.redis

CF的原由

首先來聊聊情懷這個東西! 相信每個行業內的從業者都或多或少有過一個夢, 這個夢叫作: "我到時候要開發一個XXX"！其實做者當初也是同樣.sql

每當半夜(凌晨)在加班、看文檔、調試的時候, 總會搜索到一些幾年前或十幾年前的框架或入門demo。例如: tinyhttp, 連接的源碼是一些同窗fork的鏡像站。docker

每次看到這些內容或多或少都會激起心中那一絲絲快熄滅的熱情, 也許這就是最後對技術的渴望？

就是在動手建立項目以前還反覆問過本身是否要作? 能堅持下去麼？也許被噴都是一種奢望？

在內心一一回答了這些問題後, 在2018年底建立了本項目.

說句實話! 一個網絡開發框架最難的不是實現某個功能, 而是從零開始一步一步添磚加瓦的造輪子!

做爲一個網絡開發框架, 最重要的兩個功能確定是須要的！定時器庫、事件驅動庫. 如何抉擇？選項有2個: libev / libuv .

libev 成熟穩定、輕量級、unix like支持、容易嵌入;

libuv 比libev更加優秀，增長了許多功能(線程池、信號、同步、鎖等等)，封裝更加完善, 而且增長了windows支持;

從cf框架開發之初選型來看, libuv絕對是目前最優解. 可是做者恰恰選擇了libev. 也今後開始, 艱辛的底層開發之路就此展開.

首先, 做者不讓使用者C/C++進行實際業務開發! 這樣作會讓使用者有較高的開發成本與學習成本, 而選擇一門較好的腳本語言就顯得尤其重要.

做者對Lua還算是稍微熟悉一點, 因此就選了Lua做爲業務腳本語言。至於Lua語言的優點這裏就不說了, 網上大把文章誇它的.

如今既然腳本語言已經選定, 那麼就開始寫代碼吧！Let's Lua.

CF的編寫之路

1. 網絡層

首先, 咱們來看一段C封裝給Lua調用的API代碼:

LUAMOD_API int
luaopen_tcp(lua_State *L){
	luaL_checkversion(L);
	/* 添加SSL支持 */
    SSL_library_init();
    SSL_load_error_strings();
    // CRYPTO_set_mem_functions(xmalloc, xrealloc, xfree);
    // OpenSSL_add_ssl_algorithms();
	/* 添加SSL支持 */
	luaL_newmetatable(L, "__TCP__");
	lua_pushstring (L, "__index");
	lua_pushvalue(L, -2);
	lua_rawset(L, -3);
    lua_pushliteral(L, "__mode");
    lua_pushliteral(L, "kv");
    lua_rawset(L, -3);
	luaL_Reg tcp_libs[] = {
		{"read", tcp_read},
		{"write", tcp_write},
		{"ssl_read", tcp_sslread},
		{"ssl_write", tcp_sslwrite},
		{"stop", tcp_stop},
		{"start", tcp_start},
		{"close", tcp_close},
		{"listen", tcp_listen},
		{"connect", tcp_connect},
		{"ssl_connect", tcp_sslconnect},
		{"new", tcp_new},
		{"new_ssl", ssl_new},
		{"free_ssl", ssl_free},
		{"new_server_fd", new_server_fd},
		{"new_client_fd", new_client_fd},
		{NULL, NULL}
	};
	luaL_setfuncs(L, tcp_libs, 0);
	luaL_newlib(L, tcp_libs);
	return 1;
}

以上是TCP實現的C代碼的片斷, 有興趣閱讀源碼的小夥伴請點擊這裏;

衆所周知Lua沒有原生的Socket. 那麼就須要框架編寫者本身抽象底層邏輯從新實現一套API.

簡單的封裝Lua C庫誰都會, 並且也算不上是什麼難事. 可是咱們的目的是將底層同步阻塞Socket hook爲非阻塞, 這時候難點就來了！

你們都知道libev是基於react模型的事件驅動網絡庫, 全部註冊事件後的業務邏輯都是以回調的形式觸發. 那不就變成node-lua代碼了嗎？(笑)

這時候, 做者想了個點子來解決這個問題! 執行流程以下:

每次須要作一些同步操做的時候, 就調用C API註冊回調事件.

爲當前註冊的全部事件建立一個Lua協程保存上下文並讓出當前協程執行權.

等到註冊事件被觸發後, 調用C API恢復協程繼續執行.

簡單來講就是將C層次的異步回調邏輯封裝爲Lua層的同步非阻塞, 保證不由於IO問題阻塞線程.

下面提供一段socket同步非阻塞的僞代碼, 經供參考:

function TCP:recv(bytes)
    local current_co = co_self()
    self.read_co = read_ev(function()
    -- do action
    -- stop timer_ev
    -- wakeup(current_co) 恢復執行權
    end)
   self.timer_co =  self.timer_ev(function()
    -- do action
    -- stop read_ev
    -- wakeup(current_co) 恢復執行權
    end)
    tcp_start(io, EV_READ, self.read_co)
    timer_start(timer, 3秒超時, self.timer_co)
    return co_yield() -- 讓出執行權
end

一個Lua版的Socket EV_READ僞代碼大體的處理流程如上, 想看實際處理邏輯請看這裏。

同理, Socket write/connect/listen等等API直接照抄就行(UDP也大同小異). (其實這裏有個小插曲就是SSL SOCKET的坑, 可是因爲篇幅問題就不說了.)

細心的小夥伴可能發現代碼同時註冊了Socket與Timer事件, Socket非阻塞操做不能解決read與connect超時的問題. 因此cf框架乾脆就封裝完全一點.

至此, Socket算是已經算是基本hook與封裝完成了. 接下來就能夠開始寫應用層協議了.