Instagram 目前部署了世界上最大规模的 Django Web 框架（该框架完全使用 Python 编写）。我们最初选用 Python 是因为它久负盛名的简洁性与实用性，这非常符合我们的哲学思想——“先做简单的事情”。但简洁性也会带来效率方面的折衷。Instagram 的规模在过去两年中已经翻番，并且最近已突破 5 亿用户，所以急需最大程度地提升 web 服务效率以便我们的平台能够继续顺利地扩大。在过去的一年，我们已经将 效率计划 （ efficiency program ） 提上日程，并在过去的六个月，我们已经能够做到无需向我们的 Django 层 （ Django tiers ） 添加新的容量来维持我们的用户增长。我们将在本文分享一些由我们构建的工具以及如何使用它们来优化我们的日常部署流程。

为何需要提升效率？

Instagram，正如所有的软件，受限于像服务器和数据中心能源这样的物理限制。鉴于这些限制，在我们的效率计划中有两个我们希望实现的主要目标：

1. Instagram 应当能够利用持续代码发布正常地提供通信服务，防止因为自然灾害、区域性网络问题等造成某一个数据中心区丢失。
2. Instagram 应当能够自由地滚动发布新产品和新功能，不必因容量而受阻。

想要实现这些目标，我们意识到我们需要持续不断地监控我们的系统并与 回归 （ regressions ） 进行战斗。

定义效率

Web services 的瓶颈通常在于每台服务器上可用的 CPU 时间。在这种环境下，效率就意味着利用相同的 CPU 资源完成更多的任务，也就是说， 每秒处理更多的用户请求 （ requests per second，RPS ） 。当我们寻找优化方法时，我们面临的第一个最大的挑战就是尝试量化我们当前的效率。到目前为止，我们一直在使用“每次请求的平均 CPU 时间”来评估效率，但使用这种指标也有其固有限制：

1. 设备多样性。使用 CPU 时间来测量 CPU 资源并非理想方案，因为它同时受到 CPU 型号与 CPU 负载的影响。
2. 请求影响数据。测量每次请求的 CPU 资源并非理想方案，因为在使用 每次请求测量 （ per-request measurement ） 方案时，添加或移除轻量级或重量级的请求也会影响到效率指标。

相对于 CPU 时间来说，CPU 指令是一种更好的指标，因为对于相同的请求，它会报告相同的数字，不管 CPU 型号和 CPU 负载情况如何。我们选择使用了一种叫做” 每个活动用户 （ per active user ） “的指标，而不是将我们所有的数据关联到每个用户请求上。我们最终采用“ 每个活动用户在高峰期间的 CPU 指令 （ CPU instruction per active user during peak minute ） ”来测量效率。我们建立好新的度量标准后，下一步就是通过对 Django 的分析来更多的了解一下我们的回归。

Django web services 分析

通过分析我们的 Django web services，我们希望回答两个主要问题：

1. CPU 回归会发生吗？
2. 是什么导致了 CPU 回归发生以及我们该怎样修复它？

想要回答第一个问题，我们需要追踪“ 每个活动用户的 CPU 指令 （ CPU-instruction-per-active-user ） ”指标。如果该指标增加，我们就知道已经发生了一次 CPU 回归。

我们为此构建的工具叫做 Dynostats。Dynostats 利用 Django 中间件以一定的速率采样用户请求，记录关键的效率以及性能指标，例如 CPU 总指令数、端到端请求时延、花费在访问内存缓存（memcache）和数据库服务的时间等。另一方面，每个请求都有很多可用于聚合的 元数据 （ metadata ） ，例如端点名称、HTTP 请求返回码、服务该请求的服务器名称以及请求中最新提交的 哈希值 （ hash ） 。对于单个请求记录来说，有两个方面非常强大，因为我们可以在不同的维度上进行切割，那将帮助我们减少任何导致 CPU 回归的原因。例如，我们可以根据它们的端点名称聚合所有请求，正如下面的时间序列图所示，从图中可以清晰地看出在特定端点上是否发生了回归。

