对gigahttpd开源项目的一些看法——2009-6-25 CSDN CTO俱乐部火锅城主题聚会后记

　　在CTO俱乐部 (http://cto.csdn.net/)中看到6月25日组织火锅城主题聚会时，就注意到聚会的位置（北京东南角，地铁永安里站附近）距离我（北京 西北角，地铁西二旗站附近）较远，预计路上需要花需1小时，报名后就盘算着要尽量早去。到了25日，先收到确认电话，然后收到了详细地址的短信，结果当天 的工作一直到近七点才收尾完成。经过近一小时的地铁和走路，终于到了火锅城，也许我是最后一名吧，一眼往过去没找到空座位，CSDN的工作人员在帮我加椅 子的时候，告诉我说有人找我，我一边等椅子，一边迷惑中，刚坐下，就看到msup的徐海峰过来。虽然我对这个话题感兴趣，但是由于还没吃饭，就没来得及和 徐海峰聊，希望下次聚会有机会讨论一下。
　　我和楼英勇先生、苏兴华先生、张鹏先生一桌，由于工作内容相关的缘故，和苏兴华先生（3D引擎）聊得较多。具体内容涉及工作关系就不在这里说了。
后来又认识了鲁义明先生，了解到鲁先生也是做开源项目，也是采用实体公司的方式来进行服务支撑，在这一点上和我目前参与的一个开源项目（XOOPS，北京众锐普斯信息技术有限公司 进行服务支撑）很相似，可惜我回来后按照鲁先生的名片访问亿民网（http://www.yiminnet.com）却访问不了，很遗憾，通过项目网站（http://gigahttpd.sf.net/）大概了解了一下情况，我谈一下我的看法：

1. 定 位问题。如果把目前的网站架构分解成HTTP Server（例如nginx） + Web Server（例如php的fastcgi模式） + App Server（例如用C、Java编写的应用） + DB Server（例如memcached数据缓存或MySQL、SQLite等关系型数据库）的话，我的理解是gigahttpd希望能替代HTTP Server和DB Server，并给出适合于gigahttpd架构的Web Server和App Server开发接口规范。如果是这样的话，就违背了软件工程中一直倡导的解耦合的观念。因此我的观点是如果要容纳HTTP Server和DB Server的话，建议拆分成两个开源项目分别运作，这样也可以召募不同的爱好者分别参与
2. C10K问题。单就HTTP Server项目而言，由于单独的HTTP Server并不能定制业务，所以需要配合Web Server实现，这样就涉及到了HTTP Server与Web Server的部署问题，如果部署在同一台服务器上，考虑到Web Server响应请求涉及大量的计算资源，很有可能没涉及到C10K问题的时候，服务器的计算资源就耗尽了，所以建议部署为不同的物理服务器，通过TCP 接口连接。另外，由于gigahttpd编译在Linux内核中，因此内联编译（例如apache的mod形式加载）的风险较大（ring0级不适合处理 应用级代码中大量的出错和异常情况）。
3. TCP接口问题。从HTTP Server与Web Server的接口考虑，这个接口两种情况，第一种是通用接口（例如CGI，fastcgi），第二种是内联加专用接口（例如apache通过jk使用 ajp协议连接tomcat），选用内联加专用接口的话，会限制应用范围，建议使用通用接口，考虑到gigahttpd的目的是解决负荷问题，因此建议使 用fastcgi接口。
4. 保持效果可见。从我参与XOOPS开源项目开发以来，我注意到很多开源项目的夭折在于没有及时兑现预期的价值而影响了参与者的士气，所以建议保持效果可见，例如从一开始就可以当成最简单的fastcgi HTTP Server使用，然后再不断的改进。
5. 循序渐近。虽然是开源项目，也应当进行版本规划工作，每个版本实现的需求应当足够少到可以在每个版本的参与者失去耐心前发布。

　　粗浅的见解，敬请斧正。