PyChina 大会北京站回顾

继 PyCon 大会于去年首次落户中国，今年的PyCon 大会于本月20 日在北京、上海、杭州、西安四个城市同时召开，这次大会由来自这些城市的谷歌开发者社区(GDG)北京GDG 、上海GDG 、杭州GDG 、西安GDG 、广州GDG 、以及华蟒用户组(CPyUG ) 和 TopGeek 共同举办。大会确立了“让 Python 无处不在”的口号，以及“来自社区、服务社区”的宗旨，为国内所有关注 Python、使用 Python、推广 Python 的企业和个人，提供平等、开放的交流平台。

会议开始之前，主持人周琦（ Zoom.Quiet ）首先介绍了 PyCon 的历史以及 Python 在国内的发展现状，同时给予现场每个人 30 秒钟的自述时间，通过大家的自述，可以发现今年的与会人员关注热点主要是：云计算、大数据、Python 使用场景与网站技术方案选型实施等，在播放了来自世界各地 Python 使用者的祝福视频之后，进入演讲阶段。

云计算

来自 RedHat、新浪 SAE、盛大云和阿里云的讲师分别做了云计算相关的分享。

OpenShift

Red Hat 的 Linqing Lu 首先做了题为“Open Shift is FanPaaStic”的分享。他通过对比 IaaS、PaaS 以及 SaaS 的区别，指出使用 PaaS 在时间、效率、资金上的优势，接下来他介绍了 RedHat 的 PaaS 方案： OpenShift 。对于 OpenShift，程序员可以选择自己喜欢的工作环境，比如 IDE、命令行或者是浏览器。

在 OpenShift 中，用户可以通过简单的命令行来创建实例，由于为了保证运行在其之上程序的稳定性，OpenShift 目前只集成了 2.6 的版本。

当谈及 OpenShift 的技术细节时，他说到:

OpenShift 基于 IaaS/Hypervisor/Bare Metal，RHEL（Red Hat Enterprise Linux）组成了基本的实例，在 RHEL 中通过 GEAR 安全隔离应用。当用户创建实例的时候实则是在 REHL 中创建 GEAR，系统自动将语言的运行时环境以及数据库等安装到 GEAR 中。

目前 OpenShift 通过 Cartridge 集成了 Java、PHP、Python、MySQL、 MongoDB 等，同时提供了 DIY 的接口让用户自定义安装所需要的环境。OpenShift 对代码会进行自动编译、测试以及发布。

Linqing 还提到目前的 Web 应用特点是短请求为主、并发量巨大，当用户的应用需要扩展时，OpenShift 将会通过自动将代码进行横向复制，通过 HA Proxy 将负载分担到不同的 GEAR 环境。

最后，Linqing Lu 还为大会分享了一个 Promo Code:PYCONCHINA，参会人员可以通过它注册 OpenShift 享有更多的服务特权。

盛大云

来自盛大云的刘海丰带来了题为“App Engine of Grand Cloud”的分享，他提到与其他的云计算相比，盛大云的最大特点是“不成熟”，因此也更需要社区的参与来一道对其进行改进。目前，盛大云支持PHP、Java、Python、ruby 等语言，可以通过多种方式进行管理，由于Python 环境刚刚上线，现在还只支持Django 框架。在技术细节上，盛大云采用了Nginx 作为负载均衡，通过自定义的 Cloud Foundry 作为云计算框架，使用 OpenTSDB/HBase 存储监测数据，整个管理框架是基于 Java 实现。

SAE

来自新浪 SAE 的陈峰与大家分享了 SAE Python 的发展历程，首先介绍了 SAE 目前的发展现状，新浪 SAE 支持大部分的 WSGI 框架、其基础服务包括 Fetchurl、Mail、Corn 等。目前 SAE 上包含了丰富的第三方库，用户可以通过其他方式来上传依赖库，但是目前还不支持 C 扩展。

作为国内比较成熟的 PaaS 平台，新浪的 SAE Python 于 2011 年 08 月开始启动，期间的技术选型经历和一些变化。陈峰介绍到，在早起由对 Apache 有着丰富的技术经验，同时 mod_wsgi 相对成熟稳定，他们的架构是使用 Apache、MOD_WSGi 来搭建，但问题随之而来：

1. 从解释器隔离到进程隔离，httpd 进程退化为完全的代理
2. apache prefork 的阻塞问题
3. mod_wsgi apache 与 SAE 的应用管理模型冲突
4. 只支持 wsgi

为了解决上述问题，SAE 选用了 Nginx、Direwolf 的方案。对于静态文件， Nginx 直接处理，同一个 Server 上的所有应用共享同一个 Nginx。对于动态的请求，Nginx 首先将请求加入默认队列，Direwolf 上的 master 实例会自动将请求分配给所属的应用队列，不同应用之间是进程隔离的。SAE 会根据请求队列的等待时间以及负载自动对应用进行扩展，当超过制定时间没有访问以后则会收回这些分配的实例。

