《PaaS程序设计》一2.3 PaaS：综合两种方式的最佳方案

本节书摘来自华章出版社《paas程序设计》一书中的第2章，第2.3节，作者 lucas carlson，更多章节内容可以访问云栖社区“华章计算机”公众号查看

对于开发者来说，通常会以共享主机的方式起步。很快，就会经历需要更强的功能和控制的阶段，于是，就会转向独立主机托管。在完全拥有了控制权之后，你可能会感到很惬意，也会很兴奋，因为你可以对服务器进行调整和优化，让它们运行得更快，网站可以更快地的被加载，并且可以处理更多的用户请求。

然后，随着时间的流逝，兴奋感很快就会烟消云散，因为日复一日维护服务器所增加的负担，会让人筋疲力尽。独立服务器可以提供更强的功能和控制，但是很容易就会遭受攻击，而作为开发者，你必须自己解决这些问题。在数据库被破坏了的时候，还得自己去使用备份数据进行恢复。

而且，还有更多问题！而不仅仅是需要花费时间和精力来管理这些机器。如果服务器在凌晨4点宕机（通常会在这些非常不方便的时间发生），你必须完全负责去修复它。即使你在吃晚饭、在参加婚礼或者在度假，你也得去修复机器。这就是寻呼机存在的理由—为了找到医生和系统管理员。

简而言之，对于开发者来说，共享web主机很容易，但是无法提供足够的控制和功能；而独立主机虽然功能强大，但是也带来了很多麻烦和不必要的负担。在平台即服务出现之前，没有任何折中的方案可以选择。

于是，结合独立主机托管的强大功能和共享主机的易用性，我们便得到了平台即服务。

让我们简单回顾一下这个例子，由于新增的电视节目，导致网络流量地爆发增长。采用专用服务器托管时，就必须从1台服务器增加到100台服务器。这将是一个梦魇，因为我们可能需要雇佣一个团队来管理这些服务器。但是采用平台即服务的方案，则只需要将滚动条从左边移动到右边，数秒钟之内就可以将服务器增加到100台。

就像我们所看到的那样，平台即服务提供了专用主机所拥有的强大的能力、速度、可靠性以及可扩展性，同时也如同共享主机那样简单易用。因此，我们可以说，平台即服务是开发者的可扩展性和可靠性的圣杯。

同时这一增强的可靠性也带来了另外一项好处，那就是作为可扩展架构的关键原则之一，应用于现代web开发领域的n层架构。

采用n层应用架构，我们就不需要将应用的逻辑与数据库服务器，或者缓存服务器或者负载均衡服务器放置在一起。因为，可以采用不同层次的服务器来独立地处理应用程序的不同的方面。

这样就实现了垂直方向的扩展，从而可以通过增加更多某种类型的服务器来增加运算能力， 这些服务器并行运行，并通过软件的配置实现负载的分发。于是，我们就从原来的单一服务器，到现在拥有了至少三层或者四层的服务器，或者层次。在每一层中，我们都得以复制失效恢复和高可用性。

而在采用专用服务器的时候，通常需要东拼西凑才最终得以实现类似的架构。每一个平台即服务的方案都从开始就拥有内置的n个层次。这些层次被打包成产品，并在刚开始的时候就成为一种事实上的标准，将专用web主机与一种简单的部署应用代码策略组合成一种最佳方法。

有多种不同的方法来实现平台即服务。一些供应商专注于某种单一的编程语言，就是说，开发者被限制于应用特定的语言。比如java、php、python或者node.js。

也有些供应商提供多种不同的语言以供选择。一方面来看，多语言供应商可以提供一站式服务的好处，而另外一个方面，单语言的平台即服务供应商则常常可以提供高度优化的系统环境。总的来说，应用最广泛的paas系统通常都是多语言的。

作为开发者，大家还需要注意供应商锁定问题。某些平台即服务供应商要求应用系统编程的时候，使用他们的应用编程接口（api），因此，一旦将代码绑定到他们的api之后，就很难移植到其他的平台了。如果这只是简单的在数据库服务的层面上，应用的代码还可以保持不错的可移植性。但是，如果使用了供应商定制的库或者定制的应用编程接口，就很难将这些集成点切分成相对独立的点，因此，难以将应用程序移植到其他paas平台。

几乎所有的平台即服务供应商总会让人免费尝试。通常，我们可以至少免费地建立一些应用程序。对于开发者来说，这通常是非常有用的，因为可以通过尝试熟悉平台即服务。在准备部署产品应用的时候，我们就会有很多不同的选择，这些定价模型通常依据所选择的不同平台有很大的不同。paas部署产品应用的价格可能从每月只有20美元到每月上万美元。

