2012 年 11 月 14 日
第 10 卷，第 11 期

公寓与云

环境中的约束赋予服务能力。

Pat Helland，Salesforce.com

居住在公寓（通常称为 Condo）既有约束也有便利服务。通过明确生活方式和使用模式的限制，可以将许多住宅紧密地聚集在一起，并为住户提供诸多便利。对于那些有兴趣并愿意接受这些约束，并享受共享公共服务的人们来说，公寓生活方式可以提供巨大的价值。

同样，在云计算中，应用程序在共享基础设施上运行，可以获得灵活性和成本节约等诸多好处。为了充分利用这种安排，需要一个清晰的使用模式和约束模型，以便增强共享和礼宾服务。正是使用模式的清晰性，才能赋能新的 PaaS（平台即服务）产品，从而支持应用程序模式并提供服务，简化符合该模式的应用程序的开发和运维。

正如建筑的使用方式多种多样一样，应用程序模式的风格也多种多样。本文着眼于实施 SaaS（软件即服务）应用程序的典型模式，并展示了如何通过将应用程序约束到这种模式，从而提供许多礼宾服务，以简化基于云的应用程序的开发。

使用模式

在过去的 50 年中，为预期的使用模式建造建筑物变得越来越普遍。并非所有建筑物都符合这种模式。有些建筑的需求非常独特，它们只需要按需建造——钢铁厂、棒球场，甚至超级沃尔玛都非常专业，以至于您不能期望通过房地产经纪人找到一个。

然而，这种定制建筑正变得越来越少见，而越来越多的建筑物——无论是工业园区、零售办公室还是住宅——正以通用的方式建造，并考虑到使用模式。它们的建造都明确了如何使用，但不一定明确谁会使用它们。每个建筑物都有针对居住者的标准规范，新的居住者必须适应这个空间。

约束和礼宾服务

建筑物的使用模式可能会施加约束，但反过来也会提供共享的礼宾服务。例如，公寓住宅区会对停车、噪音水平和烧烤施加约束。居民不能在车库里进行项目或园艺项目。作为交换，总有人在场接收他们的包裹和干洗服务。他们可能拥有共享的健身设施和游泳池。当东西坏了时，会有人来修理。

办公楼可能拥有共享的浴室、复印室和大堂。建筑的工程设计通常对整个结构是通用的。为了获得这些共享的好处，租户可能需要接受固定的办公室布局，以及一些使用规则。通常，人们不能在工作场所睡觉，不能在工作场所养宠物，甚至可能对建筑有着装要求。

零售购物中心提供共享的工程、停车场、安保和公共空间。广告预算可能会使所有购物中心的租户受益。作为交换，有共同的营业时间，对允许的零售活动有限制，以及对每家商店外观的约束。

每种类型的建筑物都对使用模式施加约束，并提供礼宾服务作为交换。要享受这些好处，您需要接受这些约束。

同样，云计算通常也有某些约束，因此，可以提供礼宾服务作为回报。共享基础设施可以做些什么来使共享应用程序的生活更轻松？共享应用程序必须遵守哪些约束才能适应共享云？

什么是云计算？

云计算通过内联网或互联网交付应用程序作为服务。已经出现许多术语来描述云计算解决方案的各个层次。

• SaaS。 这指的是用户通过互联网或内联网访问应用程序的能力。 SaaS 已经存在多年了（尽管这个术语是最近才出现的）。新的变化是能够在 Web 上投射应用程序，而无需构建数据中心。

• PaaS。 这是一个新兴领域，供应商提供更高级别的应用程序服务，其目标有两个：首先，一个好的 PaaS 可以使应用程序开发更容易；其次，一个好的 PaaS 可以使云提供商更容易有效地共享资源，并为应用程序提供礼宾服务。今天，PaaS 的主要例子是 Salesforce 的 Force.com⁵ 和 Google 的 App Engine²。

• IaaS（基础设施即服务）。有时称为公用事业计算，这是一种通过 Web 提供的虚拟化硬件和计算资源。 IaaS 的用户可以按需访问 VM（虚拟机）和用于支持 VM 的存储。

