【导语】服务交付平台，SDP（Service Delivery Platform），在电信行业已经使用多年，在电视行业，尤其是在结合了互联网方式的数字电视，互联网电视行业，现在也作为一个基本模型进行使用。正如技术战略一文中提到的：一项技术越向变化缓慢的其他行业渗透，就越有可能得到投资。注意，这里的投资，我认为，不仅仅是Money，也包括，我们的Focus，还有，Study。以下是微软提出的一个应用模型。

通过服务交付平台进行高效的软件交付

1（共 1）对本文的评价是有帮助 评价此主题

作者：Gianpaolo Carraro, Fred Chong, Eugenio Pace

摘要

软件即服务（software as a service lang=ZH-CN>，SaaS）作为一种软件交付机制具有很大的发展空间。这种一对多的交付模型之所以吸引人的原因之一就是它使新的规模经济成为可能。然而规模经济并不是自动获得的－它必须在解决方案中进行显性的架构。一种最典型的允许规模经济的架构模式为“单实例、多租户体系结构”，许多提供SaaS的独立软件供应商（Independent Software Vendors ，ISVs）已经转向该结构，并且也就取得了多层次的成功。

另外还有其它改进效率的方法，但是ISVs还没有以同样的热情来采纳，那就是使用基本的服务交付平台（Service Delivery Platform，SDP）。只所以对其接受的速度较慢，主要因为利用优化的服务交付平台对行业应用程序进行交付的方式才刚刚开始。但是它们开始逐渐的崭露头角。本文探讨SDP的目标，能力以及动机，并且描述了通过SDP进行高效的软件交付相关的技术和过程。

内容

规模经济和应用架构
SDP成功要素
应用程序原型：一种类型的SDP可以适用所有场合吗？
服务交付平台的性能
场景A：基本服务交付平台
场景B：通过更深入的应用程序框架知识来增进效率
场景C：操作管理之上的SDP
场景D：终极SDP
结论
资源

规模经济和应用架构

操作系统正沿着简化应用程序开发，操作和管理的道路发展。操作系统提供一个基础体系结构，常用的、通用的应用程序服务可以进行编码和重用，不再需要根据运行需求为每一个应用程序都建立（或再建立）充足的系统堆栈。

通常，这些服务技术上都非常复杂，需要很强的专业知识和技能才能进行开发。ISVs迅速的理解一个操作系统的特点，在一到两个操作系统上平衡它们的开发。通过对基本的体系结构进行平衡，使他们能够在特定领域的应用程序上花更多的时间，而这些领域相关的应用程序也正是软件使用者付钱的目的。

有很多例子，对某一应用程序的特定需求超过了通用目的操作系统所能提供的能力。在这种情况下，操作系统的部分内容被用户开发的能够提供特定层次支持的模块所替代。例如，数据库通常编写自己的文件系统，象Microsoft SQL Server就有自己的调度安排和内存管理。但是这些特定的需求与常规应用非常不同。企业和ISVs不断将通用组件从它们的解决方案中提出，形成一个水平的应用程序框架。这些框架提供更加抽象、通用和共享的组件（步骤），从而增加重用和生产力，以及一般说来，更加可预言的开发和操作环境。

“水平能力自上而下的流程，从ISV架，再到中心平台，都可以进一步通用化，直到将软件交付作为一项服务。从这种意义上，sdp就成为面向服务交付的“操作系统”。”

建立多框架结构的问题在于他们通常不能直接提高软件本身的价值。为了能够满足对应用程序的长期维护，它们肯定有限制性，ISVs和企业都宁愿别人拥有它们。这样Plumber集中于水平的功能，而领域专家则集中于对买方更有价值的垂直的功能所带来的双赢形势就大大加强了。我们应该面对的是，没有人会因为某一个解决方案具有更好的意外处理机制而购买它。

如图1所示，从应用程序中提取和一般化功能到框架，再从框架到中心平台组件是一个自然，渐进的过程。通过增加共享元素的数量，这一流程可以改进规模经济。

图 1: 将日常功能构建为可重用的平台

