一次失敗的PHP擴充開發之

一次失敗的PHP 擴充開發之旅

By warezhou 2014.11.19

緣起

經過不斷的持續迭代，我們部門的協程版網路架構（CoSvrFrame）終於出爐了！這本來是件喜大普奔的事情，但是隨著新業務的不斷接入，很多固有缺陷也逐漸浮出水面：

不支援“TCP串連池”

不支援“Dispatcher-Workers模型”

不支援“過載保護”

不支援“熱重啟”

不支援“64Bit”

... ...

對於資深後台開發而言，上面羅列的問題大多數都難入法眼，之所以成為問題，很有點“溫水煮青蛙”的味道：迭代過程缺乏宏觀視野，引入過多業務特性，導致整體架構不合理。最近的“協程版本”最初也是我個人業餘之作，僅僅為了能夠愉快地寫業務代碼，為了快點出活，底層直接複用原有SvrFrame，結果可想而知：根基不牢，地動山搖！以最極端的64Bit為例，相信大家秒懂了。

經過多番調研與討論，最終我們給出了如下前進方向：

引入公司內部開源的SPP3.0架構，吸收它的基礎周邊設施，進行業務二次開發

對於SPP進行擴充，支援PHP作為指令碼語言進行嵌入式編程，同時以C擴充形式給PHP提供協程能力（從此PHPer也可以愉快地書寫非同步代碼了，媽媽再也不用擔心我的callback了！）

叨逼叨?嗦了這麼久，下面可以切入主題了：如何?C++/PHP混合編程？

免責申明：由於本人屬於半路出家，接觸PHP擴充開發尚未足周，因此無法深入到WHY，僅能停留在HOW，僅作記錄之用，望高手見諒！

開場

嵌入式PHP

業內C++/PHP的結合，一般是出於“效能”考慮，在PHP代碼裡調用C/C++擴充，從而解決特定的效能瓶頸（如PB序列化等）。

作為C/C++開發出身，“開發效率”相對於“效能”的誘惑顯然更大，因此，我們的思路是：將PHP作為指令碼語言，快速開發商務邏輯，插入到SPP架構運行。

1. 以RTLD_GLOBAL方式開啟php動態庫

void *php_handler = dlopen("libphp5.so", RTLD_LAZY | RTLD_GLOBAL);if (!php_handler) {    base->log_.LOG_P_PID(LOG_FATAL, "%s\n", dlerror());    return -1; }   dlclose(php_handler);

2. 通過php_embed_init進行初始化

php_embed_module.php_ini_path_override = "../php/php.ini";php_embed_init(0, NULL);

3. 通過zend_eval_string引入PHP指令碼

zend_first_try {    char exec_str[256];    snprintf(exec_str, sizeof(exec_str), "include '%s';", "../php/demo_handler.php");    if (int ret = zend_eval_string(exec_str, NULL, exec_str TSRMLS_CC)) {        base->log_.LOG_P_PID(LOG_FATAL, "zend_eval_string fail. ret=%d\n", ret);        return -1;     }    base->log_.LOG_P_PID(LOG_DEBUG, "zend_eval_string succ.\n");} zend_catch {    base->log_.LOG_P_PID(LOG_FATAL, "zend_eval_string catch.\n");} zend_end_try ();

4. 通過call_user_function回調PHP函數

