附录 A：案例研究

为了回答 Django 在现实中究竟表现如何，我们跟很多人交谈过（包括 email 方式），这些人都已经在他们的地盘上完成，部署过 Django 站点。本附录主要是他们的言辞，当然为了表述更清晰也略作了一些编辑。

人物列表

让我们认识一下我们的嘉宾和他们的项目吧。

Ned Batchelder 是 Tabblo.com 的首席工程师. Tabblo 起家时是围绕照片分享的的一种讲故事工具，但它最近被惠普公司收购用作广泛的用途。

我们的 web 开发风格，以及我们连接虚拟世界与物理世界的方式，让 HP 看到了真正的价值，他们收购了我们，让我们可以将技术带给 web 上的其他站点。 Tabblo.com 依然是一个伟大的故事讲述站点，同时，我们也忙于将我们最有趣的技术模块化并更换主机。

Johannes Beigel 是 Brainbot Technologies AG 的开发主管，Brainbots 面向公众的主要

Django 站点是 http://pediapress.com/, 你可以从那里订购维基百科的打印版。Johannes的团队目前正致力于一个称为 Brainfiler 的企业级知识管理软件。

Johannes 告诉我们，Brainfiler

Brainfiler 是一个集管理、搜索、分类与共享功能的软件解决方案，处理来自各种不同信息源的信 息。它为企业级应用构建，在企业内部网与互联网中都可以使用，具有很高的可扩展性与可定制性。这个项目的核心开发开始于 2001 年，最近，我们重新设计和 实现了应用服务器与 web 前端，它现在是基于 Django 的。

David Cramer 是 Curse 的开发主管，他开发了 Curse.com,一个致力于大型多人在线游戏(例如魔兽世界，网络创世纪等)的站点。

Curse.com 是互联网上最大的用 Django 建成的站点之一:

我们每月大概有六千万到九千万的页面访问量，使用 Django，我们页面访问量的峰值达到过一个月一亿 三千万。我们是高度动态的以用户为中心的站点，我们为在线游戏玩家提供服务，特别是大型多人在线网络游戏。我们是全球最大的魔兽世界站点之一，我们始建于 2005 年，

在 2006 年，我们扩展到魔兽世界以外的其他游戏。