图 1 显示了云和 SaaS 提供商以及用户之间的关系。（该图源自加州大学伯克利分校的技术报告“Above the Clouds: A Berkeley View of Cloud Computing.”³）正如“Above the Clouds”中所观察到的，云计算有三个新方面：按需提供无限计算资源的错觉；云用户无需预先承诺；以及能够按短期付费的方式使用计算资源的能力。

云计算允许 SaaS 的部署和按需扩展，而无需构建或配置数据中心。

公有云和私有云

云是关于共享的。问题在于您是在公司内部共享，还是去找第三方提供商并跨公司共享。

在公有云中，云计算提供商拥有数据中心。其他公司按即用即付费的方式访问其计算和存储资源。这具有巨大的规模优势，但管理信任关系更具挑战性。信任确保计算资源在需要时可用（这可以称为 SLA，或服务级别协议）。此外，还存在隐私信任问题，即订阅公司需要确信其私人数据不会被窥探者访问。如果公司拥有数据中心，则证明隐私更容易。

公有云可以将共享资源投射为 VM 和低级别存储，这需要应用程序构建在看起来像是物理机池（即使它们实际上是虚拟的）之上。这将是公有云 IaaS。亚马逊的 AWS（亚马逊网络服务）¹ 是这方面的一个主要例子。

或者，在公有云 PaaS 中，可以向应用程序呈现更高级别的抽象，这些抽象允许比 VM 更细粒度的多租户。这些抽象的形状和形式正在快速演变。同样，Force.com 和 App Engine 是新兴的例子。

在私有云中，数据中心、物理机和存储都归使用它们的公司所有。共享发生在公司内部。资源的利用率可以根据不同部门和应用程序的需求而波动。共享云的规模可能小于公有云，这可能会降低共享的价值。尽管如此，它对许多公司仍然具有吸引力，因为它们不需要信任外部云提供商。到目前为止，我们只看到了私有云 IaaS。新的 PaaS 产品尚未提供给各个公司在其私有云中使用。

推动我们走向云的力量

许多力量正在促使应用程序更多地迁移到云端

数据中心经济性。 超大型数据中心可以以相对划算的價格提供计算、存储和网络服务。电力在数据中心成本中所占比例越来越大，通过将数据中心放置在廉价电力来源（如水电站大坝）附近，可以更有效地获得电力。互联网入口和出口在互联网主干线附近要便宜得多。装有数千台机器的集装箱式服务器以更低的成本提供计算和存储。服务器的共享管理节省了运营成本。所有这些都包含在数据中心的巨额价格标签中。很少有公司能够负担得起如此巨大的投资。共享（和收费）这笔巨额投资降低了成本。这为云提供商和用户都提供了经济驱动力。

共享数据。 越来越多的公司发现维护“大数据”存储具有巨大的（且意外的）价值。越来越多的企业数据被放入一个可以统一寻址并在大型计算中进行分析的存储中。在许多情况下，随着数据存储规模的增加，发现的价值也会增加。将所有企业数据存储在一个公共存储中，允许分析，并看到令人惊讶的价值，这正成为一个目标。

共享资源。 通过将计算和存储整合到共享云中，可以在保持高优先级工作强大的 SLA 的同时，实现这些资源的更高利用率。低优先级工作可以在空闲时间完成，同时在高优先级工作繁忙时被抢占。这要求资源是流动的和可互换的，以便可以将低优先级工作移开，并将资源重新分配给高优先级工作。

SaaS：前端、后端和决策支持

让我们更仔细地看看 SaaS 实施中常见的典型模式。一般来说，应用程序有两个主要部分：前端，处理传入的 Web 请求；后端，执行离线后台处理，以准备前端所需的信息。除了为前端准备数据的工作之外，后端应用程序通常还与决策支持处理共享（参见图 2）。