zval z_funcname;ZVAL_STRING(&z_funcname, "EchoDemo::init", 1);zval *zp_svr;MAKE_STD_ZVAL(zp_svr);ZVAL_LONG(zp_svr, (long)base);zval *zp_etc;MAKE_STD_ZVAL(zp_etc);ZVAL_STRING(zp_etc, etc, 1);zval z_retval;zval *z_params[] = {zp_svr, zp_etc};int call_ret = call_user_function(CG(function_table), NULL, &z_funcname, &z_retval, sizeof(z_params) / sizeof(z_params[0]), z_params TSRM convert_to_long(&z_retval);int func_ret = Z_LVAL_P(&z_retval);zval_ptr_dtor(&zp_etc);zval_dtor(&z_funcname);zval_dtor(&z_retval);if (call_ret < 0 || func_ret < 0) {    base->log_.LOG_P_PID(LOG_FATAL, "call_user_function fail. call_ret=%d func_ret=%d\n", call_ret, func_ret);    return -1;}

5. 通過php_embed_shutdown進行清理

php_embed_shutdown(TSRMLS_C);

PHP擴充

網路上關於PHP的C擴充開發文章可以說已經到泛濫的地步了，有興趣的讀者可以深入閱讀文末的附錄。

1. 下載php源碼包，進行手動編譯，為了配合上述嵌入式使用，需要開啟?enable-embed選項

./configure --enable-embedmakemake install（可選）

2. 進入php源碼包的ext目錄，藉助ext_skel工具產生外掛程式架子代碼

cd ext./ext_skel --extname=demo

3. 編輯config.m4，開啟PHP_ARG_WITH或者PHP_ARG_ENABLE選項（說實話區別仍沒搞清楚，求達人指點），添加C++支援、依賴路徑等

PHP_ARG_ENABLE(demo, whether to enable demo support,    [  --enable-demo           Enable demo support])if test "$PHP_DEMO" != "no"; then  PHP_REQUIRE_CXX()  PHP_ADD_LIBRARY(stdc++, 1, EXTRA_LDFLAGS)  PHP_ADD_INCLUDE(/root/spp/module/include/)  PHP_ADD_INCLUDE(/root/spp/module/include/spp_incl/)  PHP_NEW_EXTENSION(demo, demo.cpp, $ext_shared)fi

4. 編輯demo.cpp，添加擴充定義和實現（函數、類、變數 ...），這裡僅僅給出函數定義樣本，類相關的有興趣的讀者自行根據附錄摸索。這裡給出的sendrecv函數定義比較有代表性，其中第3個參數rsp為引用參數，負責將接收到的資料返回給PHP調用方

ZEND_BEGIN_ARG_INFO_EX(arginfo_sendrecv, 0, 0, 7)    ZEND_ARG_INFO(0, req)    ZEND_ARG_INFO(0, req_len)    ZEND_ARG_INFO(1, rsp)    ZEND_ARG_INFO(0, rsp_len)    ZEND_ARG_INFO(0, ip)    ZEND_ARG_INFO(0, port)    ZEND_ARG_INFO(0, timeout)ZEND_END_ARG_INFO()PHP_FUNCTION(sendrecv){    char *req = NULL;    int req_str_len = 0;    long req_len = 0;    zval *rsp = NULL;    long rsp_len = 0;    char *ip = NULL;    int ip_str_len = 0;    long port = 0;    long timeout = 0;if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "slzlsll", &req, &req_str_len,&req_len, &rsp, &rsp_len, &ip, &ip_str_len, &port, &timeout) == FAILURE) {        return;}       struct sockaddr_in addr;    memset(&addr, 0, sizeof(addr));    addr.sin_family = AF_INET;    addr.sin_addr.s_addr = inet_addr(std::string(ip, ip_str_len).c_str());    addr.sin_port = htons(port);    char *rsp_buf = (char *)emalloc(rsp_len);    int rsp_buf_len = rsp_len;    if (int ret = mt_udpsendrcv(&addr, req, req_len > req_str_len ? req_str_len : req_len, rsp_buf, rsp_buf_len, timeout)) {        efree(rsp_buf);        RETURN_LONG(ret);    }    zval_dtor(rsp);    ZVAL_STRINGL(rsp, rsp_buf, rsp_buf_len, 0);    RETURN_LONG(0);}

const zend_function_entry demo_functions[] = {    PHP_FE(sendrecv, arginfo_sendrecv)    PHP_FE_END  /* Must be the last line in demo_functions[] */};

5. 一切準備就緒，可以編譯擴充了，我個人比較喜歡動態編譯（靜態編譯需要重新編譯php源碼，太耗時費力），產生的.so位於當前擴充的modules目錄下

/usr/local/bin/phpize./configure --with-php-config=/usr/local/bin/php-configmake

6. 編輯php.ini檔案，添加新的擴充，然後就可以愉快地在PHP代碼中調用新擴充了

extension_dir="/somewhere/modules"extension="demo.so"extension="xxxx.so"

高潮

終於到了組裝成型的時刻了，通過telnet玩了幾把EchoDemo，看到一行一行的回顯，不禁心情大好。

這裡最值得讚歎的就是process函數對於sendrecv擴充調用，這裡背後通過協程其實已經實現了一次非同步網路互動：既能像同步CGI般書寫邏輯代碼，又能無痛地享受非同步高並發。

願望是美好的，現實是殘酷的！

我這時突然心血來潮：來壓測一把效能吧，看看相比於原生C++代碼有多大的效能衰減。單次請求1KB，施以1w/s的壓力，壓了一會coredump了。

記憶體流失？協程棧溢出？...

期間各種折騰：GDB，修改協程棧大小，Google，諮詢PHPer ...

很快到了晚上，該查的都查過了，該問的都問過了，實在沒轍了，停下來喝杯茶：“call_user_function可重新進入麼”？想到這一層，相信瞭解協程本質的兄弟又秒懂了：你妹的，人家實現Zend的時候怎麼知道調用線程還會玩協程進行使用者態調度啊，這個黑盒裡面一切皆有可能啊！全域變數、靜態變數 ...

好吧，去掉sendrecv這類基於協程的擴充，重新壓測，單worker對於3w/s的echo還是輕鬆無壓力的。

結局

雖然這次最迷人的一個Feature最終未能實現，不過我還是很開心，因為再次印證了一個觀點：思考往往比蠻幹高效百倍，尤其在處理棘手問題時，無頭蒼蠅般亂闖亂撞往往費力不討好，此時，如果能夠冷靜下來，儘力搜集現有知識儲備，說不定靈感就來光顧你了。

未來可能的方向：PHP從5.5版本引入了yield，感覺如果挖掘出來Zend對於yield的支援細節，說不定有希望和我們的C架構很好的融合，但是總覺得是個填不平的大坑。如果拋開其它因素，也許我還是希望選擇Golang一類語言直接享受goroutine的優勢吧，哈哈！

附錄

PHP擴充開發及核心應用

http://www.walu.cc/phpbook/preface.md

編譯PHP擴充的兩種方式

http://521-wf.com/archives/227.html

如何使用C++開發PHP擴充（上）

http://521-wf.com/archives/241.html

如何使用C++開發PHP擴充（下）

http://521-wf.com/archives/245.html

Wrapping C++ Classes in a PHP Extension

http://devzone.zend.com/1435/wrapping-c-classes-in-a-php-extension/