Christian Hammond VMware (虚拟化软件的领头羊)的高级工程师，同时他也是 Review Board(http://www.review-board.org/)的开发主管，Review Board 是一个基于 web 的代码走查系统，它起源于 VMware 的一个内部项目，现在成了一个开源项目:

2006 年底，David Trowbridge 和我讨论了在 VMware 使用的代码走查流程，在将代码提交到源代码仓库之前，程序员要将改动的部分用邮件发出来让其他人审阅。在这 个基于邮件的流程中，想跟踪某个感兴趣的代码走查就比较困难。因此，我们开始讨论这个问题的解决方案。

我并没有把想法写出来，而是直接开始编码。不久，Review Board 诞生了，它可以帮助开发人员、代码审阅者及相关责任人方便地跟踪代码走查与更好的沟通。使用者可以直接在代码上做评注，而不是像原来那样在邮件 中用文字模糊的指代某部分代码。代码与评注一起展现在系统中，开发者可以根据这些评注方便地对代码做出修改。

在 VMware，Review Board 的蔓延快得超乎想象，在短短几周内，已经有十来个团队使用它了。现在，这个项目已经不再局限于 VMware 内部了，我们希望有一天它可以走向开源，让更多的公司与项目使用它。

我们已经建立了一个站点并发出了开源公告，访问 http://www.review-board.org/. 我们得到了许多印象深刻的反馈，就像在 VMware 内部一样。很快，我们的演示服务器拥有了超过

600 名用户，并且有开发者参与到项目中来。

Review Board 并不是市场上唯一的代码走查工具，但它是我们见到的此类工具中的第一个内置了大量功能特性的开源项目。我们希望最终很多开源甚至商业项目都能从中获益。

为什么选择 Django?

我们询问每一个开发人员，为什麽他决定用 Django，究竟有什么其他的选择考虑，以及如何最终决定使用 django。.

Ned Batchelder 說:

在我加入 Tabblo 之前, Antonio Rodriguez (Tabblos 的创建者与 CTO) 对 Rails 和 Django 做了个测评, 发现两者都可以提供非常高效的快速构建环境。在两者的对比中，他发现，Django 更有技术含量，可以更容易的构建强壮的、可扩展的站点。另外，Python 完善的生态系统使得 Django 具有强有力的社区支持。Tobblo 的开发充分 证明了以上观点。

Johannes Beigel 說:

我们使用 Python 编码已经很多年了，不久我们开始使用 Twisted 框架，web 方面自然就使用了 Nevow. 然而很快，我们发现尽管 Twisted 提供了完美的集成，很多东西还是会略显笨重，它给我们灵活的开发流程造成了阻碍。

进行过一些内部讨论之后，很明显，Django 是符合我们需求的最理想的 web 框架。

我们转向 Django 的最初动机是它的模板语法，但很快我们就发现 Django 中的其他特性也非常有用，Django 一时炙手可热。

在做了几年并行开发与部署工作后（在一些客户站点的项目中 Nevow 依然在使用），我们得出了这样的结论：Djiango 更轻量、更灵活，写出的代码更容易维护，也更有趣。

David Cramer 說:

我在 2006 年夏天听说了 Django，那时我们正在忙于一个比较大的重构。研究了一下 Django之后，它给我们留下了很深的印象，它提供很多功能，可以节省我们的时间，我们商量着，决定就用 Django。马上，我们就开始编写第三版的代码了。

Christian Hammond 說:

我在几个小的项目中尝试使用了 Django，它给我的印象很深，它是基于 Python 的，我现在已经成 了一个 Python 的爱好者。Django 不仅使得编写网站或者 Web 应用很容易，而且它还可以保持代码的可维护性，通常这在 php 或者 perl 中是比较 难做到的。根据这些经验，我不假思索的选择 Django。

起步

由于 Django 还是一个比较新的工具，有经验的 Django 开发者还不是太多，让我们看看这些先行者们是怎么开始使用 Django，以及他们有哪些经验可以分享给 Django 的新手。

Johannes Beigel 說道:

我们一直在写 c++与 perl 程序，切换到 python 之后，我们依然用 c++来实现一些计算密集型的部分。

我们是这样学习 Django 的：照着教程做练习，阅读文档了解它都能做什么（只跟着教程做容易漏掉很多 特性），努力去理解这些组件背后的基本概念，如 middleware,request objects, database models, template tags, custom filters, forms,authorization, localization 。在真正需要的时候，我们会去深入研究这些主题。

David Cramer 談到:

官网上的文档很不错，时刻关注它。 Christian Hammond 談到:

David 和我之前对 Django 都有使用经验，即使那时还是受限的。我们从评论版的开发中学到了很多东西。我会建议新手去阅读精心编写的 Django 文档和你正在阅读的这本书，它们对于我们都是无价的。

我们不是非得向基督徒行贿来得到引用的权力。

移植现有代码

虽然 Review Board 和 Tabblo 是白手起家开发起来的，其他的网站却是从现有代码移植而来。我们感兴趣的是了解这个移植的过程。

Johannes Beigel :

我们开始的时候从 Nevow 移植站点，但很快意识到必须更新太多概念性事物（包括在 UI 部分和应用服务器部分），因此我们转而从零开始，而将之前的代码主要用作参考。

David Cramer :

之前的站点用 PHP 编写而成。从 PHP 到 Python 的移植工作非常程式化。唯一的问题是你必须非常小心内存管理问题【由于 Django 进程运行时间比 PHP 进程（单循环）要长得多。】

现状

下面是一个关键问题：Django 是如何对待你的？我们对听见 Django 出错特别感兴趣——在撞南墙 之前 就知道所用工具的弱点所在是很重要的。

Ned Batchelder :

Django 真正使我们能够满足我们需要的网络架构 作为热点用户,企业 ,现在作为 hp 的合作伙伴, 我们使用非常灵活的方式,使软件适应新的需求. 分离功能,模型,视图和控制器,MVC模块化,让我们可以方便的扩展和维护 而基于 python 的语言给了用户机会使用大量的已有库来解决 问题不必重复造轮子 感谢 PIL, PDFlib, ZSI, JSmin,

System Message: ERROR/3 (<string>, line 220) Unexpected indentation.

and BeautifulSoup

内存对象和数据库对象之间的关系是， in a few ways，Django 的使用中最难的部分。第一，

Django 的 ORM 并不能保证，对同一个数据库记录的两此引用是来自同一个 Python 对象，所以你可能会遇到这种情况：代 码中的两个部分要修改同一数据库记录，而其中一个的数据是旧的。第二，Django 开发模型鼓励你在数据库对象的基础上建立你的数据对象。我们会发现更频繁的超时，更多地使用那些没有对应到数据库的数据对象，我们只好不再假定数据是保存 在数据库里的。

对于一个有大量的、生命周期很长的代码库，花时间来 anticipating 你的数据存储和访问是有非常意义的。nd building some infrastructure to support those ways.

我们也增加了数据库迁移功能，这样开发人员就不必通过 SQL 脚本来更新数据库结构。开发人员可以通过写一个 python 函数的来更新数据库。当服务器重启的时候，这个更新会自动生效。

Johannes Beigel 談到:

我们把 Django 看做是一个完美符合 Pythonic 思想的成功平台。所有事情都会像您期望的那样工作。

在我们的项目中一个需要花点时间来做的事情是调节全局 settings.py 文件和目录或配置

（为 apps 程序,templates 模板,locale data 本地化设置,或者其他的文件。）因为我们在部署一个高度模块化和可配置系统，项目中所有 Django 视图是类实例化的方法 But with the omnipotence of dynamic Python code, that was still possible.

David Cramer 有言:

一个周末，我们被要求搞出一个大型数据库应用程序。如果用 php 的话，做出这样一个原型网站我们大概要花一到两周时间。这时候我们发现了 Django

现在，由于 Django 是最伟大的平台，it cant go without saying that its not built specific to everyones needs.在开始启动 Django 项目网站时，我们的网站处于年度流量最大的月份，我们赶不上进度，在接下来的几个月中，我们对大部分响应 Django 服务请求的硬件和软件进行了细致的调优，［这包括修改硬配置，调整 Django 性能，调整我们当时正在用的 lighttpd和 FastCGI

在 2007 年 5 月份，暴雪（魔兽世界的创造公司）释出了另外一个比较大的补丁。就像我们刚

启动 Django 项目的 11 月份时候他们做的一样。第一件闪过我们脑海的事情是，我们在 11月份的时候差点没当机。这次和上次差不多，我们的网站应该能顶住压 力。大概 12 个小时以后我们才发现服务器开始受到影响。问题再次被提出：Django 是不是我们网站最好的解决方案？

感谢来自社区的很多强大的支持，在几天后的一个深夜，我们为网站部署了一些修复补丁。 The changes (which hopefully have been rolled back into Django by the time this book is released) managed to completely reassure everyone that while not everyone needs to be able to do 300 Web requests per second, the people who do, can, with Django.

Christian Hammond 提及:

Django 允許我們非常快速地建造一個復習版，並驅使我們能透過 URL，VIEW，和樣板維持著條理，有架構的，靠著所提供的內建元素，如權限管理小程式，內建的快取，和資料庫的簡化。這些功能，絕大部分都讓我們運行的很有效率。

做為一個動態[網站應用程式]，我們必須寫一堆 JavaScript 代碼。這是個 Django 沒法實際上幫我們很多忙的部分。Django 的樣板，樣板的標籤，過濾器，表單的支持都是超棒的，但是沒有辦法簡化 JavaScript 代碼。當我們想要使用一個特別的樣板或是過濾器的時候，偏偏沒法同時使用 JavaScript 代碼。我個人將會樂於看見一些有創意的解法將這部分含入 JavaScript 代碼。

团队结构

常常，成功的專案主要是因為他們的團隊，都不是他們所選的技術，我們詢問我們的 panel他們的團隊是如何運做，他們是用什麼工具和技術來讓工作上軌道。

Ned Batchelder 說:

一個非常標準的網頁開創環境:Trac/SVN,良好的程式員。我們有一個測式主機，一個產品主機，一個 ad hoc 發布指令稿。就這些。

記憶體快取很重要。 Johannes Beigel 說:

我們使用 Trac 當我們的臭蟲追蹤器和維基。然後最近將它們從 Subversion+SVK 切換到

Mercurial(一個 Python 寫的分散式的版本控制系統，來管理分枝和合併，很棒)

我想我們有一個非常敏捷的開發過程，但是我們沒有遵守嚴格的方法論像極限編程寫的(即使我們借用了很多點子從那裏)。我們比較像是 Pragmatic 程式員。

我们有一个自动编译系统（基于定制过的 SCons）和对几乎所有东西的单元测试。 David Cramer 論及:

我们的团队有 4 个 web 开发人员构成，这 4 个人都在同一个办公室工作，所以我们彼此沟通交流是很方便和容易的。我们彼此共同使用一些工具，如：SVN 和 Trac.

Christian Hammond 述道:

復習板實際上有兩個主要開發者(我和 David Trowbridge)和一堆貢獻者。我們將站點放在 Google Code 利用他們的 Subversion 源碼倉庫，事件追蹤器，和維基。我們實際上使用復習版是要復習我們的改變。我們先在自己的本地主機測試，也有手動和單元測 試。我們的使用者在 VMware 上每天用復習板提供一堆有用的回饋和臭蟲報告，讓我們可以試著這些成果整合進來。

部署

Django 的开发者很严肃认真的对待如何简化部署及系统的扩展(scaling)，因此我们重视很乐意的听到现实情况里有关系统部署和拓展（scaling）的一些让你麻烦和很难处理的问题。

Ned Batchelder 提及:

我們已經使用快取在查詢和回應層，藉此來加快回應時間。我們有一個古典的設定組態方式:一個多重的主機，很多個應用伺服器，一個資料庫主機。目前這種架構運作良好，因為我們可以使用快取在應用伺服器來避免資料庫存取，然後加上應用伺服器，就需求上來應付流量

Johannes Beigel 言及:

Linux 主機，尤其是偏好 Debian,搭載很多的(gigs)記憶，Lighttpd 當作網站伺服 器，Pound當作 HTTPS 前端和負載平衡器，假如需要的話，而 Memcached 當做快取。SQLite 用做小型的資料庫，假如資料量成長太快就用 Postgres ，高度的規格化客製資料庫是我們的尋找和知識管理的元件。

David Cramer 提及:

我们的结构还有待讨论，但目前就是这个样子的。

當一個使用者要求這個網站，它們會被傳送到 Squid (使用 lighttpd)的叢集主機。在那裏，主機會檢查是否使用已經登入。假如不是，他們會招待一個快取頁面。一個已登入的使用者會被引導到一個網站主 機(跑著 lighttpd 加上 mod_python(每一個都擁有大量的記憶體))構成的叢集，依靠者分散式的 Memcached 系統和超強的 MySQL 資料庫主機。靜態的內容是存放在由 lighttpd 組成的叢集。多媒體，如大的影音檔，通常是放在用超小的 Django 加上

lighttpd 和 fastcgi。現在這些都移往，推向所有多某體到一個服務，類似 Amazons S3。 Christian Hammond

这里现在有两个主要的产品级服务器。一个是运行在VMware 里，包括了一个运行在VMware ESX里的 Ubuntu 虚拟机。我们使用 MySQL 作为数据库，Memcached 作为后端缓存，和流行的 Apache作为 Web 服务器。我们有一些在我 们需要的时候能够有助于我们扩大规模的强劲服务器。当我们的用户增多的时候，我们可以把 MySQ 或者 Memcached 移到其他的虚拟机上。

第二个生产服务器就是用于 Review Board 的那个。它的设置和虚拟机里面的那个是完全一样的，唯一差别就是虚拟机是运行在 VMware 服务器上的。