架构概览
Wheatserver来自于构造一个开源的uWSGI轻量级的项目，但随着项目发展，可插拔式的工程构建使得发展为通用应用服务器，分离的模块使得极易构造出适合的应用环境。通过Wheatserver，我们构建出了一个极快的WSGI应用服务器和Redis集群管理应用，我们发现Wheatserver能极大的提高高性能服务器端软件的构建。
项目部署简介:http://yuyuyu101.github.com/wheatserver/
开发者文档:Wheatserver设计思想及开发文档
- 具备一定强度的并发请求处理能力
- 具有多种工作模式，同步、异步或者多线程，协程，并且可以扩展
- 应用层协议和应用可以模块式开发，框架最少接口化和接口最少疑惑
- 具备强有力的内部反馈和自省能力，方便系统管理
- 最少的依赖和选项最少化
- 增强系统的自身调控，减少高级配置项
- 保持简洁
可开发模块分为三种，工作者模块、应用层协议模块和应用模块。
工作者模块需要处理的事项是提供IO接口，另外需要支持的是收集各处的统计信息。
协议模块需要提供初始化和析构接口，提供协议发现(spot)接口来指定后端的应用，并且具有协议解析接口。
应用模块只需收到协议层提供的信息并且自身完成业务层逻辑后，向工作者模块提供的IO中写入回应即可。
工作者模块、协议模块和应用模块最小化偶合，采取固定的信息流转。所有提供基础工作的由Master模块负责。整个请求流从工作者模块流入，经过协议模块解析后流入应用模块，最后应用模块产生回应使用上层的协议模块API发送回应。
模块之间保持数据隐藏和最小耦合度，任一模块开发者只需要了解自己所需协议模块的API和工作者API即可完成应用模块的开发。
Master进程:管理所有Worker进程，主要负责配置解析，监听管理端口，统计汇总工作者统计数据。
Worker进程:业务逻辑实现和主体运行者，由Master fork出。
Master会时刻接收到Worker进程发出的统计数据，当一定时间后没有接收到特定Worker的报告时，Master会Kill掉这个进程并且重新启动一个进程。如果Worker进程自己崩溃掉，Master进程也会通过信号发现死亡的子进程，重新Fork新进程。Master进程监听管理端口，不仅接收Worker发出的统计报告，还可以监听来自系统管理员发出的命令查询包并且回复自身的状态。
模块实现还需要注意的事项:
- 日志写入
- 配置项解析
######目前已完成模块实现:
工作者模块:
- 同步工作者:用于应用开发的调试
- 异步工作者:用于生产环境下使用
协议模块:
- Http协议:支持Http1.1和Http1.0协议，与Nginx媲美的Http协议处理能力
- Redis协议:支持The new unified request protocol，即Redis 1.2以后的版本的协议
应用模块:
- WSGI应用: 使用Python-C API编写的WSGI服务器，由于上层Http协议极快的解析能力，做到比Gevent实现的WSGI服务器更快
- 静态文件应用: 使用内核调用直接发送数据避免复制，与Nginx差不多的静态文件处理能力
- Redis集群管理应用: 零复制代理及集群分发应用
Wheatserver目前试用部署在Srchsale，运行情况良好。
请参考Wheatserver与Gevent作为WSGI服务器的性能评测
近期需要支持的功能: Mail协议
工作者模块增加协程工作者