从到框架，再到中心平台的水平能力的向下流程能够进一步的通用化，直到将软件交付作为一项服务。从这种意义上，SDP就成为面向服务交付的“操作系统”，特别是在SaaS交付的应用程序的水平特性和要求。

传统的核心公司凭借其背景，专业，技术和已有数据库自然是执行和提供SDP的首选。但是其它公司也应该考虑进入这一正在发展的空间中。目前ISVs是自足执行它们的SaaS解决方案，这样就可以考虑通过提供通用目的的交付环境拥有为自己建立的自足执行环境。系统集成者通过业务过程外包获得世界级的操作性能，从而可以平衡高速发展的SaaS 领域的知识。

“重点是SDP的效率主要依赖于提供服务的原型。一个SDP具有的关于应用程序的知识越多，运行和操作的效率就越高，共享的程度也就越高。”

SDP成功要素

SDP成功的程度由以下特点所决定：

1.   核心操作能力： 提供强壮的服务级别协议（service level agreements，SLAs）的能力（容错和正常运行时间），可扩展性和灾难恢复，以及通用的服务功能，如面向多个地理位置，24-7客户支持以及多层次的物理安全。

2.   服务深度：它所提供服务的复杂程度，如十分支持多种付费方式。

3.   服务广度：平台的完整性。换句话说，就是对SaaS交付的应用程序生命周期不同阶段的支持程度，如订单服务，应用程序暂存，性能规划服务，或打包和更新的方法。

4.   使用的简单程度： ISV角度的使用性，即学习和使用SDP提供的服务的成本。易用的SDPs具有较短的延迟时间，完整的文档，良好的界面和SDK，实例代码，模板，向导和培训内容。

需要注意的是以上四个特点并不意味着能够表达成熟的模型。通过对现有的SDP的观察发现当前有两个策略：广度策略，用于提供完整的，端到端的平台，可以包含一个典型SaaS交付应用程序生命周期的每个步骤（见图2），只是对每个方面的涵盖都很浅；深度策略，仅关注特定的步骤，当时对这些步骤能提供复杂的功能。同样的调查发现易用功能并没有完全体现在提交的服务中，因为易用大多数还是取决于人的即兴过程。

应用程序原型：一种类型的SDP可以适用所有场合吗？

商务应用基于不同的特点和要求可以分为不同的原型。以下是这些原型的例子：

•   联机事务处理系统（ Online transaction processing systems，OLTP):

主要特征是低延迟，高响应，数据完整性，预定义UI工作流。

•   分析系统或在线分析处理（online analytic processing， OLAP）:

以对大型多维数据集进行复杂分析和高度定制的查询，以及低延迟响应著称。BI系统属于该类型。

•   批处理系统：

能够在大型数据集上高效的执行操作，当例外发生时，可以协调工作以最大化的协调CPU的恢复策略。

每个应用程序类型都有自己的约束，特点和优化的设计模式，可以解决它们面临的特定的挑战。通常，这些挑战的目标都是相互矛盾的。例如：OLTP将用于低延迟的优化，然而延迟对于批处理系统来说并不是那么重要。

OLTP在水平方向延伸，具有无状态的体系结构，而批处理系统在垂直方向延伸，是有状态的。因此，它们的基础体系结构和服务都各不相同。

重点是SDP的效率主要依赖于提供服务的原型。一个SDP具有的关于应用程序的知识越多，运行和操作的效率就越高，共享的程度也就越高。

服务交付平台的性能

图2展示了典型的SaaS交付的应用程序的生命周期。该生命周期的每个阶段都由ISV执行的一些活动组成，SDP的复杂程度越高，中心企业和其它角色的联系就越密切。（例如，系统集成商，增值转销商）

图 2: 一个典型的SaaS交付的应用程序生命周期和相关活动

以下四种场景描述复杂程度逐渐增加的SDP性能和体验

A：基本服务交付平台

目前，最简单的SDP功能主要由传统的主厂商来提供。这些服务集中于核心，通用的体系结构组件如：CPU，网络访问，互联网安全功能和存储（磁盘和数据库）；通常提到的“侦测，电源和管道” 该场景中规模经济仅限于最低层次的体系结构：建立数据中心和IT体系结构，如服务器和网络设备。

