高性能动态Web服务器的一些探讨

现在设计高性能Web网站时，一般都把动态和静态分开处理。静态资源(html/image/js/css/swf)一般使用nginx/lighttpd这类Web服务器，把静态资源缓存到内存或用sendfile，CPU和磁盘IO一般不是瓶颈，性能很高，直接用就行，本文不讨论。

至于动态部分，我们一般使用Apache，用C++编写CGI/FastCGI。FastCGI因为比CGI少了fork和初始化，并发性能和CPU消耗都比CGI要好很多。本质上，FastCGI是一种同步多进程的Server（也有用多线程模式，但对编码要求更高些）。

这种同步模式的并发性能，受限于FastCGI进程数和请求处理时长：假设每个请求100ms处理完，那么1个FastCGI进程每秒能处理10个请求，一台Web服务器假设起100个FastCGI进程，那就是每秒并发1000。比起一般异步Server每秒1万的性能，差了10倍。更重要的是，如果后端服务的接口耗时因异常情况变长时，FastCGI就像是被挂住一样，性能急剧下降，抖动明显。

我看到有些架构设计，把FastCGI只作为接入层，把消息转发给后面的异步业务逻辑Server。这种设计里，业务逻辑异步Server不用解析HTTP，能复用现有的框架和组件；但前面的FastCGI接入层需要知道业务Server的分布，有变动时要同步刷新配置，并且并发性能也受FastCGI进程数限制。

为什么不在异步Server的网络组件里直接支持HTTP协议呢？貌似难度很大，SSL、上传、认证、缓存、压缩、安全性等等，想起来就头大。参照前面把动静分离的思路，让异步Server只处理动态逻辑，简化功能，这样就省事多了。考虑到Web服务器经常出现代码bug导致入侵的漏洞，规划以下功能：
1、支持GET/POST方法
2、支持绑定多域名
3、HTTP Header长度限定
4、HTTP Body长度限定
5、URL长度限定
6、Cookie长度限定
7、支持应用逻辑设定HTTP Header
8、支持长连接模式
......

这样的话，网络组件直接提供HTTP服务，复用了我们在异步Server上的技术积累，也把原来CS模式的框架延伸到了Web领域。