下载本文的PDF版本 PDF

企业软件即服务

在线服务正在改变软件的本质。

DEAN JACOBS，SALESFORCE.COM

外包业务职能（如工资单）的做法已经存在几十年了，但将其实现为在线软件服务只是最近才开始流行。在在线服务模式中，提供商开发应用程序并运营托管该应用程序的服务器。客户通过互联网使用行业标准浏览器或Web服务客户端访问应用程序。各种各样的在线应用程序都已可用，包括电子邮件、人力资源、业务分析、CRM（客户关系管理）和ERP（企业资源规划）。

在企业环境中，在线服务与打包软件的内部部署竞争。与任何形式的外包一样，在线模式的主要优势在于它可以汇集大量用户，并可以利用规模经济来降低成本。这一原则适用于IT基础设施的各个方面，包括硬件、软件、人员配备和数据中心本身。

在线服务的附带优势是容量共享实现了按需付费定价。这意味着前期成本较低，客户只需为他们使用的服务付费，并且可以通过取消服务完全消除成本。

在线服务的一个重要杠杆点是它们将应用程序的开发与其支持基础设施（包括文件系统、数据库、应用程序服务器和管理工具）的开发垂直整合。因此，可以定制基础设施组件以满足特定应用程序和通用在线模型的需求。例如，Google文件系统经过优化，以支持读取和追加，而不是任意写入。1 应用程序管理基础设施的专业化可以显着减少对IT人员的需求，从而显着降低运营成本。

软件即服务比打包软件更容易开发。在在线环境中，应用程序仅安装在一个设置中；因此，无需将其移植到各种平台。此外，服务提供商可以直接控制升级发生的时间，从而控制在任何给定时间需要提供的应用程序版本。最后，由于服务提供商管理客户使用的实际应用程序实例，因此更容易重现错误，并且可以根据实际数据开发测试用例，并在任何隐私约束范围内进行。

在线服务设计中的一个重要问题是它可以定制的程度。许多复杂的业务流程需要定制，并且定制可以为企业提供竞争优势，但它也可能意味着升级服务更加困难。更重要的是，定制可能会使组织更难以设置和/或迁移出服务。虽然设置和迁移的便利性对于在线业务模式并非必不可少，但它们降低了尝试服务的风险，并为应对失败的提供商提供了对冲。

在线服务的好处因客户业务规模而异。拥有自己数据中心的大型企业可以汇集用户并从规模经济中受益。对于缺乏资源来建立和维护复杂数据中心的中小型企业而言，在线服务可以提供业务流程的基本自动化。

虽然第一个在线企业服务出现在20世纪90年代，但该模式只是最近才开始获得广泛接受。原因之一是互联网已经成熟：Web UI技术可以产生更好的浏览器体验；Web服务协议使与外部应用程序的集成更容易；服务提供商受益于更便宜、更高质量的带宽；IT经理也越来越适应这项技术。另一个因素是服务提供商现在正在从头开始构建在线应用程序，因此它们具有更好的安全性、更好的服务质量和更高的成本效益。服务提供商也在通过瞄准不太关键任务的应用程序（例如营销活动管理和审批链处理，至少在初期阶段）来启动他们的业务。

在本文中，我们将研究软件即服务以及它与传统打包软件的不同之处。首先，我们从服务质量的角度比较这些模型，包括可扩展性、性能、可用性和可靠性。然后，我们讨论利用规模经济的问题。我们还将研究应用程序定制和在线编程环境，以及应用程序集成和Web服务。文章最后提出了一个发展成功的在线服务的策略。

服务质量

在线服务必须从一开始就设计为高度可扩展的。例如，一个中等规模的部门应用程序通常支持数百个用户。此应用程序的成功在线实施将必须处理数千个此类部门，因此需要处理数十万用户。如此大的负载需要使用集群2，其中进程组分布在多台机器上，并协调它们的动作以提供服务。可扩展性是通过允许进程和机器的数量根据呈现的负载而变化，并通过在整个系统中平衡请求来提供的。图1说明了一个典型的基于Web的应用程序，其中集群用于整个系统，从前端的Web服务器到中间层的应用程序服务器，再到后端的数据库。

为了提高在线服务的可靠性和可用性，服务提供商应采用集群来消除单点故障。应提供管理基础设施来监控服务器进程的健康状况，并在发生故障时重新启动它们或发出警报。管理基础设施应支持将工作从故障服务器迁移出去，这可能需要迁移本地存储上的数据或迁移共享存储上数据的所有权。在线服务提供商可以选择提供额外的可靠性和可用性功能，特别是地理位置分散的数据中心之间的站点范围故障转移。与内部实施以及其他在线服务提供商相比，这些功能可以提供竞争优势。

不幸的是，许多提高可扩展性的技术都会对PAR（性能、可用性和/或可靠性）产生负面影响。此问题的示例包括