在这个基本场景中，部署的ISVs应用程序对应用程序架构使用自己的标准，核心企业只需知道一少部分。ISV有望开发和提供它们自己的多租户管理体系结构，安全体系结构和租户管理等等。

体系结构服务请求如注册新域，建立新的数据库，分配内存等通常通过手动或由定制脚本自动执行。

安装和部署解决方案需要ISV为中心企业提供详细的配置和建立的指令；需要多个非标准调节（如处理XML config文件，注册密钥，文件路径，连接字符串），因为核心企业对应用程序架构了解的很少。这些随意的步骤阻碍了核心企业向成千上万应用程序扩展，因为它必须将每个应用程序都看作是例外。

每个应用程序都是一个具有潜在冲突的组件的“黑盒子”，这些资源竞争共享的（有限的）资源，这也就是为什么许多ISV需要专门的服务器来保证应用程序之间的隔离。然而，专门的服务器又与通过共享框架结构来提高效率的目标相违背。

图 3:通过共享的体系结构驱动规模经济

核心企业仅能通过观察和遵照大量的指示器来监视解决方案。它们仅能够测量通用的广泛的性能计数器如CPU和内存负载，带宽，SQL 争用，以及可能是ISV根据需要提供的一些特定应用程序的性能计数器。没有公认的标准体系用于支持应用程序更细粒度的管理。

引人注目的是，尽管核心企业只知道少量甚至不知道应用程序的工作，它通常都能向ISV提供详细的数据库性能信息。这是因为数据库产品对所有的ISV和其产生的平台（数据库服务器本身，如SQL Serve）来说都是通用的（每个应用程序都有表，存储过程，索引，触发，视图等等）。因此，核心企业可以提供详细的争用，锁定和性能报告，甚至可以提供对这些产品改进的建议。

“尽管核心企业只知道少量甚至不知道应用程序的工作，它通常都能向ISV提供详细的数据库性能信息。这是因为数据库产品对所有的ISV和其产生的平台（数据库服务器本身，如SQL Serve）来说都是通用的”

显著的一点是这些产品存在于每个基于数据库的应用程序上，而不用考虑授权于它的ISV。相比较而言，以一个Web应用程序为例，不同ISV共享的唯一产品就是由一个URL指定的“Web页面”，它的粒度太粗，以至于难以管理。关于页面的哪部分下载时间长，哪个组件通过特定的页面实例化，或者哪些相互依赖的组件会引起争用或运行时问题等都需要查看代码，使用高级工具和（或）更深层次的关于应用程序是如何建立的知识－这些过程使其不能扩展到成千上万个应用程序。

在该基本环境中操作的SaaS应用程序通常通过使用一些不必要的兼容技术堆栈和库来执行。例如，您可能发现一个终端服务交付VB6应用程序，Web应用程序使用各种可用的框架和运行时组件。换句话说，例外的是规则。

该场景描述为操作的体系结构的共享。总之，在该场景中规模经济受限于低层次的组件。影响SDP的主要特征是核心企业应用程序的异构性。

场景B：通过更深入的应用程序框架知识来增进效率

更多的共享组件导致更高的效率，因此问题成为哪个是从应用程序到SDP最自然的候选者？最明显的候选者是那些指定应用程序体系结构的服务如：应用程序配置，运行时例外处理和报告，日志和审核，跟踪，缓存，数据访问。每个应用程序都需要它们，而ISV对它们进行频繁的写入。

例如通用的，标准的和被广泛接受的应用程序体系框架微软企业程序库。通过将这些基本的服务公共开发，SDP还具有不断增大的对常用步骤自动化和提供更加先进的操作管理功能的能力。这样，就可以提供更细粒度的调节，定制和故障解决。值得注意的是，中心企业不需要详细的理解应用程序做什么，而只需知道怎么做（例如，数据库的连接字符串存在什么地方？运行时例外是如何记录和通知的？）

图 4: 通过应用程序体系结构增加重用能力

