Uploadcare如何构建每天处理350M文件API请求的服务堆栈

Python部落(python.freelycode.com)组织翻译，禁止转载，欢迎转发。

Uploadcare是一种文件基础设施即服务解决方案。我们为处理文件提供预制构建，为管理复杂技术提供简单的控件。这些控件包括widget，Upload API，REST API和CDN API。这些API每天一共要处理350M的请求。

只需几行代码即可上传，存储，处理，缓存和交付文件。我们支持Dropbox，Facebook和许多其他外部来源上传。我们还允许用户将文件直接上传到他们的存储空间中。

是的，你可以自己处理文件，你可以搭建基本的系统并运行地很快。但是存储怎么样？正常运作吗？ 是否有清晰友好的用户界面？ 能否快速交付到偏远地区？ 我们分析了大多数用例，发现投资开发自己的文件基础设施是没有意义的。

设置Uploadcare很快，解决了用户通常在处理大文件和批量文件时遇到的许多问题。此外，用户不再需要在每个浏览器中测试系统并维护基础设施。

ploadcare利用AWS构建了无限可扩展的基础设施。建立在AWS之上，每天可以处理350M的文件上传，操作和交付请求。在2011年开始时，AWS唯一的云替代方案是Google App Engine，我们不想构建相当复杂的解决方案。我们也不想购买任何硬件或使用合作点。

我们的堆栈处理接收文件，与外部文件源通信，管理文件存储，管理用户和文件数据，处理文件，文件缓存和分发以及管理用户界面仪表板。

从一开始，我们基于微服务架构构建了Uploadcare。

这些是我们在堆栈的每一层面临的挑战。

后端

Uploadcare的核心是运行在Python上。在佛罗伦萨的Europython 2011会议真正启发了我们，再加上事实是Python足以解决我们所有的挑战。另外之前我们还有在Python中工作的经验。

我们选择使用Django构建主要应用程序，因为它在Python生态系统中的具有举足轻重的地位并且功能十分完整。我们的生态系统内的所有通信都通过几个HTTP API，Redis，Amazon S3和Amazon DynamoDB进行。我们决定使用这种架构，以便我们的系统可以在存储和数据库吞吐量方面进行扩展。这样我们只需要在数据库集群之上运行Django。我们使用PostgreSQL作为数据库，因为当提到集群和扩展时，它被认为是行业标准。

上传，外部源

Uploadcare允许用户使用小部件上传文件。我们支持多个上传源，包括仅需要URL的API。

上传的文件由Django应用程序接收，大部分由Celery完成。它很适合处理队列，它拥有一个强大的社区和大量的教程和示例。Celery处理上传大文件，从不同的上传源检索文件，存储文件，并将文件交付到Amazon S3。与外部源的所有通信都由单独的Amazon EC2实例来处理，负载均衡由AWS弹性负载平衡器处理。负责上传的EC2实例与应用程序的其余应用保持分开。

当我们在保留资源以降低成本和提高效率时，在AWS中遇到的两个问题是：AWS状态页面报告不准确，并且未能提前计划。

文件存储，用户和文件数据

我们使用Amazon S3进行存储。EC2上传实例，REST API和处理层都与S3直接通信。如果他们愿意的话，S3让我们能够永久存储客户档案。

文件和用户数据由高度定制的Django REST框架进行管理。起初我们使用了开箱即用的Django REST框架，因为它帮助我们快速部署功能。然而，随着我们对REST API应如何工作的展望，我们对它实施了定制来适应我们的用例。我们的定制添加的代码越来越多，从而导致更新框架变成了一个痛点。我们正在寻求修改堆栈的这一部分，以避免添加进一步定制框架时，使这个问题复杂化。

我们使用微型框架Flask来处理敏感数据和OAuth通信。它是轻量级和高效的框架，同时不包括我们不需要的任何功能，如队列，ORM层或高速缓存。

我们在博客上关于云安全的文章中更详细地探讨了这个话题，解释了Uploadcare如何从社交媒体获取内容，以及如何处理最终用户隐私。

处理

我们每天处理的350M API请求包括许多处理任务，例如图像增强，调整大小，过滤，面部识别和GIF到视频转换。

我们的文件处理要求需要使用异步框架进行IO绑定任务。Tornado是我们目前使用的，而aiohttp是我们打算在将来的生产中实施的。两个工具都支持处理大量的请求，但是aiohttp比较好，因为它使用的是asyncio，而且是Python原生的。

我们的实时图像处理是一个CPU绑定的任务。 由于Python是我们服务的核心，我们最初使用PIL，然后是Pillow。我们还在改进。当我们认为调整大小是最耗资源的操作时，我们的工程师Alex创建了名为Pillow-SIMD的叉型指令，并做了大量优化，使其比ImageMagick快15倍。优化之后，现在Uploadcare需要服务器处理的图像减少6倍。这里，通过服务器也意味着处理EC2实例和第一层缓存分离。处理实例也与ELB配对，这有助于将文件提取到CDN。

缓存，交付

有三层缓存有助于提高整体性能：