CPU 指令对测量效率很重要——当然，它们也很难获得。Python 并没有支持直接访问 CPU 硬件计数器（CPU 硬件计数器是指可编程 CPU 寄存器，用于测量性能指标，例如 CPU 指令）的公共库。另一方面，Linux 内核提供了 perf_event_open 系统调用。通过 Python ctypes 桥接技术能够让我们调用标准 C 库的系统调用函数 syscall，它也为我们提供了兼容 C 的数据类型，从而可以编程硬件计数器并从它们读取数据。

使用 Dynostats，我们已经可以找出 CPU 回归，并探究 CPU 回归发生的原因，例如哪个端点受到的影响最多，谁提交了真正会导致 CPU 回归的变更等。然而，当开发者收到他们的变更已经导致一次 CPU 回归发生的通知时，他们通常难以找出问题所在。如果问题很明显，那么回归可能就不会一开始就被提交！

这就是为何我们需要一个 Python 分析器，（一旦 Dynostats 发现了它）从而使开发者能够使用它找出回归发生的根本原因。不同于白手起家，我们决定对一个现成的 Python 分析器 cProfile 做适当的修改。cProfile 模块通常会提供一个统计集合来描述程序不同的部分执行时间和执行频率。我们将 cProfile 的 定时器 （ timer ） 替换成了一个从硬件计数器读取的 CPU 指令计数器，以此取代对时间的测量。我们在采样请求后产生数据并把数据发送到数据流水线。我们也会发送一些我们在 Dynostats 所拥有的类似元数据，例如服务器名称、集群、区域、端点名称等。

在数据流水线的另一边，我们创建了一个消费数据的 尾随者 （ tailer ） 。尾随者的主要功能是解析 cProfile 的统计数据并创建能够表示 Python 函数级别的 CPU 指令的实体。如此，我们能够通过 Python 函数来聚合 CPU 指令，从而更加方便地找出是什么函数导致了 CPU 回归。

监控与警报机制

在 Instagram，我们每天部署 30-50 次后端服务。这些部署中的任何一个都能发生 CPU 回归的问题。因为每次发生通常都包含至少一个 差异 （ diff ） ，所以找出任何回归是很容易的。我们的效率监控机制包括在每次发布前后都会在 Dynostats 中扫描 CPU 指令，并且当变更超出某个阈值时发出警告。对于长期会发生 CPU 回归的情况，我们也有一个探测器为负载最繁重的端点提供日常和每周的变更扫描。

部署新的变更并非触发一次 CPU 回归的唯一情况。在许多情况下，新的功能和新的代码路径都由 全局环境变量 （ global environment variables，GEV ） 控制。 在一个计划好的时间表上，给一部分用户发布新功能是很常见事情。我们在 Dynostats 和 cProfile 统计数据中为每个请求添加了这个信息作为额外的元数据字段。按这些字段将请求分组可以找出由全局环境变量（GEV）改变导致的可能的 CPU 回归问题。这让我们能够在它们对性能造成影响前就捕获到 CPU 回归。

接下来是什么？

Dynostats 和我们定制的 cProfile，以及我们建立的支持它们的监控和警报机制能够有效地找出大多数导致 CPU 回归的元凶。这些进展已经帮助我们恢复了超过 50% 的不必要的 CPU 回归，否则我们就根本不会知道。

我们仍然还有一些可以提升的方面，并很容易将它们地加入到 Instagram 的日常部署流程中：

