转载

烘烤后端

　　英文原文：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 是足够稳定的，那么它对于你也应该是稳定的。

开源：使用开源框架，当我们寻找具体行为的解释、或我们想用手动特性来增强框架时，我们可以浏览源代码。
迅捷安装：开发一个面向移动 app 的 webservice，是一种练习，一个技能是至关重要的，也是一种反应。我们的客户热切希望我们能够按天为单位发布或更新 API。在这个角度，Ruby on Rails 带来了约定优于配置（COC）的理念，领先于其竞争者的开发速度。
生态系统的力量：开发者今天能够遇到的大部分高级问题，某种程度上都已经被解决了。这样，其特性不仅仅定义了框架的质量，还有这么多年其社区所开发的资源库。在这方面，Rails 利用了 Ruby 的优势和大量的包管理工具 RubyGems。
开发者吸引力：Applidium 工程师，是敏感的人群，我们明白，享受工作的开发者一定可以更好地工作。在这个层面，Ruby 提供了一种语法，与 Rails 的约定一道，让我们更快乐

　　数据库

烘烤后端

　　与之前的两个层相反，这一层对于非技术人员也是相当熟悉的。差不多每个人都知道网站后面有一个数据库。正如名字所表示的，这一层负责存储所有的永久数据。

　　传统上，这种数据存储后，你能借助流行的搜索查询语言（SQL）以强大的方式请求。然而，为了能够提高这些请求的性能，数据库不得不使数据以关系型排序，这在性能方面代价很高，需要在独立机器上托管数据库。随着大型数据库的出现，人们开始接触 NoSQL，为了更好的性能和扩展的能力，牺牲掉了某些请求特性。

　　除了在 SQL 和 NoSQL 之间选择，数据库层的标准使得现有解决方案相当类似。不同点在于细节，你可以选择一种解决方案，而不用惧怕危害到项目的成功。

　　我们的选择：PostgreSQL

　　当我们把 Rails 做为框架时，我们坚持选择三种原生支持的数据库系统之一：SQLite、MySQL、PostgreSQL。SQLite 是 Rails 默认数据库，然而它不适合生产环境应用程序，因为它独特的基于文件的性质。在 MySQL 和 PostgreSQL 之间选择不太容易，因为两者在性能和功能上非常接近。然而，考虑到运行每个项目的社区，PostgreSQL 的独立和声誉对其有利。

　　主机

烘烤后端