烘烤后端

本文是翻译,版权归原作者所有


在阅读本文之前,请花点儿时间看看你的智能手机面板,找到你使用最多的应用。他们有什么共通之处吗?考虑一下,或者做个猜想:打开飞行模式。事实上:所有程序都不能使用了。这是因为每个应用都依托一台服务器。

烘烤后端

感谢我们有幸设计的各种移动产品,我们意识到,优秀用户体验的高质量和感觉,在移动界面之类的前端和产品服务器部分的后端之间,有着一种相互依存的关系。

这就是我们今天为什么要花时间向你展示,我们在 Applidium 是如何烘焙一个移动为中心的后端。

你在后端堆放了什么?

你在后端堆放了什么层

和通常的软件工程一样,后端是这样一个区域,它就运行原理给出了丰富的画面,这需要一千篇文章才能说清楚。我们这里仅聚焦在主要层,把其它后端选择放在将来的文章里。

web 服务器

web服务器层

web 服务器是负责后端客户网络端的层,它只是和一个客户端建立连接。它确保客户端发送的所有东西能够达到下一层,下一层的所有响应被传输到客户端。

然而,真实情况不是这样简单。首先,不管你的客户端采用何种方式,它们在请求服务器之前不会等待上一个请求。然后,由于你比较聪明,每小时不会只有几个,而是成千上万个(或者更多)。最后,它们对你的服务渴望太多,甚至在通勤(commuting)时还在请求。通勤意味着连接数不够,这意味着连接要比平时花更长时间,意味着你的服务器忙于等待我们所称作的:慢客户端。

面对这三个挑战,web 服务器设计了诸如缓存或并发连接的策略。然而,每条策略在提供的服务和资源消耗之间是一种折衷,然后你不得不选择适合你需求的服务器实现。

我们的选择:Phusion Passenger

因为大多数 Rails 社区(特别是 Rails Core Team),我们选择了 Passenger【注1】。它是真正的并发、节约内存、与 Nginx 深度集成,有趣的是它显著加快了静态资源的请求。考虑到 web 应用程序大都是托管在硬件有限的实例上,所有这些特点让 Passenger 成为了我们的选择。

web 应用框架

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 分享给我们吧。

译文:烘烤后端 》| 腊八粥