1. CPU 指令指标应该要比其它指标如 CPU 时间更加稳定，但我们仍然观察了让我们头疼的差异。保持“ 信噪比 （ signal:noise ratio ） ”合理地低是非常重要的，这样开发者们就可以集中于真实的回归上。这可以通过引入 置信区间 （ confidence intervals ） 的概念来提升，并在信噪比过高时发出警报。针对不同的端点，变化的阈值也可以设置为不同值。
2. 通过更改 GEV 来探测 CPU 回归的一个限制就是我们要在 Dynostats 中手动启用这些比较的日志输出。当 GEV 的数量逐渐增加，开发了越来越多的功能，这就不便于扩展了。相反，我们能够利用一个自动化框架来调度这些比较的日志输出，并对所有的 GEV 进行遍历，然后当检查到回归时就发出警告。
3. cProfile 需要一些增强以便更好地处理封装函数以及它们的子函数。

鉴于我们在为 Instagram 的 web service 构建效率框架中所投入的工作，所以我们对于将来使用 Python 继续扩展我们的服务很有信心。我们也开始向 Python 语言本身投入更多，并且开始探索从 Python 2 转移 Python 3 之道。我们将会继续探索并做更多的实验以继续提升基础设施与开发者效率，我们期待着很快能够分享更多的经验。

本文作者 Min Ni 是 Instagram 的软件工程师。

（题图来自：nostarch.com）

via: https://engineering.instagram.com/web-service-efficiency-at-instagram-with-python-4976d078e366#.tiakuoi4p

作者：Min Ni 译者：ChrisLeeGit 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Django 围绕“可重用应用”的思想建立：自包含的包提供了可重复使用的特性。你可以将这些可重用应用组装起来，在加上适用于你的网站的特定代码，来搭建你自己的网站。Django 具有一个丰富多样的、由可供你使用的可重用应用组建起来的生态系统——PyPI 列出了超过 8000个 Django 应用——可你该如何知道哪些是最好的呢？

为了节省你的时间，我们总结了五个最受喜爱的 Django 应用。它们是：

• Cookiecutter: 建立 Django 网站的最佳方式。
• Whitenoise: 最棒的静态资源服务器。
• Django Rest Framework: 使用 Django 开发 REST API 的最佳方式。
• Wagtail: 基于 Django 的最佳内容管理系统（CMS）。
• django-allauth: 提供社交账户登录的最佳应用（如 Twitter, Facebook, GitHub 等）。

我们同样推荐你看看 Django Packages，这是一个可重用 Django 应用的目录。Django Packages 将 Django 应用组织成“表格”，你可以在功能相似的不同应用之间进行比较并做出选择。你可以查看每个包中提供的特性和使用统计情况。（比如：这是 REST 工具的表格，也许可以帮助你理解我们为何推荐 Django REST Framework。

为什么你应该相信我们？

我们使用 Django 的时间几乎比任何人都长。在 Django 发布之前，我们当中的两个人（Frank 和 Jacob）就在 Lawrence Journal-World （Django 的发源地）工作（事实上，是他们两人推动了 Django 开源发布的进程）。我们在过去的八年当中运行着一个咨询公司，来建议公司怎样最好地应用 Django。

所以，我们见证了 Django 项目和社群的完整历史，我们见证了那些流行的软件包的兴起和没落。在我们三个之中，我们个人可能试用了 8000 个应用中至少一半以上，或者我们知道谁试用过这些。我们对如何使应用变得坚实可靠有着深刻的理解，并且我们对给予这些应用持久力量的来源也有着深入的了解。

建立 Django 网站的最佳方式：Cookiecutter

建立一个新项目或应用总是有些痛苦。你可以用 Django 内建的 startproject。不过，如果你像我们一样，对如何做事比较挑剔。Cookiecutter 为你提供了一个快捷简单的方式来构建项目或易于重用的应用模板，从而解决了这个问题。一个简单的例子：键入 pip install cookiecutter，然后在命令行中运行以下命令：

$ cookiecutter https://github.com/marcofucci/cookiecutter-simple-django

