英文原文：Baking back ends
在阅读本文之前，请花点儿时间看看你的智能手机面板，找到你使用最多的应用。他们有什么共通之处吗？考虑一下，或者做个猜想：打开飞行模式。事实上：所有程序都不能使用了。这是因为每个应用都依托一台服务器。
感谢我们有幸设计的各种移动产品，我们意识到，优秀用户体验的高质量和感觉，在移动界面之类的前端和产品服务器部分的后端之间，有着一种相互依存的关系。
这就是我们今天为什么要花时间向你展示，我们在 Applidium 是如何烘焙一个移动为中心的后端。
你在后端堆放了什么？
和通常的软件工程一样，后端是这样一个区域，它就运行原理给出了丰富的画面，这需要一千篇文章才能说清楚。我们这里仅聚焦在主要层，把其它后端选择放在将来的文章里。
web 服务器
web 服务器是负责后端客户网络端的层，它只是和一个客户端建立连接。它确保客户端发送的所有东西能够达到下一层，下一层的所有响应被传输到客户端。
然而，真实情况不是这样简单。首先，不管你的客户端采用何种方式，它们在请求服务器之前不会等待上一个请求。然后，由于你比较聪明，每小时不会只有几个，而是成千上万个（或者更多）。最后，它们对你的服务渴望太多，甚至在通勤（commuting）时还在请求。通勤意味着连接数不够，这意味着连接要比平时花更长时间，意味着你的服务器忙于等待我们所称作的：慢客户端。
面对这三个挑战，web 服务器设计了诸如缓存或并发连接的策略。然而，每条策略在提供的服务和资源消耗之间是一种折衷，然后你不得不选择适合你需求的服务器实现。
我们的选择：Phusion Passenger
因为大多数 Rails 社区（特别是 Rails Core Team），我们选择了 Passenger【注1】。它是真正的并发、节约内存、与 Nginx 深度集成，有趣的是它显著加快了静态资源的请求。考虑到 web 应用程序大都是托管在硬件有限的实例上，所有这些特点让 Passenger 成为了我们的选择。
web 应用框架
从服务器获取请求，这个层负责解释所有属性来理解客户端的期望并计算出响应。这层的角色因项目不同而有着巨大的差异，这也是大多数软件工程师作品出现的地方。这就是为什么宁可使用一个现成产品，调整某些参数的原因，你只需找一个框架来架构和加速你的开发。
框架，哪怕它仅被视作一种架构，也决定了很多工作。因为它耗费了大量计算，它在你的总体服务性能上发挥着关键作用。然而，依据它们的受欢迎程度，框架不等同于可获得的资源（文档、资源库）。最后，一些框架因其内部结构而不能影响到某些 web 特性（比如推送-拉取）。
选择框架绝对是你的栈选择中最大的投入。从一个框架切换到另一个框架，的确需要差不多重写你的项目。因此要花些时间来衡量每个框架的优缺点。
我们的选择：Ruby on Rails
很多框架正被积极地使用，也被活跃社区维护着。总的来说，没有最好的，不过一个框架最好能够满足你的特定期望。对于我们而言，Ruby on Rails 成为我们众多选择中的一员。
导致我们决定的因素有：
成熟度：即使我们想接触最新的技术，我们也知道一个框架需要时间来证明其稳定程度。于 2004 年面世，Ruby on Rails 每年都在增长，时至今日，已经变成了使用最广泛的框架之一。如果它对于 Github 或 Basecamp 是足够稳定的，那么它对于你也应该是稳定的。
数据库
与之前的两个层相反，这一层对于非技术人员也是相当熟悉的。差不多每个人都知道网站后面有一个数据库。正如名字所表示的，这一层负责存储所有的永久数据。
传统上，这种数据存储后，你能借助流行的搜索查询语言（SQL）以强大的方式请求。然而，为了能够提高这些请求的性能，数据库不得不使数据以关系型排序，这在性能方面代价很高，需要在独立机器上托管数据库。随着大型数据库的出现，人们开始接触 NoSQL，为了更好的性能和扩展的能力，牺牲掉了某些请求特性。
除了在 SQL 和 NoSQL 之间选择，数据库层的标准使得现有解决方案相当类似。不同点在于细节，你可以选择一种解决方案，而不用惧怕危害到项目的成功。
我们的选择：PostgreSQL
当我们把 Rails 做为框架时，我们坚持选择三种原生支持的数据库系统之一：SQLite、MySQL、PostgreSQL。SQLite 是 Rails 默认数据库，然而它不适合生产环境应用程序，因为它独特的基于文件的性质。在 MySQL 和 PostgreSQL 之间选择不太容易，因为两者在性能和功能上非常接近。然而，考虑到运行每个项目的社区，PostgreSQL 的独立和声誉对其有利。
主机
前三个层只是涉及到了后端软件部分，但是最终，它们都需要运行在硬件上。如果你可以像过去一样，在地下室部署自己的服务器，那么你当下更喜欢使用外边的这项服务。
首先，硬件会出错。现在标准的运行时间是 99.99%，从内部达到这一点可能需要大量硬件投入（比如每个单点故障的冗余）。其次，你能够求助万能的云。
你给云提供商一份应用程序的镜像，你来决定应该在云中运行多少该镜像的实例。你不再受限于那些以前需要安装配置的物理机，你只需移动鼠标来生成应用程序的新实例。这样它就提供了巨大的灵活性，根据你的服务费用的发展，你可以精确地为你需要的东东付费。
我们的选择：Heroku
鉴于云计算的民主化，人们倾向于认为，主机复杂程度完全由云提供商处理。他们的确在处理着所有的硬件问题，开发者仍然需要管理主机的软件部分。
这就是为什么在经典的云计算服务之上，一些公司会开发处理某些软件复杂部分的平台。它们比简单的云提供商要贵一些，以此交换那些花费开发者的单调、耗时的软件维护操作。经常被看做是剩余成本，那些平台的费用最终远远少于开发者花在维护 web 应用上的大量时间。
根据我们已经浏览和体验过的所有平台，Heroku 无疑是这种游戏里最知名的玩家，它是我们的首选：
Amazon 云，一个行业标杆，支持 Heroku，因此它提供了最好的可用率。
Heroku 每年都在支持更多的技术，今天它包含了所有我们选择的技术，我们下一次采用它的机会仍然很高。
对于中等规模的项目，它提供了巨大的比率，即节约的开发时间除以账单的费用。Heroku 的确是 EC2 价格的两倍，看起来多了不少。但是当你的项目仅需要一些实例时，这种付费难以达到一个开发者每月一小时的成本，至少节约了一天的时间。
Heroku 的流行程度决定了插件生态系统已经发展得很好了。今天它已经平滑地集成到了平台，它给开发者提供了大量的优质服务，一个命令就可以添加到项目中。
我们安装的后端大部分都服务于多媒体内容。不管是考虑性能、还是月底的账单，这都不是你想托管在经典服务器上的那种内容，而是在文件存储服务上。Heroku 基于 Amazon 云，你可以在服务器、文件存储服务引用、Amazon S3 之间节省所有迁移成本。
结论
强大的成熟技术选择、加上我们对后端的娴熟，今天我们能够为客户提供快速、可靠的面向移动的后端配置。我们不得不承认，我们没有致力于最便宜的解决方案，我们更看重可扩展性和可移植性。
而且，我们对新组件保持关注，它或许在不久的将来得到发展，牢记：一个持续的应用只是一种格式良好的、实时数据流。
这就是我们烘烤美味后端的方式。你呢，你的烹饪秘诀是什么？在 Twitter @applidium 分享给我们吧。
— END —
译文： 《烘烤后端 》 腊八粥
相关文章