在典型的 SaaS 实施中，前端提供面向用户的服务，处理 Web 服务或 HTML。这种 Web 服务代码通常具有严格的 SLA，通常只有 300-500 毫秒，有时甚至更严格。后端处理消耗爬取的数据、合作伙伴馈送以及前端和其他来源生成的日志信息，并生成供前端使用的参考数据。您可能会看到产品目录和价格表作为参考数据，或者您可能会看到倒排搜索索引以支持 Google 或 Bing 搜索等系统。除了生成参考数据之外，后端处理通常还为 SaaS 所有者执行决策支持功能。这些功能允许指导业务的“假设”分析。

SaaS 应用程序中的模式：前端

本节探讨了构建 SaaS 应用程序前端部分时使用的常见模式。通过利用这些应用程序使用的模式，PaaS 管道可以提供许多非常有用的礼宾服务。

许多服务应用程序都符合某种模式

许多服务应用程序都很好地符合某种行为模式。这些应用程序的目标是实现 SaaS 应用程序的前端。传入的 Web 服务请求或 HTML 请求到达系统，并使用会话状态、其他服务和缓存的参考数据，以请求-响应模式进行处理。

前端的礼宾服务

当前端应用程序符合刚刚描述的模式的约束时，可以为应用程序提供许多礼宾服务。这些服务简化了应用程序的开发，减轻了服务的运营挑战，并促进了云资源的共享，以有效地满足为应用程序定义的 SLA。一些可能的礼宾服务包括

自动扩展。 随着工作负载的增加，将为此服务自动分配额外的服务器。当负载下降时，资源将被收回。

自动部署。 部署、迁移、故障边界和地理透明度都包含在内。应用程序完全无需关心这些。

容量规划。 这包括分析服务使用流量模式与传入用户工作负载的关系。跟踪传入用户工作负载的趋势。

资源市场。 礼宾管道自动跟踪服务直接和间接（通过调用其他服务）消耗资源的成本。这允许将共享服务的成本归属并回收到发起工作。

A/B 测试和实验。 该管道可以轻松地在部分流量上部署服务的新版本，并将结果与以前的版本进行比较。

自动缓存和数据分发。 SaaS 应用程序的后端生成供前端使用的参考数据（例如，产品目录和价格表）。此数据以可扩展的方式自动缓存，并且对参考数据中项目的更改会自动分发到缓存。

会话状态管理。 当处理与合作伙伴的每个请求时，请求可以选择记录会话状态，该状态描述了该合作伙伴正在进行的工作。这会自动管理，以便后续请求可以轻松获取状态以继续工作。会话状态管理器与动态可扩展和负载均衡的服务协同工作。它实现了应用程序的会话状态生存和容错策略。

每项礼宾服务都依赖于应用程序遵守为典型前端 SaaS 应用程序描述的使用模式的约束。

无状态请求处理

服务的传入请求被路由到能够响应请求的多个服务器之一。此时，目标服务器中没有与会话关联的状态（如果需要，稍后我们将获取它）。可以合理地认为这是一个无状态请求（至少到目前为止），并选择任何可用的服务器。

管道维护一个可以实现服务的服务器池。传入的请求被动态路由和负载均衡。随着需求的增加和减少，管道的礼宾服务可以自动增加和减少服务器的数量。

复合请求处理

通常，一个服务会调用另一个服务来完成工作。被调用的服务可能会反过来调用另一个服务。这种复合调用图可能变得非常复杂和非常深入。每个服务调用都需要完成才能构建用户的响应。随着请求的到来，工作会分散出去，进行处理，然后再次收集。 2007 年，亚马逊报告称，对其电子商务网站之一的典型请求导致超过 150 个服务请求⁴。许多 SaaS 应用程序都遵循图 3a 所示的模式

1. 请求从外部到达（Web 服务或 HTML）。

2. 服务可以选择请求其会话状态，以刷新其关于正在进行的工作的记忆。

3. 响应从会话状态管理器返回。

4. 如果需要，会咨询其他服务。

5. 其他服务响应。

6. 咨询应用程序数据缓存（由后端处理管理）。

7. 缓存的参考数据返回给服务，供其前端应用程序使用。

8. 向调用者发出响应。

SLA 和请求深度

SaaS 前端服务的请求将具有 SLA。典型的 SLA 可能是“对于 99.9% 的请求，假设流量速率为每秒 500 个请求，则响应时间为 300 毫秒”。