接下来你需要回答几个简单的问题，比如你的项目名称、 目录 （ repo ） 、作者名字、E-Mail 和其他几个关于配置的小问题。这些能够帮你补充项目相关的细节。我们使用最最原始的 “foo” 作为我们的目录名称。所以 cokkiecutter 在子目录 “foo” 下建立了一个简单的 Django 项目。

如果你在 “foo” 项目中闲逛，你会看见你刚刚选择的其它设置已通过模板，连同所需的子目录一同嵌入到文件当中。这个“模板”在我们刚刚在执行 cookiecutter 命令时输入的唯一一个参数 Github 仓库 URL 中定义。这个样例工程使用了一个 Github 远程仓库作为模板；不过你也可以使用本地的模板，这在建立非重用项目时非常有用。

我们认为 cookiecutter 是一个极棒的 Django 包，但是，事实上其实它在面对纯 Python 甚至非 Python 相关需求时也极为有用。你能够将所有文件以一种可重复的方式精确地摆放在任何位置上，使得 cookiecutter 成为了一个简化（DRY）工作流程的极佳工具。

最棒的静态资源服务器：Whitenoise

多年来，托管网站的静态资源——图片、Javascript、CSS——都是一件很痛苦的事情。Django 内建的 django.views.static.serve 视图，就像 Django 文章所述的那样，“在生产环境中不可靠，所以只应为开发环境的提供辅助功能。”但使用一个“真正的” Web 服务器，如 NGINX 或者借助 CDN 来托管媒体资源，配置起来会比较困难。

Whitenoice 很简洁地解决了这个问题。它可以像在开发环境那样轻易地在生产环境中设置静态服务器，并且针对生产环境进行了加固和优化。它的设置方法极为简单：

1. 确保你在使用 Django 的 contrib.staticfiles 应用，并确认你在配置文件中正确设置了 STATIC_ROOT 变量。
2. 在 wsgi.py 文件中启用 Whitenoise:

from django.core.wsgi import get_wsgi_application
from whitenoise.django import DjangoWhiteNoise

application = get_wsgi_application()
application = DjangoWhiteNoise(application)

配置它真的就这么简单！对于大型应用，你可能想要使用一个专用的媒体服务器和/或一个 CDN，但对于大多数小型或中型 Django 网站，Whitenoise 已经足够强大。

如需查看更多关于 Whitenoise 的信息，请查看文档。

开发 REST API 的最佳工具：Django REST Framework

REST API 正在迅速成为现代 Web 应用的标准功能。 API 就是简单的使用 JSON 对话而不是 HTML，当然你可以只用 Django 做到这些。你可以制作自己的视图，设置合适的 Content-Type，然后返回 JSON 而不是渲染后的 HTML 响应。这是在像 Django Rest Framework（下称 DRF）这样的 API 框架发布之前，大多数人所做的。

如果你对 Django 的视图类很熟悉，你会觉得使用 DRF 构建 REST API 与使用它们很相似，不过 DRF 只针对特定 API 使用场景而设计。一般的 API 设置只需要一点代码，所以我们没有提供一份让你兴奋的示例代码，而是强调了一些可以让你生活的更舒适的 DRF 特性：

• 可自动预览的 API 可以使你的开发和人工测试轻而易举。你可以查看 DRF 的示例代码。你可以查看 API 响应，并且不需要你做任何事就可以支持 POST/PUT/DELETE 类型的操作。
• 便于集成各种认证方式，如 OAuth, Basic Auth, 或API Tokens。
• 内建请求速率限制。
• 当与 django-rest-swagger 组合使用时，API 文档几乎可以自动生成。
• 广泛的第三方库生态。

当然，你可以不依赖 DRF 来构建 API，但我们无法想象你不去使用 DRF 的原因。就算你不使用 DRF 的全部特性，使用一个成熟的视图库来构建你自己的 API 也会使你的 API 更加一致、完全，更能提高你的开发速度。如果你还没有开始使用 DRF, 你应该找点时间去体验一下。

