一次失败的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 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/modulesextension=demo.soextension=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/