例如，采用某个业界领先的paas供应商的服务时，通常可以免费地部署应用。但是，当需要扩展应用，并增加更多实例的时候（让应用进入产品准备阶段），可能就得按照每个实例支付费用，每个实例大约每月30～40美元。如果还需要备份服务，就还需要每月增加30～40美元的费用。因此，对于某些平台即服务供应商来说，支付的成本可能随着应用的扩展而迅速增加。

其他的平台会采用不同的定价模型。有些按照实际使用的虚拟机数量收费，也有些按照某个资源消耗模型收费。采用appfog，开发者就拥有一定数量的ram，基于这些ram可以按照需要部署特定数量的应用，或者一定数量的实例以运行这些应用。按照每个月使用多少ram支付费用，而不是如何使用付费。docould也采用类似的模式。

这里有好几个问题。平台即服务是个新的概念吗？或者它只是基础设施即服务的一种扩展？这一“伟大构想”是否是按需提供的服务器加上api的概念组合？或者平台即服务是一个全新的，完全不同的思想？

有足够的证据表明iaas和paas各不相同，而且平台即服务并不是基础设施即服务的一个特性。归根到底，问题是对于每种服务来说，什么是重要的。

在iaas和paas背后的核心概念是什么？换种方式说：什么是它们的基础单元？

基础单元

一个基础单元就是所研究实体的最小的不可分解的单元。什么是最小的公共元素？什么才是人们所关心的基础的、不可分割的方面？数学上，就是数（或者更为基础的集合）。物理上，就是方程。化学上，就是分子。而在生物学上，就是细胞。

这一概念也同样适用于商业世界。对于麦当劳来说，就是汉堡。对于巴诺（barnes&nobel）书店，就是书。对于可口可乐，就是一听可乐。这些就是一个公司最在乎的基础单元。

搞清楚一个公司的基础单元，既有一定的启发意义，也有一定的限制性。启发性在于它可以让人更为专注，集中精力于所擅长的方面。而限制性在于很难销售任何不在公司基础单元之外的东西。很少有尝试多个基础单元的公司能够成功。

基础单元并不一定要如前面所述的那样具体。例如，对于亚马逊（amazon.com），其基础单元就是任何可以被放置在仓库中管理，并且可以被包装在一个盒子中运输的东西。对于netflix，就是多种形式的数字媒体。对于procter&gamble来说，就是居家用品。

在谈到挑选基础单元这个问题时，有很多令人困惑的地方。其中部分原因在于很多销售着不同基础单元的公司被组合到了一起。一种从根本上理清这个问题的途径，就是从一般的层面上去了解每个公司的基础单元。

iaas与paas的对比

对于基础设施即服务，基础单元就是资源。这里的资源是指服务器、磁盘、网络以及ip地址。iaas所做的一切就是按照需要提供这些资源。例如，亚马逊（amazon）的web服务，所有的工具都以资源为中心，所有的文档都是关于资源的，所有的开发都是专注于资源，同时人们也因为需要这些资源而使用它。其他一些iaas的例子还包括rackspace、gogrid以及joyent。

对于平台即服务来说，基础单元就是应用。那么什么是应用？就是一个系统。这就是代码以及所有那些在任何时候都与这些代码通讯的服务。这不仅仅是资源，事实上，一个应用是由很多单独的资源绑定在一起组成的。将所有这些资源连接在一切所需要付出的工作量通常被低估了。这就是为什么很多公司成立it部门，以及为什么系统管理员总是非常受欢迎的原因。从一个单一地运行apache和mysql的服务器转移到一个拥有单独的负载均衡服务器、缓存服务器、应用服务器、数据库服务器以及冗余的失效恢复的系统架构需要大量的工作，包括前期投入以及后期维护。

利用paas可以做的另外一件事情，就是从应用的角度来管理iaas。诸如cloud formation之类的工具是非常了不起的，但它们是通过资源的角度来管理iaas。从应用的角度来管理iaas与资源完全不同。

与资源不同，应用通常不会频繁地上线下线。对于iaas来说，虽然按照实际需求每小时付费的定价模式非常有用，但通常没有那么重要，除非面对应用的爆发式增长或者在一个测试或开发场景中。

简单地说，平台即服务供应商面对的是代码和服务。这些供应商的职责就是管理和维护代码、运行服务并且确保在任何时候，所有的一切能正常连接并正常工作。