在构建服务时，通常使用百分位数（例如，99.9%）而不是平均值来衡量 SLA。平均值更容易设计和部署，但会导致用户不满意，因为异常情况通常非常令人恼火。

冲击堆栈底部的服务

使用复合调用图实现系统范围的 SLA 会给堆栈底部带来很大的压力。因为时间被计入调用者的 SLA，更深的堆栈意味着对 SLA 的压力更大。

在许多系统中，最低级别的服务（例如会话状态管理器和参考数据缓存）可能具有 99.9% 的时间为 5 到 10 毫秒的 SLA。图 4 显示了复合调用图可能变得非常复杂，并将大量的 SLA 压力施加到调用堆栈的下方。

简单排队论快速回顾

预期响应时间取决于最小响应时间（空系统上的响应时间）和系统的利用率。实际上，等式是

这在直觉上是有道理的。如果系统繁忙率为 50%，那么工作必须在空闲时间完成，因此需要两倍的最小时间。如果系统繁忙率为 90%，那么工作必须在 10% 的空闲时间完成，并且需要 10 倍的最小时间。

自动配置以满足 SLA

当服务的 SLA 下降时，一种解决方案是降低提供服务的服务器的利用率。这可以通过向服务器池添加更多服务器并更分散地分配工作来完成。

假设每个面向用户或面向外部的服务都有 SLA。此外，假设系统管道可以跟踪调用模式，并知道哪些内部服务被面向外部的服务调用。这意味着管道可以知道嵌套内部服务的 SLA 要求，并跟踪对堆栈深处服务的需求。

鉴于各种面向外部服务的优先需求和 SLA，管道可以增加分配给重要服务的服务器数量，并从低优先级工作中借用或窃取资源。

访问数据和状态

当请求到达服务时，它最初除了请求中到达的内容外，没有其他状态。如果需要，它可以获取会话状态和/或缓存的参考数据。

会话状态提供来自先前交互的信息，该服务在会话中进行过这些交互。它在请求开始时获取，然后在请求完成时与附加信息一起存储回去。

大多数 SaaS 应用程序使用应用程序特定的信息，这些信息在后台准备好并缓存以供前端使用。产品目录、价格表、地理信息、销售配额和处方药相互作用是参考数据的示例。缓存的参考数据通过键访问。使用键，前端内的服务可以读取数据。从前端来看，此数据是只读的。应用程序的后端部分生成对参考数据的更改（或新版本）。在 Amazon.com 零售站点上可以看到只读缓存参考数据的示例。查看任何产品页面的 ASIN（亚马逊标准识别号），这是一个 10 个字符的标识符，通常以“0”或“B”开头。这个唯一标识符是您看到的所有产品描述（包括图像）的键。

管理可扩展且可靠的状态

会话状态由会话状态 ID 键控。此 ID 在请求中传入，并用于从会话状态管理器中获取状态。会话状态的一个例子是电子商务网站上的购物车。

会话状态管理器的管道处理扩展。随着会话数量的增长，会话状态管理器会自动增加其容量。

此管道还负责会话状态的持久性。通常，持久性要求规定会话状态应在单个系统发生故障时幸存下来。这应该写入云中一组系统上的磁盘吗？应该将其保存在许多系统上的内存中以提供可接受的持久性吗？提高持久性会增加实施成本，并可能需要增加延迟以确保请求是持久的。

通常，会话状态管理器使用非常频繁，因此它必须为读取和写入提供非常严格的 SLA。 5 或 10 毫秒的保证并不罕见。这意味着等待将会话状态记录到磁盘上是不切实际的。通常，当会话状态存在于内存中的两个或三个副本上时，它会被确认为已成功写入。不久之后，它很可能会被写入磁盘。

将更改应用到后端

有时，前端请求实际上会“执行工作”并将应用程序更改应用到后端。例如，用户按下“提交”并要求完成工作。

对后端的应用程序更改可以是同步的，用户等待后端完成工作并响应请求，也可以是异步的，工作被排队并在稍后处理。

