继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来搭建，但问题随之而来：
\- 从解释器隔离到进程隔离，httpd进程退化为完全的代理\
- apache prefork的阻塞问题\
- mod_wsgi apache与SAE的应用管理模型冲突\
- 只支持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在网站架构方面的应用。
\豆瓣
\作为豆瓣推出的数字阅读服务，豆瓣阅读一直以拥有一流的用户体验广受好评，来自豆瓣的测试工程师孙毅为大家分享了豆瓣阅读中的持续集成与发布实践。首先他提到持续集成的好处是能够减少风险、减少重复过程、任意时间/地点部署、增加可见性，并且能够增强团队的信心。对于采用持续集成，孙毅依次从开发、提交、构建、交付等四个场景做出了对比。
\之前在开发场景出现的问题是主要是开发环境复杂且不统一、本地构建困难并且本地没有快速反馈机制。豆瓣目前采用的解决方案是：
\- 本地采用统一的虚拟开发环境（使用Vagrant）\
- 订阅上有依赖变更（使用Rss订阅消息，使用puppet管理）\
- 大家一起贡献模块（使用fork、pull-request）\
- 基准开发工具包\
- 简单便捷的本地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等。
\王捷说当扇贝网成长起来之后，他们主要关注三个方问题：
\- 数据安全\
- 服务性能\
- 开发效率\
他说到扇贝网之前在数据定期备份的做法比较“土”，直接拷贝/var/lib/mysql，虽然也能起到备份的作用，但是事倍功半。目前，他们采用的策略是用LVM创建分区，mount在数据库的目录上，通过打快照的方式快速备份数据库。同时，他们还分享了在硬件方面的“教训”。
\对于安全策略，他指出如下值得借鉴的几点：
\- 增加只读账号\
- 常用查询脚本化\
- 在slave数据库上进行数据分析\
- 仅限内网访问\
- 做好数据库随时坏掉的准备\
在服务性能的优化方面，王捷指出了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 代码 \u0026amp; 架构 导读》、刘远亮《知识引擎的设计》等。
\通过回顾一天的演讲，我们发现Python在诸如云计算、大数据处理、影视后期处理等领域都有着广泛的应用，同时，在传统的Web开发领域，目前的开发者更多的是关注应用场景工具的选择以及开发测试流程的优化问题。
\InfoQ会后续推出上海站的回顾，没有参加本届PyCon China 北京的同学可以访问大会官网了解详情，或者在这里下载讲义，期待明年的PyCon大会能有更好的内容奉献给大家。
311
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