具有较弱PAR要求的应用程序允许使用这些技术，因此更容易实现可扩展性。由于可扩展性在在线环境中至关重要，因此具有较弱PAR要求的应用程序更适合在线实施。具有强PAR要求的应用程序可以在在线环境中实现，但这只会增加服务提供商数据中心的复杂性和成本。特别是，通过为每个组织提供其自己的专用机器，可以有效地将在线服务的可扩展性要求降低到其内部级别。这将在下一节中进一步讨论。

利用规模经济

由于在线服务模式将许多用户聚集在一起，因此它可以利用规模经济来降低成本。在最基本的层面上，硬件、软件和数据中心资源（如空间和电力）的批量定价有助于降低成本。此外，在线服务在用户之间共享的资源越多，增加用户的成本就越低，处理峰值负载所需的未使用容量就越少。请求的同质性是批量定价和资源共享的重要杠杆点，因为它减少了所需资源的种类。

资源共享的一个重要方面是IT人员成本在许多用户之间的摊销。服务提供商应开发一种应用程序管理基础设施，以优化IT人员的效率。调整、升级和故障分析等管理操作应尽可能自动化。请求的同质性通过减少管理操作的种类和执行这些操作所需的技能来促进这些目标。优化运营效率可以保护服务提供商免受产品商品化，因为它提供了除功能之外的竞争维度，就像硬件制造商一样。

对于在线服务而言，成本效益最低的实施策略是为每个组织提供其自己的专用机器。这种方法迫使服务提供商为其最大负载配置每个组织的系统，从而导致稳态下存在大量未使用容量。名义上，资源应组织成服务器场，并且应使用虚拟化技术来动态分配每个组织的进程和数据。组织可以通过共享进程和存储来实现进一步的成本节约。共享可以发生在系统的任何或所有层，从Web服务器到应用程序服务器再到数据库服务器。

在数据库中，共享可以发生在多个级别。最常见的方法是在共享数据库服务器上为每个组织提供其自己的数据库实例。更激进的方法是允许共享数据库实例中的每个表包含来自多个组织的数据。表级共享可以通过允许完全从SQL内部执行跨组织操作（如升级）来简化应用程序管理。相比之下，使用服务器级共享，此类操作必须在每个实例上单独执行，并使用脚本捆绑在一起。如果数据库提供集群，则可以将表级共享扩展到服务所需的任何级别。否则，系统可能需要多个数据库服务器，因此需要一些跨实例管理。在后一种情况下，可以围绕自然管理边界（如地理区域）组织实例。

共享的一个缺点是它降低了服务提供商为不同组织配置不同系统的能力。例如，如果只有一个应用程序服务器池，则服务器无法进行不同的调整以处理不同组织的负载。共享对配置的负面影响在数据库中更为显着，在数据库中，某些功能可能变得不可用。例如，对于表级共享，为单个组织设置触发器或物化视图可能不可行。如果需要此类功能，服务提供商可能必须在数据库之上将其实现为应用程序的一部分。

除了实施应用程序级安全性（如跟踪角色和强制访问权限）之外，服务提供商还必须确保组织无法访问彼此的数据。共享增加了这一挑战。例如，如果应用程序服务器在请求之间维护数据（作为会话状态或缓存的数据库数据），则欺骗攻击或缓冲区溢出可能会将一个组织的数据暴露给另一个组织。类似地，对于表级共享，应用程序或数据库代码中的错误更有可能将一个组织的数据暴露给另一个组织。

无论实施设置如何，应用程序都必须防止单个用户过度消耗资源，无论是无意还是恶意。共享提高了这个问题的重要性，因为它允许一个组织影响另一个组织。处理此问题的基本技术是节流（延迟请求以使资源使用在一段时间内分散开来）和拒绝（拒绝请求）。这两种技术在在线环境中都不具吸引力，在在线环境中，表面上提供服务是为了满足所有需求。服务提供商必须在允许有效但高资源使用率与防止无意或恶意过度资源使用率之间走钢丝。

用户消耗资源的能力（无论是正常程度还是过度程度）取决于应用程序支持的请求类型。此问题受到用户自定义或扩展应用程序能力的影响。

应用程序定制和在线编程环境

不同的应用程序需要不同程度的配置和定制。简单的桌面应用程序（如电子表格）通常由最终用户通过一系列菜单或向导进行配置。复杂的企业应用程序（如ERP系统）需要系统集成商或内部开发人员编写特定于组织的代码。在光谱的另一端，应用程序服务器是构建任意分布式应用程序的平台。这些系统为用户/程序员提供了不同程度的表达能力。

在在线环境中，实现高度表达性的结构可能具有挑战性，因为它很难控制其资源使用率。例如，一个简单的数据浏览应用程序可能提供一组固定的参数化查询，这些查询从基于Web的表单中调用。服务提供商可以提前分析这些查询，并准确预测它们将对数据库造成的负载。一个更复杂的报告应用程序可能会生成包含选择和投影但不包含连接的查询。服务提供商可以限制此类查询的大小或复杂性，以帮助控制其运行时间。通常，只有当管理基础设施可以识别和中止正在使用过多资源的操作时，才能支持高度表达性的结构（如不受限制的查询或任意脚本）。