Direwolf 是由新浪针对 SAE Python 的应用场景开发的系统，它完全用 C 语言实现，只负责解释 Python 脚本，目前支持 wsgi/Tornado woker。

为了防止用户代码执行越权的操作以及保护内部接口，SAE 进行了资源限制，主要使用如下的方式：

• 使用 LD_PRELOAD 对文件系统、system-call 进行限制
• 使用 cgroups 对 CPU/Memory 进行限制
• 使用 iptables、强制 sockproxy 等对网络进行限制
• 禁用了部分函数与模块
• 禁用进程、线程
• 禁用 Python 自带的 c 模块全部 builtin
• 限制第三方的 c 模块路径

对于 SAE Python 的下一步计划，Alan 表示：

尽快从 Alphoa 转成 Beta 版本，同时增加 geven worker 等。

阿里云

阿里云的王立做了“飞天开放平台与产品”的分享。目前阿里云已经具有了完整了的技术构架，各个云计算产品之间具有详细的划分。基于系统强大的运算能力，飞天提供 RESTful API 的数据处理服务，能够完成 PB 级别的数据处理。同时，ODPS 能够满足实时性不高的海量数据离线处理。

语言与应用

语言与应用干货较多，来自于豆瓣、扇贝网以及知乎的工程师分享了 Python 在网站架构方面的应用。

豆瓣

作为豆瓣推出的数字阅读服务，豆瓣阅读一直以拥有一流的用户体验广受好评，来自豆瓣的测试工程师孙毅为大家分享了豆瓣阅读中的持续集成与发布实践。首先他提到持续集成的好处是能够减少风险、减少重复过程、任意时间 / 地点部署、增加可见性，并且能够增强团队的信心。对于采用持续集成，孙毅依次从开发、提交、构建、交付等四个场景做出了对比。

之前在开发场景出现的问题是主要是开发环境复杂且不统一、本地构建困难并且本地没有快速反馈机制。豆瓣目前采用的解决方案是：

1. 本地采用统一的虚拟开发环境（使用 Vagrant ）
2. 订阅上有依赖变更（使用 Rss 订阅消息，使用 puppet 管理）
3. 大家一起贡献模块（使用 fork、pull-request）
4. 基准开发工具包
5. 简单便捷的本地 CI

在提交场景中，面对的主要问题是：review 流于形式、分支合并成本高、问题定为困难。豆瓣现在的解决方案是基于 git 的 pull-request，为此豆瓣内部还开发了一套类似于 github 的系统。使用 pull-request 作为基本的 review 单元，并且每次的合并都会触发构建，这就极大的保证了代码质量，目前豆瓣阅读在 5 个月的时间里，已经产生了 1275 个 pull-request、900 多次建构。

对构建场景，之前面对的主要问题是：

• 分支集成不足
• CI suite 反馈速度慢
• 无法获取阶段结果
• 持续服集成服务器资源有限

针对这些问题，豆瓣的策略是基于 opening pull request 的分支持续策略，同时将构建链和测试进行详细的分级，并充分的利用冗余的计算资源进行跑 CI。孙毅表示，通过大家贡献 slave，降低了对中心 CI 服务器的负载，目前能够将提交建构控制在 10 分钟之内。

在最后一步的产品的交付场景中，豆瓣集成了 CI suite 的版本状态监测，并且他说在豆瓣产品的每个重大特性都有开关，可以通过管理界面随时控制特性状态。当代码完成建构以后，就会执行远程脚本，打上上线的 tag，不过，目前的上线的最后控制还是需要人工点击按钮来发布。

知乎

来自知乎的工程师杨昆为大家带来了题为“Python 在社会化问答网站中的应用”的分享，首先他介绍了知乎的技术背景，目前知乎采用Python 作为开发语言、 Tornado 作为 Web Server、SQLAlchemy 作为 ORM。

随着用户以及产品特性的增加，知乎的技术选型也经历了几次变化，杨昆将其形容为“石器时代——青铜时代——蒸汽时代”，并且憧憬了今后的“信息时代”。

在“石器时代”，知乎采用“精益创业”的思想，注重核心逻辑，低成本快速开发，尽量外包周边业务。杨昆说，早起的知乎服务器就是两台位于美国的 Linode VPS ，但是随着访问量的增长，网络延迟以及性能问题日益凸显。在“石器时代”开发团队主要是针对硬件和网络环境的改善，他们将服务器迁入国内，购置了主机进行托管，技术方面通过 MySQL master/slave 减缓数据库压力、使用 HA Proxy 做热备份、使用 Tornado 解决高并发问题。杨昆着重提到了 Tornado 的异步编程特性，其高性能极大地改善了知乎的体验。

但是随着代码行数的膨胀，知乎的开发团队很快就面临了新的问题，他们这次主要将关注点放在了代码的重构之上，这就是知乎的“青铜时代”。这个"时代"的问题主要表现在：急剧增长的业务需求、数据库承担了大量的计算任务、Tornado 的瓶颈，他们的解决方案是对于 Tornado 进行优化、采用 Celery 作为分布式任务队列、使用 Redis 提高多个场景的性能。

