洪强宁介绍 Douban App Engine 的架构与特性

豆瓣网首席架构师洪强宁最近在 PyCon China 分享了他们研发两年的成果：Douban App Engine（DAE）。InfoQ 中文站编辑在现场对洪强宁的分享（ PPT 下载）进行了记录，提取重点内容如下：

DAE 是专门针对 Python 做的私有 PaaS 平台，目前已经支撑了 427 个应用，其中 126 个是对外应用。126 个对外应用包括：

• 豆瓣电台的 Bubbler
• 豆瓣移动版网站
• 豆瓣 FM
• 豆瓣电影
• 豆瓣小组

对内应用则包括 Douban Code 平台、豆瓣上线系统 Up 平台、用于人事管理和活动组织的豆瓣花名册、验证深度学习算法有效性的豆瓣电影评论数据分析系统精灵宝钻等等。

DAE 目前每天处理 2.4 亿动态请求，峰值可达到 5K qps，运行在 32 台服务器上（豆瓣称之为 32 个节点）。

开发 DAE 的原因

洪强宁介绍开发 DAE 的原因，包括几个方面：

1. 用 Git 替换 SVN。此前，豆瓣所有的代码都在一个 SVN repo 上，commit 数量将近 17 万。PyCon 北京之前，豆瓣正式停用 SVN，将所有代码转移到 4.6k 个 git repo 上，目前有 2.8K 个 fork。项目数量以每一两天一个新项目的速度增长
2. 基础设施公用，不用给每一个应用都配一套MySQL、BeansDB、Memcache、MQ 什么的了
3. 大大简化了新项目启动的操作：你只需要 dae create 即可创建你的项目，dae serve 即可测试，dae deploy 即可上线
4. 最佳实践可以自动实施到所有的项目上，这包括每次提交都进入持续集成系统进行自动化测试，分级上线，状态收集和故障报告的标准化等

基于上述好处，DAE 的存在还带来了另一个极大的好处：运维工作的可扩展性。如果没有 DAE，那么 SA 的工作量跟服务器数量、应用种类的数量是呈平方增长关系的。有了 DAE，只需要 4 个 SA 就能完成所有的豆瓣运维。

DAE 的架构设计

DAE 的架构是这样设计的：

每一个应用都有一个 app.yaml 定义这个应用的版本、是 sync 模式还是异步模式、出了问题该通知谁等信息。

应用依赖采用类 pip 的方案解决，只需执行 dae install package 即可安装该 package 以及相关的所有依赖。豆瓣提供了一个 pypi 的镜像供大家使用。

实例分为三种：web、service 和 daemon。

一个 web 实例就是一个 gunicorn。使用 gunicorn 的原因是因为它是用 Python 写的，适合豆瓣对它做二次开发，而且 gunicorn 还有一些很好的特性，比如 graceful restart。

service 是用于在应用和应用之间传递信息的，用 gunicorn 配合 thrift 实现。

daemon 是那种长期运行、不会死掉的守护进程，采用 ZooKeeper 做全局管理。有了这个就可以实现一些其他的应用，可以保证 Message Queue 里有固定数量的消费者，通过定时产生一些消息，让队列的消费者执行特定程序来实现定时任务。

路由系统采用两级 Nginx 结构，请求过来之后判断它是找哪个应用的哪个实例，给它做一个 HTTP proxy 过去。基本上，长期没人访问的应用消耗是很小的，仅占用硬盘空间。这里使用了 unix socket 而避免使用 tcp，是看中了 unix socket 的文件属性，实现更简单。

所有的基础服务，如 MySQL、memcache、doubandb、cdn、mail、irc 等，都是通过 API 的方式提供。业务访问不同的服务会有不同的前缀，通过这个实现隔离和监控。

DAE 的特点

根据洪强宁的介绍，DAE 本身的资源占用是很低的，因为是用进程来做资源分配，用 Unix 账号做资源隔离，监控则交给外部的监控系统。

另外，DAE 是一个自己实现自己的系统：通过一个 DAE 应用部署应用，通过一个 DAE 应用管理应用，一个 DAE 应用 scale 所有的应用，而 DAE 的代码也是托管在一个 DAE 应用上，会有循环依赖。

DAE 自身的升级是通过开发集群 ->beta 集群 ->stable 集群逐级上线的，目的是在发布到外部应用之前 DAE 系统已经经过了内部系统的测试。

DAE 在部署应用时，会分批逐步在各节点部署，部署后会自动测试，测试不通过就会自动回滚，这样来保证应用部署过程中和部署后的可用性。

另外，DAE 的环境是不受限的，比如 C 扩展，比如 Python 的 fork、subprocess、multiprocessing 等在其他 PaaS 上禁止使用的特性，在 DAE 上都是允许的。这样当然会造成一些潜在的问题，比如你的应用 fork 出来一堆线程没有处理，就会在那里占用很多资源。所以我们做了一个曹娥来解决这个问题，在父进程死掉的时候杀死所有 fork 出来的子进程。

接下来希望做的一些事情：

• 让 DAE 成为豆瓣所有应用的平台
• 采用 cgroups 实施资源限制，以免外部监控跟不上的情况
• 开发新的服务系统，解决在应用 thrift 中发现的一些问题，和 thrift 互为补充
• 自动实现跨 IDC
• 实现 QoS，让任何应用的问题不会影响其他应用的表现

DAE 并没有计划做公有云服务，因为原本的设计采用的 Unix 账号模式，设计目标是数千个 app 的容量，很明显是无法支持公有云的用量的。

开源方面，其实一直有这个计划，会在基础库逐步开源之后再开放出来。