高度表达性的结构可能会使提供商更难升级服务。作为基线，考虑一种服务，其中客户仅提供原始数据（如帐号和客户姓名），并使用固定的架构。在这种情况下，提供商可以相对容易地升级服务，而无需更改架构，或者更新架构并对数据进行一次性转换。但是，随着服务变得越来越可定制，架构和定制的内部表示可能会变得更加动态和复杂。如果允许脚本编写，则必须提供对编程API版本控制的支持。

高度表达性的结构也可能使组织更难设置和迁移出服务。对于刚刚描述的基线服务，很容易批量上传和下载数据作为逗号分隔值文件，或者更好的是，以行业标准格式进行。但是，随着服务变得越来越可定制，前期启动需要付出更多努力，并且只有在组织继续使用该服务时，此努力才具有价值。虽然这种供应商锁定从长远来看可能对服务提供商有利，但在短期内，它可能会阻止服务达到临界规模。

具有简单、自然的定制/编程模型的应用程序在在线环境中更容易销售。如果要支持广泛的定制/编程，那么最好通过第三方开发人员来完成。为了托管第三方编写的应用程序，服务提供商必须构建额外的基础设施（例如，支持测试和升级）。或者，第三方可以自己托管辅助应用程序，并使用Web服务与主服务集成。

Web服务和应用程序集成

在线服务越来越多地使用Web服务与外部系统集成。这些可能是现有系统，也可能是专门编写的用于扩展在线服务的系统。外部系统可能具有自己的服务器；示例包括公司数据中心中的遗留应用程序和其他在线服务。在这种情况下，外部系统通常维护某些业务数据的记录副本，在线服务使用Web服务来提取或输入该数据。或者，外部系统可以是客户端，可以是标准桌面应用程序（如电子表格）或专用富客户端。在这种情况下，在线服务维护记录副本，客户端使用Web服务来提取或输入数据。

应为最终用户和第三方开发人员提供不同的Web服务API。应为最终用户提供一个简单、强类型的API，该API特定于其组织的数据模型。应为第三方开发人员提供一个更强大、更弱类型的API，该API跨越所有组织的数据模型。请注意，由于定制，组织之间的数据模型可能会有所不同。在这两种情况下，都应提供批量操作以减少网络通信的开销。

从长远来看，服务提供商应支持用于异步通信的Web服务API。存储转发消息传递提供了比分布式事务更简单的可靠通信形式，并为应对系统过载或不可用提供了缓冲。不幸的是，用于异步通信的Web服务协议尚未广泛建立，许多IT经理不愿意为出站消息传递打开防火墙。因此，在短期内，服务提供商应支持用于同步调用-响应的Web服务API。

尽管Web服务增加了在线服务的功能，但它们并非没有成本。与浏览器界面不同，Web服务API既不是固定的，也不是众所周知的。这引入了许多与打包软件相关的问题。Web服务API必须进行版本控制，并且升级必须在不中断外部系统的情况下进行。通过Web服务API进行测试和调试很困难，并且需要各方之间的个人互动。

发展成功的在线服务

要创建成功的在线服务，您应该制定一个随时间演变的策略。首先，瞄准一个不太关键任务的应用程序，该应用程序具有较弱的数据一致性要求，并且最多只需要简单的定制。专注于开发一种资源共享策略，该策略不会危及您支持每个组织的配置、实施安全性或防止拒绝服务攻击的能力。开发良好的批量上传和下载数据机制。构建全面的Web服务API，并与其他在线服务建立合作伙伴关系。将您的服务定位在中小型企业，这些企业的要求较少，需求更大。

随着时间的推移，构建管理基础设施，使您能够以尽可能低的成本交付服务，以此来对冲商品化。使多个地理位置分散的数据中心上线，并在它们之间提供站点范围的故障转移。在您达到临界用户规模后，扩展到其他更关键任务且需要更多定制的应用程序，并开始瞄准更大的企业。

参考文献

  1. Ghemawat, S., Gobioff, H., and Shun-Tak Leung, S-T. 2003. The Google file system. In Proceedings of the Nineteenth Symposium on Operating Systems Principles. Bolton Landing, NY.
  2. Jacobs, D. 2005. Data management in application servers. In Readings in Database Systems, 4th edition, ed. J. M. Hellerstein and M. Stonebraker. MIT Press.

DEAN JACOBS是salesforce.com的首席架构师。他是WebLogic应用程序服务器的原始开发人员之一，并负责WebLogic集群。

他于1985年获得康奈尔大学计算机科学博士学位，并在南加州大学（USC）计算机科学系任教。

acmqueue

最初发表于Queue vol. 3, no. 6—
在数字图书馆中评论本文




更多相关文章

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


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


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


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



© 保留所有权利。

© . All rights reserved.