微信号:infoqchina

介绍:有内容的技术社区媒体

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

2013-12-23 18:20 InfoQ

豆瓣网首席架构师洪强宁最近在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的容量,很明显是无法支持公有云的用量的。


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


***********************************

本文来自InfoQ微信公众账号:infoqchina

1、回复“今日新闻”,查看今天更新的新闻;

2、回复“今日英文”,查看今天英文站的更新;

3、回复“文章 +关键词”,搜索关键词相关内容;

4、回复“QCon”,了解QCon大会相关信息;

5、回复“活动”,了解最近InfoQ组织的线下沙龙;

6、回复“架构师”,获取《架构师》下载地址;

7、回复“投稿”,了解投稿和加入编辑团队的流程。

***********************************

 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 React Native开发技术周报第二十期-热推Redxu整理与开源项目 唯快不破:Web 应用的 13 个优化步骤 RxJava学习总结 Docker网络详解及pipework源码解读与实践 一致哈希