Amazon.com 提供了异步后端应用程序更改的示例。当用户按下“提交”时，前端的一部分会快速确认收到工作并回复请求已被接受。通常，后端会立即处理请求，用户在一两秒钟内收到电子邮件。有时，当后端异步处理繁忙时，电子邮件会花费 30 分钟左右。

自动服务、状态和数据

通过理解 SaaS 应用程序的使用模式，平台可以减少开发应用程序所需的工作，并增加其优势。如图 3b 所示，应用程序应该只关注其业务逻辑，而不必担心系统级问题。调用其他服务、访问缓存数据和访问会话状态的接口很容易调用。这为可扩展且健壮的 SaaS 应用程序提供了支持。

应用程序会话状态、应用程序参考数据缓存以及对其他服务的调用都可以作为礼宾服务使用。平台规定了如何访问这些服务，应用程序无需知道构建它们需要什么。通过约束应用程序功能，平台可以增加礼宾服务。

SaaS 应用程序中的模式：后端

本节探讨了典型 SaaS 应用程序的后端部分中使用的模式。后端为应用程序做了什么？它通常是如何做的？

馈送、爬取、日志记录和在线工作

SaaS 应用程序的后端接收来自多个来源的数据

爬取。 有时，后端有应用程序会查看互联网或其他系统，以查看可以提取什么内容。

数据馈送。 合作伙伴公司或部门可能会发送数据以摄取到后端系统中。

日志记录。 积累了关于前端系统行为的数据。这些日志被提交以供后端系统分析。

在线工作。 有时，前端直接调用后端以代表应用程序的前端部分执行某些工作。这可以同步（在用户等待时）或异步调用。

所有这些数据源都被馈送到后端，在那里它们被记住和处理。

数据发布和参考数据更新

许多前端应用程序使用参考数据，这些数据由 SaaS 应用程序的后端定期更新。应用程序被设计为处理可能过时的参考数据。处理参考数据的一般模型是

1. 来自合作伙伴馈送、Web 爬取或系统活动日志的传入信息到达后端。在线工作也可能刺激后端处理。

2. 后端应用程序代码将数据处理为批处理作业、延迟较短的事件处理或两者兼而有之。

3. 参考数据缓存中的新条目被分发到缓存机器。更改可能是批处理更新或增量更新产生的新版本。

4. 前端应用程序读取参考数据缓存。这些缓存逐渐更新，前端用户看到新信息。

自动化参考数据缓存

参考数据缓存是一个键值存储。这些缓存的一个易于理解的模型是在缓存中分区和复制数据。每个缓存机器通常都有一个内存存储（因为磁盘访问太慢）。随着缓存数据大小的增加，分区的数量也会增加。最初，副本的数量会增加以确保容错，然后会增加以支持来自前端的读取流量的增加。

在管道中使用完整的礼宾服务来支持这种模式是可能的。后端管道可以处理数据规模的分区（以及为增长或收缩进行重新分区）。它可以处理启动新的副本以实现读取速率扩展。此外，管道可以管理后端所做更改的分发（无论是批量还是增量）。此分发了解分区、动态重新分区以及动态分配给分区的副本数量。

图 5 说明了 SaaS 应用程序中从后端到前端的接口通常是一个键值缓存，该缓存由后端填充，并且前端只读。这种清晰的模式允许在 PaaS 系统中创建礼宾服务，从而简化这些应用程序的实施和部署。

请注意，这不是动态管理缓存的唯一方案。一致性哈希（例如 Dynamo⁴、Cassandra⁶ 和 Riak⁸ 实现的）在处理参考数据时提供了一个极好的选择。前端只读且后端更新的略微过时的参考数据的一致性语义非常匹配。这些系统具有出色的自我管理特性。

后端处理的风格

SaaS 应用程序的后端部分可以通过多种不同的方式实现，这在很大程度上取决于所需的处理规模。这些包括

关系数据库和普通应用程序。 在这种情况下，计算方法相当传统。数据保存在关系数据库中，计算以久经考验的方式完成。您可能会看到数据库触发器、N 层应用程序或其他应用程序形式。通常在云环境中，N 层或其他形式的应用程序将在 VM 中运行。这可以生成前端所需的参考数据，以及假设业务分析。这种方法的优点是关系数据库，但只能扩展到少量大型机器。