因为ISV也许会对这些API进行开发，所以核心企业需要发布“SDP SDK”包括文档，示例，甚至是ISV下载和使用所需的基本工具。

在该场景中，核心企业可以扩展基本的操作步骤，就好像它们都是常用的步骤。不符合标准的应用程序当然会导致额外费用。

另外，核心企业可以利用各种不同的自行执行架构提供各种不同的服务。例如，中心企业知道所有的应用程序都要使用同样的测量和步骤来记录运行时例外，因此基本的中心企业程序包就会包括运行时例外日志和报告，高级运行时日志，通知和升级就会成为定额服务。（见图5）。

但是使用该方法的ISV应用程序并没有改变，因为所有的逻辑（“plumbing”）都在SDP一方。

图 5: 同一功能不同对策的例子

场景C：操作管理之上的SDP

场景B比A具有明显的优势，但是SDP还可以通过增加更复杂的应用程序服务来进一步增强，如高级的架构设置，安全相关服务（用户配置文件，用户角色，个性化）和新的业务服务，如：业务事件，应用程序计量、计费和使用技能。 因为可以良好的定义服务和应用程序之间的协议，此时可以建立服务层的SLA。传统的宏级别（如正常运行时间，带宽和CPU使用）的SLA是必要的但不是充分的条件。可以协商许多更细粒度的SLA。例如，可以定义，监视和控制一个声称“能在X分钟之内设置一个新租户”的SLA。SDP SDK可以进一步加强来包含新提供的服务，这些能够离线开发的服务是独立执行的。例如，中心企业不可能只是出于开发的目的而与ISV共享完整的计费系统。  ISV更有可能采用相对等的接口和协议以及最小的仿真执行来模仿计费服务。目标就是建立开发环境能够最小的依赖详细的执行来模仿所有SDP功能。这就避免了SDP内部的知识产品不必要的暴露出来。为支持这一场景，中心企业和ISV自身软件开发生命周期之间需要更深层次的集成和交互。

“版本控制，集成的事件管理，在暂存环境之间暂存和版本提升，允许ISV，聚合者，系统集成者开发，定制和维护不同的并行的产品。这一体系结构使的程序就像是测试版，可以在SDP控制的领域运行，在功能最终发布之前收集反馈，使用模式和bug解决方案。”

在这一场景中，部署到SDP的解决方案也是大部分通过自动的过程，尽量减少手动干涉。这些步骤包括自动验证和应用程序要求（例如前提条件，服务器定位，连接字符串）配置的高级功能。

SDP的部署超越了编码和配置脚本，包括协商的SLA，操作要求如自动容量管理，事件升级和计费参数化。

SDP也能提供暂存的环境，应用程序可以在该环境中运行，并在提交之间进行校验。暂存环境允许对计费，租户建立，错误等进行仿真，可以对真实场景进行更加复杂的建模。这些可以看作中心企业和ISV之间对SLA的“单元测试”。（见图6）

图 6:包含代码和运行时定义的部署

有趣的是，这就导致在运行时之上又提供了新的服务：例如，可以ISV进行错误仿真，负载测试，性能分析和优化。小型的ISV也可以对临时资源进行访问，但是对它们来说代价过大。

由于对应用程序的工作方式有深入的了解，在实际工作时，SDP可以提供自动的资源管理和调节。更高级的SDP可以动态分配新的机器，为一个集群增加CPU，指定更高的通讯带宽，以及任何为了维护SLA的应用程序所需的体系结构。

由于能够对应用程序进行完整的检测，中心企业能够提供使用模式智能和对应用程序执行和工作方式的较细粒度的分析，并将这些信息反馈给ISV的产品规划流水线。

由于具有高度自动化的质量保证和部署过程，ISV有机会基于收集的智能和提供几乎实时的产品增强，并基于更精确的用户反馈不断地改善它们的产品。

应用程序的销售、品牌打造、捆绑和聚合都可以通过良好定义的组合规则来完成，因此，中心企业可以为不同的解决方案（如单点登录或通用角色管理）捆绑提供通用服务。并且可以为聚合者和第三方提供“白标”品牌打造，从而基于同样的代码库创造专门的，定制的产品。