杨昆说在“青铜时代”的功臣是 Redis ，选用 Redis 的原因是 Redis 简单易用、功能强大、性能强大，在知乎，Redis 主要配合 Cache、MQ 与存储功能。在使用 Redis 的过程中，也出现了一些问题，集中表现在随着数据量的增大，单个节点存储能力凸显，单点访问压力加大等。知乎的开发团队通过内部开发的 Redis Shard 解决了这个问题，并且已经开源了解决方案。

之前，知乎的服务器数量较少，没有专职的运维人员，并且运维主要是人工手动操作，但是随着服务器数量的增加，运维的问题也浮出水面，目前，知乎采用 Cobbler 统一安装配置操作系统、Puppet 统一管理服务器、使用 Nagios / Cacti 进行监控报警。

紧接着“青铜时代”的是“蒸汽时代”，在这个时期，知乎主要面临的问题是代码量大、逻辑耦合、调试开发难度加大、开发周期不一致等问题。知乎的开发团队通过如下的工作来解决这些问题：

• 针对代码量大，切分服务
• 针对紧耦合，使用 Sink（知乎内部系统）实现消息服务
• 针对调试难，使用 Kids（知乎内部系统）对开发日志进行集中收集
• 针对开发难，使用基于 Virtualbox 的虚拟开发环境 Hobox（知乎内部系统）

对于接下来的“信息时代”，杨昆说数据中间层、持续集成将会是关注的热点。

扇贝网

作为只有四个开发人员的小团队，扇贝网的工程师王捷做了题为“任由西洋参，我有地黄丸”的分享，旨在讲解在技术架构方面的共性问题。首先他介绍了扇贝网的背景，目前扇贝网的注册用户是100 万，每天访问量是5 万，扇贝网的技术栈很丰富，包括Nginx、 uWSGI 、Django、Python、MySQL、Redis、MongoDB、LVM 等。

王捷说当扇贝网成长起来之后，他们主要关注三个方问题：

1. 数据安全
2. 服务性能
3. 开发效率

他说到扇贝网之前在数据定期备份的做法比较“土”，直接拷贝 /var/lib/mysql，虽然也能起到备份的作用，但是事倍功半。目前，他们采用的策略是用 LVM 创建分区，mount 在数据库的目录上，通过打快照的方式快速备份数据库。同时，他们还分享了在硬件方面的“教训”。

对于安全策略，他指出如下值得借鉴的几点：

1. 增加只读账号
2. 常用查询脚本化
3. 在 slave 数据库上进行数据分析
4. 仅限内网访问
5. 做好数据库随时坏掉的准备

在服务性能的优化方面，王捷指出了 Django Queryset 的优化问题，他说 Django 没魔法，一定要清楚每一个查询背后所生成的 SQL 语句，避免 subquery。对于 MySQL，需要关注 innodb_buff_pool_size、innodb_flush_log_at_trx_commit、query_cache_size 这三个值，根据实际情况配置大小。然后，他说到了 uWSGI 的问题，扇贝网在使用的过程中出现了大量的 broken pipe 错误，通过半年多的使用他们总结了如下的经验：

• 分配多个 socket
• 每个 socket 分配一组 worker
• 调整内核的相应参数，如 ulimit,backlog,sysctl 等
• touch reload 机制

在扇贝，之前采用的 nfs 存储方案由于性能差、安全性差等原因被放弃，目前使用 MongoDB 作为文件存储。扇贝网将一些读取代价较高的数据存储在 Redis 中。

目前他们使用 git 进行版本控制，通过 virtualenv+pip 隔离开发环境和测试环境，通过单元测试保证代码质量，目前使用的持续集成工具是 Jenkins。

其他的分享包括， 3Gland 曾庆生《灵活的 IDC 业务中如何进行 Python 应用部属》、 AdMaster 陆丹峰《Python 在互联网广告监测分析中的应用》、 Limodou (李迎辉)《又一年, UliWeb 发展纪事儿》、华强方特影业周辉《视觉效果制作行业的工业语言——Python》、EasyHadoop 童小军《Python 配合 Hadoop 快速搭建开放型大数据仓库分析平台》、 42 区张教主 (张沈鹏)《42qu.com 代码 & 架构 导读》、刘远亮《知识引擎的设计》等。

通过回顾一天的演讲，我们发现 Python 在诸如云计算、大数据处理、影视后期处理等领域都有着广泛的应用，同时，在传统的 Web 开发领域，目前的开发者更多的是关注应用场景工具的选择以及开发测试流程的优化问题。

InfoQ 会后续推出上海站的回顾，没有参加本届 PyCon China 北京的同学可以访问大会官网了解详情，或者在这里下载讲义，期待明年的 PyCon 大会能有更好的内容奉献给大家。