大数据和 MapReduce。 这种方法是一套面向集合的大规模并行处理解决方案。底层数据通常存储在 GFS（Google 文件系统）或 HDFS（Hadoop 分布式文件系统）中，计算由使用 MapReduce、Hadoop 或某些类似技术的大型批处理作业执行。越来越多的高级语言声明性地表达所需的计算。这可以用于生成参考数据和/或执行假设业务分析。随着时间的推移，我们将看到 MapReduce/Hadoop 在企业所有数据上运行。

大数据和事件处理。 数据仍然保存在可扩展的存储中，例如 GFS 或 HDFS，并且批处理可用于参考数据的生成和假设分析。这里有趣的是，出现了能够在几秒钟内识别来自 feed 或网络爬取的更改，并对与 MapReduce/Hadoop 批处理作业可用的相同的后端数据语料库执行事务性更新的能力。值得注意的例子是 Google Percolator 项目。⁷ 将事件快速处理成新的参考数据提供了充满活力的 Web 体验。

后端礼宾服务

当 SaaS 应用程序的后端部分遵循所述模式时，可以创建 PaaS 产品，这将使构建、部署和管理应用程序变得更加容易。通过遵循模式的约束，可以获得许多礼宾服务，例如

大数据统一数据访问。 通过统一的企业级（和受控的跨企业）数据，任何事物都可以与任何事物一起处理（如果已授权）。

容错和可扩展的存储。 适用于大数据和关系数据库的云管理存储可用，具有自动数据中心内和跨数据中心复制功能。

大规模并行批处理。 高级集合操作执行大规模计算。

事件处理。 具有极高更新速率的低延迟操作可用于独立事件。事务性更新发生在超过数十 PB 的数据上（参见 Percolator⁷）。对相同数据语料库的事件处理可用于批处理。

自动扩展参考数据缓存。 后端为前端提供动态更新的特定于应用程序的数据。键值缓存的管理和操作是自动的。管道系统通过根据需要增加缓存的复制来确保前端的读取 SLA 得到维护。

多租户访问控制。 企业间（公有云）和企业内（私有云）都需要对共享存储中包含的数据进行访问控制。

优先级 SLA 驱动的资源管理。 关系数据库、大数据批处理和大数据事件处理竞争相同的计算资源。不同的组织有不同的工作负载，所有工作负载都竞争资源。各种工作负载都给出了 SLA 和优先级，然后通过管道系统自动进行权衡。

计算领域走向共同性的驱动力

正如前面提到的，建筑物具有共性一样，不同类别的计算环境也具有共性。不同的类别必须连接到社区，就像建筑物中发生的情况一样。越来越多的云环境正在促进这些变化。

孤岛和 SOA

当今的企业使用 SOA（面向服务的架构）将应用程序孤岛粘合在一起。孤岛是在共享数据库上工作的应用程序集合。 SOA 是应用程序集成，它包含使用消息传递和数据馈送的 EAI（企业应用程序集成）和 B2B（企业对企业）通信。图 6 显示了具有共同特征的应用程序将如何在 SOA 服务总线中聚集。当前的企业应用程序在迁移到云时将利用其共性。当然，尚未为云部署设计的现有应用程序无法获得与遵循新兴模式的应用程序相同的所有好处。然而，有一种方法可以利用现有的共性，并通过在公共云或私有云中的云部署获得新的好处。

云计算将有助于推动孤岛和 SOA 走向共同的表示形式

关系数据库。 关系数据库将在标准化服务器上得到支持，标准化服务器具有在 SAN（存储区域网络）上运行的标准化存储。这将允许强大的存储成为可重启数据库服务器的基础。

使用 VM 的现有应用程序。 由于现有应用程序对处理环境有自己的期望，因此使用 VM 以通用方式最容易满足这些期望。 VM 看起来就像应用程序软件的物理机，但可以在云集群中进行管理。应用程序可以获得一台机器或一组机器。