场景D：终极SDP

终极SDP并不存在。本节主要进行推论和思索。在最高级的应用场景中，给出了以上描述的所有特征，SDP还包括面向完整的应用程序生命周期管理的服务，允许对开发，版本，部署，管理，操作和支持SaaS交付解决方案的进一步集成，允许扩展的生态系统，共同协作交付特定的解决方案。

发现，学习，尝试，开发，扩展，版本管理，调节都是SDP支持的使用案例。这是ISV软件开发全生命周期（ISV Software Development Life Cycle，SDLC）和SDP软件操作全生命周期（SDP Software Operations Life Cycle，SOLC）的完全集成。在该场景中，软件开发的各个方面都被作为服务来提供：bug跟踪，软件版本控制，性能测试等等（图7）。

图7: “终极SDP”中ISV的SDLC与核心公司操作生命周期的集成

所有的SDP功能都表达为机器可读的形式。软件组件和SDP功能的模型都被完成的集成到工具中。对这些模型的验证，分析和仿真可以被生态系统中独立的成员执行：ISV，第三方，聚合者，企业以及其它建立复杂系统的协作伙伴。

应用程序元数据不仅包括操作参数，还包括在SDP发布应用程序所需信息（等同于在Windows上增加新软件的应用程序注册），而且提供“了解更多”，指导，文档，训练，以及更多增值的专业服务等。

可以通过SDP提供版本控制，集成的事件管理，在暂存环境之间暂存和版本提升，允许ISV，聚合者，系统集成者开发，定制和维护不同的并行的产品。这一体系结构使的程序就像是测试版，可以在SDP控制的领域运行，在功能最终发布之前收集反馈，使用模式和bug解决方案。

SDP提供的市场服务提供了一个发现，学习和尝试新产品的机制，通过伴随每个应用程序利用元数据来实现。

正如前面所说，这些高级的SDP功能成为主流还需要一定的时间。

结论

SDP为传统的中心企业建立不同的，高价值的服务提供了新的机会；为大量ISV能够提供世界级操作水平的解决方案降低了门槛。率先进入这一新市场的将是大量的ISV，尤其是那些处于小型或小到中型业务段，由于技术或企业经济实力而不能自主的企业。

微软体系结构策略团队正在积极的致力于开发体系架构指导，从而帮助ISV，中心企业和企业实现软件和服务的利益，最大化的发挥微软平台的作用。

资源

MSDN architecture. Development Center

SaaS Section on MSDN Dev Center

LitwareHR

–A sample SaaS-delivered application ，由 Microsoft 基础架构策略团队开发

作者简介

Gianpaolo Carraro，服务交付首席专家－Microsoft 基础架构 Strategy Team，推动了SaaS思想的领导地位和微软架构的最优体验。在进入微软之前，Gianpaolo是SaaS启动的共同建立者和首席架构师；他是Bell实验室的前技术人员。Gianpaolo主要国际IT会议的作者和演讲者。如需更多他的信息，您可以访问他的博客： http://blogs.msdn.com/gianpaolo

Fred Chong， 架构师－Microsoft 基础架构 Strategy Team，业界公认的SaaS架构的业务专家。先前，他为微软产品和客户解决方案设计和执行安全协议和网络组件。Fred也曾经在IBM T.J. Watson Research Center 和 the University of California at San Diego进行研究工作。您可以访问他的博客：http://blogs.msdn.com/fred_chong

Eugenio Pace，架构师－Microsoft 基础架构 Strategy Team，主要复杂SaaS领域开发体系结构的指导工作。在加入AST之前，他曾是微软patterns and practices team的产品经理，主要负责交付客户端一方的体系架构的指导，包括Web客户端，智能客户端和移动客户端。当时，他的团队为移动客户端，桌面智能客户端和Web客户端开发了Composite UI 应用程序 Block和三种软件工厂。在加入patterns and practices team之前，他是微软Consulting 服务的架构师，领导全世界多家企业解决方案的开发工作。您可以访问他的博客：http://blogs.msdn.com/eugeniop