基于 Django 的最佳 CMS：Wagtail

Wagtail 是当下 Django CMS（内容管理系统）世界中最受人青睐的应用，并且它的热门有足够的理由。就像大多数的 CMS 一样，它具有极佳的灵活性，可以通过简单的 Django 模型来定义不同类型的页面及其内容。使用它，你可以从零开始在几个小时而不是几天之内来和建造一个基本可以运行的内容管理系统。举一个小例子，为你公司的员工定义一个员工页面类型可以像下面一样简单：

from wagtail.wagtailcore.models import Page
from wagtail.wagtailcore.fields import RichTextField
from wagtail.wagtailadmin.edit_handlers import FieldPanel, MultiFieldPanel
from wagtail.wagtailimages.edit_handlers import ImageChooserPanel 

class StaffPage(Page):
    name = models.CharField(max_length=100)
    hire_date = models.DateField()
    bio = models.RichTextField()
    email = models.EmailField()
    headshot = models.ForeignKey('wagtailimages.Image', null=True, blank=True) 
    content_panels = Page.content_panels + [
                                FieldPanel('name'),
                                FieldPanel('hire_date'),
                                FieldPanel('email'),
                                FieldPanel('bio',classname="full"),
                                ImageChoosePanel('headshot'),
                                ] 

然而，Wagtail 真正出彩的地方在于它的灵活性及其易于使用的现代化管理页面。你可以控制不同类型的页面在哪网站的哪些区域可以访问，为页面添加复杂的附加逻辑，还天生就支持标准的适应/审批工作流。在大多数 CMS 系统中，你会在开发时在某些点上遇到困难。而使用 Wagtail 时，我们经过不懈努力找到了一个突破口，使得让我们轻易地开发出一套简洁稳定的系统，使得程序完全依照我们的想法运行。如果你对此感兴趣，我们写了一篇[深入理解 Wagtail][17。

提供社交账户登录的最佳工具：django-allauth

django-allauth 是一个能够解决你的注册和认证需求的、可重用的 Django 应用。无论你需要构建本地注册系统还是社交账户注册系统，django-allauth 都能够帮你做到。

这个应用支持多种认证体系，比如用户名或电子邮件。一旦用户注册成功，它还可以提供从无需认证到电子邮件认证的多种账户验证的策略。同时，它也支持多种社交账户和电子邮件账户。它还支持插拔式注册表单，可让用户在注册时回答一些附加问题。

django-allauth 支持多于 20 种认证提供者，包括 Facebook、Github、Google 和 Twitter。如果你发现了一个它不支持的社交网站，很有可能通过第三方插件提供该网站的接入支持。这个项目还支持自定义后端，可以支持自定义的认证方式，对每个有定制认证需求的人来说这都很棒。

django-allauth 易于配置，且有完善的文档。该项目通过了很多测试，所以你可以相信它的所有部件都会正常运作。

你有最喜爱的 Django 包吗？请在评论中告诉我们。

关于作者

Jeff Triplett 劳伦斯，堪萨斯州 http://www.jefftriplett.com/

我在 2007 年搬到了堪萨斯州的劳伦斯，在 Django 的发源地—— Lawrence Journal-World 工作。我现在在劳伦斯市的 Revolution Systems (Revsys) 工作，做一位开发者兼顾问。

我是北美 Django 运动基金会(DEFNA)的联合创始人，2015 和 2016 年 DjangoCon US 的会议主席，而且我在 Django 的发源地劳伦斯参与组织了 Django Birthday 来庆祝 Django 的 10 岁生日。

我是当地越野跑小组的成员，我喜欢篮球，我还喜欢梦见自己随着一道气流游遍美国。

Jacob Kaplan-Moss 和 Frank Wiles 也参与了本文的写作。

via: https://opensource.com/business/15/12/5-favorite-open-source-django-packages

作者：Jeff Triplett 译者：StdioA 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出