通过大数据存储的 SOA 消息传递。 大型基于云的存储可以接收用于连接企业孤岛的消息和数据馈送。通过将 SOA 服务总线连接到大数据存储，可以分析有关孤岛交互的信息。这种分析已被证明对企业带来的洞察力非常宝贵。

标准化监控和分析。 随着企业计算的各个部分转移到私有云或公有云中的通用托管，可以跟踪应用程序的行为、它们之间的交互以及应用程序的使用模式。将其捕获在大数据存储中，可以以与应用程序的消息传递数据和其他企业知识集成的方式进行分析。

数据库和大数据

关系数据库提供严格控制的事务和完整的关系语义。然而，它们在扩展到少数服务器以上时面临挑战。尽管如此，关系数据库在应用程序、操作和技能开发方面拥有超过 30 年的投资，这些投资将持续多年。

以 MapReduce 和 Hadoop 为代表的新兴大数据存储提供了互补的优势。这些环境利用具有高可用性复制数据的大规模文件系统，提供可以在公共命名空间中寻址的数百 PB 的数据。最近，出现了可更新的键值存储，它们提供受事务保护的更新。⁷ 这些庞大的系统经过优化，可以与多个用户共享，这些用户以优先方式访问计算和存储资源。

越来越多的，大数据环境的这些优势将应用于现有应用程序中使用的关系数据库数据的副本。业务线关系数据与企业其余数据的集成将导致数据的通用底板。

IT 部门和业务线：天然的张力

企业中的业务线部门驱动新应用程序的开发。这是需要应用程序及其提供的解决方案来满足业务需求的部门。该部门为应用程序提供资金，并且通常不太关心应用程序如何适应企业其余的计算工作。

另一方面，IT 部门在应用程序部署后必须处理和操作该应用程序。它希望应用程序、数据库和服务器都在共同的基础上。它需要将应用程序集成到企业范围的监控和管理中。

这种天然的张力类似于房地产开发商和城市规划委员会之间看到的张力。开发商希望建造和出售建筑物，并且对质量不太挑剔。城市规划者必须确保开发商考虑诸如社区规划以及污水处理厂是否有足够容量等问题。

随着我们转向云计算环境，其中应用程序、数据库管理系统和其他计算资源托管在一组通用服务器上，我们将看到关于它们如何适应企业的标准和期望的提高。

那么推动我们走向云的力量呢？

推动我们走向云的力量将发挥作用，因为它们专注于计算和存储的共同和共享基础。首先，集中且昂贵的数据中心提供的更便宜的电力、网络和服务器技术带来的成本节约将继续存在。虽然存在管理信任的问题，但经济性是一种强大的力量。其次，企业将继续在数据分析中发现意外的价值。可用于分析的数据越多，就越有可能发生有价值的惊喜。最后，计算和数据存储资源将越来越多地在应用程序和企业之间共享。现有应用程序将从共享中获得一些价值，而新的云感知应用程序将获得更多价值。

这些力量将鼓励应用程序在新的共享抽象之上协同工作。当应用程序坚持其旧模型时，它们将获得云共性的一些优势，但不如新应用程序所看到的多。

结论

环境中的约束是赋予服务权力的因素。使用模式允许支持基础设施和礼宾服务。

共享建筑通过约束和标准化其使用而获得成功。建筑设计师知道建筑物将 *如何* 被使用，即使他们不知道 *谁* 将会使用它。并非所有人都能接受这些约束，但对于那些接受约束的人来说，会有奇妙的优势和服务。

计算工作使用标准的标准化将使工作迁移到共享云成为可能。借助这些使用模式，支持服务可以显着降低在云中开发和部署应用程序的障碍。较低级别的标准正在随着 VM 的出现而出现。这些支持广泛的应用程序，但共享灵活性较低。更高级别的 PaaS 解决方案尚处于起步阶段，但具有许多优势。

我们必须定义和约束重要类型的云应用程序的使用模型。这将允许增强资源共享以及重要的支持服务。新的 PaaS 产品将为计算世界带来巨大的价值。

参考文献

1. Amazon Web Services; http://aws.amazon.com/.

2. App Engine; http://code.google.com/appengine/.