1.在处理引擎中进行缓存，从而相同的操作不会运行多次

2.CDN-Shield内的缓存，因为CDN边缘，不会影响起点，缓存更有效

3.在CDN边缘上的缓存作为最接近用户设备的边界

为了交付文件，在nginx和AWS弹性负载均衡器的帮助下，文件将被推送到Akamai CDN。我们还使用Amazon CloudFront，但由于缺乏覆盖，我们将Akamai作为默认CDN。另外Akamai还有很多很酷的功能，例如，它允许我们自动调整imagea格式然后再发给用户浏览器。

值得补充的是，我们的文件接收/交付比率有很大程度基于交付。

前端

如我们所说，对于复杂技术的简单控件不能没有整洁的UI用户区域，包括起始页，仪表板，设置和文档。

最初使用Django。早在2011年，考虑到我们以Python为中心的方法，那是最好的选择。后来，我们意识到我们需要更快地在网站上进行迭代。 导致我们从前端分离Django。那时我们决定建一个SPA。

为我们的前端页面，文档和其他网站部分构建SPA是一个持续的过程。它是通过Node.js完成的，异步的，并提供同构渲染。为了与我们较老的基于Django的前端进行通信，它通过nginx使用JSON API。 这是一个经验法则：一旦分离，我们的前端和后端之间的通信仍将通过JSON API进行。

对于构建用户界面，我们目前使用React，因为它在构建工具包时提供了最快的渲染。不仅如此：React有一个很好的社区，可以帮助你减少代码并构建更多的功能。值得一提的是，Uploadcare不是以前端为中心的SPA：我们没有把事情搞得太复杂。如果是，我们会结合Ember。

然而，有一个机会让我们转向更快的Preact，它的座右铭是使用尽可能少的代码，并且因为它更多地使用浏览器API。

在客户端，我们使用Redux.js处理数据，并通过React Router进行路由。后者是强大的React社区的一个很好的例子。

前端将来的任务之一就是配置Webpack Bundler来分解不同站点部分的代码。目前，当你加载站点页面时，你还同时会获取所有其他页面的代码。Webpack还是一个代码构建的工具，具有大量的社区示例，可用作入门套件。 我们正在考虑使用Browserify或Rollup，但是它们没有运行时，并且比Webpack工作速度慢，或者要求我们做更多的编码以提供类似的功能。 此外，异步块更容易处理Webpack。

至于静态网站页面，很多都是Markdown格式的文件，它们位于GitHub的仓库中。总的来说，我们正在使用GitHub Pull Request Model进行部署。然后，来自一个仓库的文件将通过jinja2启发的nunjucks，然后是markdown-it和posthtml。 例如，我们的文档是以这种方式构建的。

对于样式，我们使用PostCSS及其插件（如cssnano）来压缩代码。

你可能会说，我们喜欢后处理器的想法。例如，posthtml是一个解析器并提供抽象语法树的字符串，它很容易使用。

所有这一切使我们能够提供良好的用户体验，并尽可能少地使用代码，快速实现需要的更改。

部署

如上面提到的，我们使用GitHub Pull请求模型。过程中的某些部分是自动的，而其他部分需要手动干预。 我们使用以下步骤：

1.我们为一个功能在仓库中创建了一个分支

2.提交给分支。然后在TeamCity中进行自动测试

3.如果测试通过，则创建PR，然后由开发团队进行自动测试和代码审查

.如果测试通过/审查通过，我们将更改合并到分段分支，然后通过TeamCity和Chef自动部署

.部署时，我们通过TeamCity运行集成测试

.如果一切顺利，我们会将更改合并到生产分支，并通过TeamCity自动运行一次以上的测试

.如果测试通过，我们确保它不是一个星期五晚上，我们部署到生产环境。这里的主要脚本由devops运行。

我们通过Slack通道获得有关部署状态的通知。关于报告，我们从监控堆栈获得了很多输入，其中包括报告错误和异常的Rollbar，用于日志记录的LogDNA，用于外部测试我们的服务的Pingdom，用于监控AWS统计信息的Amazon CloudWatch，以及Datadog用于整合报告和监控服务器和服务的健康状况。

团队管理，任务，沟通

利用Slack，还有G Suite来发送电子邮件，Trello来制定计划，HelpScout和Intercom来与用户成功沟通并处理用户关系等。

版本

由于我们提供了完整的处理文件的预制构建，所以我们鼓励所有人在其产品的不同部分使用类似的预制构建。我们的堆栈是一个很好的例子，它是一个预制构建的组件的集合。我们可以随时继续添加更多组件。 例如，我们正在使用Segment来对发送的数据进行分析，而这些数据又由Kissmetrics，Keen IO，Intercom等进行处理。我们正在使用Stripe处理付款。

我们实践了所讲的内容：关注你想要创建的内容，并让这些预制构建处理它所做的具体任务。

英文原文：https://stackshare.io/uploadcare/how-uploadcare-built-a-stack-that-handles-350m-file-api-requests-per-day
译者：lizi

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！