3. Armbrust, M., Fox, A., Griffith, R., Joseph, A. D., Katz, R. H., Konwinski, A., Lee, G., Patterson, D. A., Rabkin, A., Stoica, I., Zaharia, M. 2009. Above the clouds: a Berkeley view of cloud computing; http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf.

4. DeCandia, G., Hastorun, D., Jampani, M., Kakulapati, G., Lakshman, A., Pilchin, A., Sivasubramanian, S., Vosshall, P., Vogels, W. 2007. Dynamo: Amazon's highly available key-value store. Symposium on Operating Systems Principles; http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf.

5. Force.com; http://www.force.com/.

6. Lakshman, A., Malik, P. 2009. Cassandra - a decentralized structured storage system. Large-scale Distributed Systems and Middleware; http://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf.

7. Peng, D., Dabek, F. 2010. Large-scale incremental processing using distributed transactions and notifications. Ninth Usenix Symposium on Operating Systems Design and Implementation; http://research.google.com/pubs/pub36726.html.

8. Riak; http://basho.com/products/riak-overview/

喜欢它，讨厌它？让我们知道

[email protected]

Pat Helland 自 1978 年以来一直从事分布式系统、事务处理、数据库和类似领域的工作。在 20 世纪 80 年代的大部分时间里，他担任 Tandem Computers 的 TMF（事务监控设施）的首席架构师，该设施为 NonStop 系统提供分布式事务。除了在亚马逊工作两年之外，Helland 从 1994 年到 2011 年在微软工作，在那里他担任 Microsoft Transaction Server、SQL Service Broker 以及 Cosmos（Bing 的底层分布式计算和存储系统）中许多功能的首席架构师。 Pat 最近加入了 Salesforce.com，并领导着许多使用超大规模数据的新工作。

本文是在 Pat 加入 Salesforce.com 之前撰写的，虽然有很多相似之处，但这并非旨在描述 Salesforce 的架构。

最初发表于 Queue 第 10 卷，第 11 期—
在数字图书馆中评论这篇文章

更多相关文章

Marc Brooker, Ankush Desai - AWS 的系统正确性实践
构建可靠且安全的软件需要一系列方法来推理系统正确性。除了行业标准的测试方法（例如单元测试和集成测试）外，AWS 还采用了模型检查、模糊测试、基于属性的测试、故障注入测试、确定性模拟、基于事件的模拟和执行跟踪的运行时验证。形式化方法一直是开发过程的重要组成部分 - 也许最重要的是，形式化规范作为测试预言，为 AWS 的许多测试实践提供正确的答案。正确性测试和形式化方法仍然是 AWS 的关键投资领域，这些领域已经看到的投资回报加速了这一进程。

Achilles Benetopoulos - 数据中心计算机的中间表示
我们已经达到了分布式计算无处不在的地步。内存应用程序数据大小正在超过单个机器的容量，因此需要将其分区到集群中；在线服务具有高可用性要求，这只能通过将系统部署为多个冗余组件的集合来满足；高持久性要求只能通过数据复制来满足，有时跨越广阔的地理距离。

David R. Morrison - 模拟：分布式系统中未充分利用的工具
模拟在人工智能系统的出现中发挥着巨大的作用：我们需要一种高效、快速且经济高效的方式来训练 AI 代理在我们的基础设施中运行，而模拟绝对提供了这种能力。

Matt Fata, Philippe-Joseph Arida, Patrick Hahn, Betsy Beyer - 从企业到云：谷歌的虚拟桌面
超过四分之一的 Google 员工使用内部数据中心托管的虚拟桌面。这种本地产品位于公司网络中，允许用户开发代码、访问内部资源以及从世界任何地方远程使用 GUI 工具。在其最显着的特性中，虚拟桌面实例可以根据手头的任务调整大小，具有持久的用户存储，并且可以在公司数据中心之间移动以跟随出差的 Google 员工。直到最近，我们的虚拟桌面都托管在使用名为 Ganeti 的自制开源虚拟集群管理系统的 Google 公司网络上的商用硬件上。今天，这项重要的且对 Google 至关重要的工作负载在 GCP（Google Compute Platform）上运行。