SaaS模式、技术与案例详解——第14章 实用性及扩展性

本章导读语】

老僧三十年前参禅时，见山是山，见水是水。到后来见山不是山，

见水不是水。而今依前见山只是山，见水只是水。

________释普济，《五灯会元》

对于成功设计SaaS应用而言，系统的适用性及扩展性本是极其重要的。本章讨论的设计方案和模式为您提供了至关重要的信任基础。设计一套既能实现竞争优势又可充分满足数据共享和隔离要求的SaaS数据体系结构，并不是一件容易的事。不过，您可借助这些方案和模式来明确并解决将面临的众多关键性问题。尽管系统的扩展性没有一个统一的评价标准，也没有一项详尽的技术来完整地解决这个问题，不过本章的内容都有助于您充分利用可配制性、可扩展性以及多用户效率等基本原则来进行设计，为SaaS应用创建安全可靠的可扩展数据体系结构。

14.1可适用性

我们的SaaS平台通过合理规划和标准设计可适用于不同行业、不同企业及所有合作伙伴的用户，建立统一的编码体系、数据字典，集中统一管理，并提供标准的数据接口定义格式。

l 通过DB2 V9.5的工作负载来达到系统的可适用性

DB2 V9.5的工作负载管理功能使您可以更深入地洞察系统的运行情况并更好地控制资源和性能。DB2 V9.5的这项功能执行以下任务：

² 通过使用工作负载定义自动标识工作、将工作负载分配给服务类并将资源分配到每个服务类，可以将工作划分为易管理的逻辑组。您可以捕获详细的工作负载概要文件和性能信息，以帮助优化您的工作负载定义和服务类定义。

² 您可以通过成本、时间和并行性阈值来控制执行情况，这使您可以控制流氓查询并有助于达到服务级别协议（SLA）目标。通过使用阈值，系统可以自动对不良情况作出反应或在它发生前进行预测。当您控制了长时间运行且复杂的查询的影响后，您就可以使事务保持平稳运行。

² 您可以跟踪处理的每个阶段，以便可以为用户提供最新的状态信息。

下图显示如何评估发送至数据服务器的多个请求、如何将它们分配到特定的工作负载以及如何在适用的服务类中执行这些请求。不能与您定义的工作负载匹配的请求将分配到缺省工作负载，然后在缺省服务类中执行此工作负载。

图14-1 服务类和工作负载

l 工作负载管理引擎

SLA是组之间的一个正式协议，它定义组之间的期望值并包含服务、优先级和职责等各项的目标。SLA目标通常使用响应时间目标来表示。例如，特定的“人力资源”报表可能需要在平均5分钟内运行完成。

增强的DB2工作负载管理功能可以帮助您标识一组已定义的数据库活动并将它们隔离在自己的执行环境中，您可以对这些活动分配达到您的目标所需要的适当资源。在环境或服务类中，您可以显式管理系统资源，以便较重要的资源可供较高优先级的工作使用，并可以控制或消除与较低优先级工作的争用情况。

您通过对每种不同类型的客户使用服务类来隔离数据服务器上的活动。例如，您可以按组来设置工作负载，然后对该组分配一个具有较少资源的不同服务类。在您设置服务类后，您可以轻松地收集并监视聚集活动统计信息，以确保满足每个客户的SLA目标。从而使您可以根据接收到的服务级别对每个客户进行收费。

示例如下：我们假设一个SaaS应用程序可能由三个不同用户使用。用户1可能希望响应时间平均值小于2秒，而用户2和用户3可能希望5秒之内的平均响应时间；从这可以看出这里有两个服务等级，服务等级1需要的服务质量是使服务的响应时间在2秒之内，服务等级2需要的服务质量是使服务的响应时间在5秒之内。于是我们在DB2 V9.5中定义两个服务类：

ServiceClass1（这个服务类具有更多的系统资源）和ServiceClass2（这个服务类具有较少的系统资源）；然后把ServiceClass1赋给用户1，ServiceClass2赋给用户2和用户3。通过这样的配置，我们就能够实现所需要的功能。

14.2 可扩展性

大型企业软件旨在让数千人同时使用。如果您有过开发此类企业应用的经验，您肯定已亲自遇到过创建可扩展架构的重大挑战。对于SaaS应用而言，可扩展性更为重要：您所支持的用户数量，是单个客户的平均用户群乘以客户总数。对那些习惯于设计内部企业软件的ISV来说，支持这样大规模的用户群就如同从低级别联赛进级参加顶级联赛一样：规则是熟悉的，但赛事本身则是完全不同的级别。这时您所构建的不是一个广泛部署的业务关键型企业应用，而是一个因特网级的系统，需要积极支持数以百万计的潜在用户群。

14.2.1 什么是可扩展性

l 什么是扩展性？

扩展性是指根据增加的用户或交易，通过添加硬件，按比例提高系统容量的能力。通过添加硬件，可扩展的系统可以处理增加的用户和交易，同时不影响响应时间和用户体验。在可完全性扩展的系统中，通过将处理能力和其它硬件资源扩大两倍可使系统容量也扩大两倍，同时不影响响应时间。

一个真正可扩展的企业级报表应用程序平台应特别设计，从而使用户操作和请求不会相互干扰。即使在相对于可用的硬件，负载十分繁重的情况下，响应时间也应保持在可接受的水平，即小于5秒。适当性强的可扩展企业级报表平台可通过增加硬件来有效解决性能问题，全部的硬件均得到有效的使用。

l 扩展性的重要性

基准测试能有力说明产品的性能和扩展性。而无论企业级报表应用程序大小如何，性能和扩展性均是关键要求。深入研究基准测试结果之前，不管其应用程序的大小如何，首先应了解扩展性以及它对所有组织如此重要的原因。

可扩展的架构凤毛麟角

虽然扩展性是企业软件应用程序的关键因素，许多企业软件应用程序也声称具有该性能，但真正可扩展的架构可谓凤毛麟角。这是因为可扩展的架构：设计和开发极其困难，需要深入了解某些计算机科学最先进的概念，需承担开发产品功能的大量的前期费用和时间。而最终用户又不能看见产品功能，因此很难很好地进行“演示”。

在开始设计系统架构时，必须首先考虑性能和扩展性。这就象在砌起第一面墙后就不能再为房屋添加坚实的基础一样，在产品开发的后期无法将扩展性和性能添加到系统架构中。

14.2.2 可扩展性的的要求　　

应用的可扩展性包含两个方面的要求：

（1）高效地利用应用资源，从而最大限度地提高并行性。

（2）当原先的服务器资源确实无法满足不断增加的用户数量时候，可以很方面的通过向上扩展（提升硬件性能）或横向扩展（增加硬件数量）来提高整个系统的并发处理能力。

可扩展性并不仅仅是SaaS面对的难题，所有基于Internate的大型网络应用队会面对这样的挑战，所以网络上相关的资料很多，大多谈及大规模企业应用的体系结构设计的主题，都会涉及到对可扩展性问题的讨论。

14.2.3 可扩展性的技术支持

l 应用的无状态模式

我们需要研究如何设计应用，使之运行在无状态模式下。也就是说，所有必需的用户和会话数据都存储在客户端或分布式存储设备上，任何应用实例都能访问。无状态是指每个事务处理都能由任何实例来完成，用户在一次会话中可用众多不同的实例进行事务处理，但用户本身并不知情。比如我们在做Asp.net开发的时候，如果用Session变量来存储状态信息，因为它需要占用服务器资源，当您想增加机器以扩展性能的时候，它们会起阻碍作用，因为Session是与特定机器相关连的。在这方面，也许我们可以参考EJB中的关于无状态会话Bean，以及其管理器无状态管理器的实现。其实，internet能发展到今天的规模，跟http这个无状态的协议应该有很大的关系，而internet的扩展性已经在现实世界中被印证了，所以如果我们能尝试着去理解整个因特网的结构特点，也许我们对如何建构一个高可扩展性的大型系统会有更深的了解。另外，从SOA的角度来讲，提倡的Service一般是Stateless的，给定什么样的输入，就会有对应的确定的输出。一旦服务有了状态，就无法方便的使用对象池来减少对象的数量，从而提高了负载。

l 大型数据库的分解、重构技术

MySpace是一个过亿注册用户的超大型网站，在三年的发展过程中，它完成了从一个单服务器到及具扩展性的架构的变化，我想变化其实对于我们研究如何建立一个可扩展的系统其实有很强的借鉴意义：

（1）最早。两台Web服务器，一台数据库服务器，和我们目前的结构是完全一样的。在初期的发展中，MySpace就是通过添加新的web服务器来提高性能的，直到其数据库服务器超载。

（2）50万用户。要增加数据库，这时候面临着保证数据一致性的问题。在第二代架构中，他们启用了3个SQL Server数据库服务器，一个为主，接受所有的数据提交，并将内容复制给另外两个，由它们全力向用户提供数据。在这个架构中，通过增加辅数据库服务器的方法，可以有效应对系统访问量的增加。

（3）100-200万用户。数据库服务器开始受制于I/O容量。这时候，把所有业务放到一个DB上看来已经不行了，于是他们对数据库的架构进行了垂直分割，不同的数据库服务器服务于不同类的功能，有的负责登录，有的负责博客等。另外，但用户达到200万的时候，他们启用了存储区域网络（SAN:Storage Area Network）。按MySpaces的说法，此举极大提升了系统的性能、正常运行时间和可靠性。

（4）300万。垂直分割不够用了，毕竟有些信息（如用户表）需要在所有DB中共享，维护数据一致性的开销很大。另外，有一些应用增长太快，其专用DB压力太大。这时候，需要进行向上扩展（Scale Up:升级服务器）和向外扩展（Scale Out加强分布式能力，用大量便宜的服务器来分担压力）的抉择。为了尽量少改动以前的代码，他们先考虑了向上扩展，研究了如何使用32CPU的服务器的问题。但最终，他们还是走上了向外扩展的道路，开始提炼分布式计算架构（这是向外扩展架构必须面临的问题，大厂商如Google甚至开发了自己的分布式文件系统）。这时候，前面被拆分的应用在逻辑上又被整合了起来。并且，用户以百万为一组，被分别存储不同的DB。当然会有一个特殊的DB来控制所有的帐号和密码，但其功能单一，也就比较容易控制负荷。

（5）1000万。采用了新型的SAN，更改了SAN和数据库的绑定方式。在Web服务器和数据库服务器之间加上数据缓存层，他们说这是一开始就应该做的事情，但他们成长太快，以至于一直没有实现。

（6）2600万。采用SQl Server2005，因为支持64位的数据库可以使用更多内存。

从MySpace的变化可以看出，随着用户量的增加和用户数据量的积累，数据库服务器将日益成为瓶颈。在它成为瓶颈之前，充分做好各种相关的技术准备工作是必须的。

l 线程和网络连接等汇集资源的共享（负载均衡）

将线程、网络连接和数据库连接等资源集中，这有助于使计算资源最大化，并提高我们预测资源使用的能力。当然，在这些方面，其实IIS和ADO.NET等基础的资源服务系统已经作了很多相关的考虑，我们做的资源调度应该是基于这些服务器之上的。我们可以参考.Net对线程池的管理，也可以参考ADO.NET对连接池的管理。另外在进行资源调度和管理的时候，要充分考虑整个网络的拓朴结构，并充分借鉴分布式系统在实现方式特别是资源调度算法上的一些考虑和特点。

所以，这里总的来说强调的是一种负载均衡的概念，而负载均衡除了上面提到的这些软件方面的手段，可能还包括对一些硬件设备的认识和选购，特别是对各种负载均衡服务器的性能和功能的掌握。

l 其他

（1）多级缓存技术。缓存，说白了就是用空间换时间。越是并发的系统，越需要仔细考虑缓存的问题，我们每发现一处可以在多用户间反复重用的数据并将其加入缓存，都有可能使这部分数据的生成效率提高上千倍（如果这个数据可以在上千个用户间共享的话）。另外，如何提高缓存的命中率，也是当我们的网站逐渐变大之后，越来越重要的问题。还有，对于memcache这类的比较牛的缓存解决方案，也许我们也需要深入研究它与我们项目的结合点。

（2）仔细研究数据库的锁定方式，在对数据库操作的时候，尽可能锁定小范围的数据集合。采用既可以实现并发最大化，同时还能使排它锁定最小化的方式写入数据库操作。例如，在执行只读操作时，不要锁定记录。这些环节看似虽小，其实对整个系统的并发性都有显著的影响。

14.3 可扩展性的分类

14.3.1 应用扩展

当然，您的解决方案很难成为像Hotmail那样拥有庞大的用户群（如果确实拥有这么多用户，真该恭喜您！）。不过，可扩展性方面的挑战却是相同的。

应用可向上扩展（将应用转移至更强大的较大型服务器上），也可横向扩展（在更多的服务器上运行应用）。对所有曾用全新计算机取代过旧计算机的人来说，向上扩展并不陌生，该解决方案通常更适用于那些无需为众多并发用户提供服务的小型应用。不过，就SaaS而言，横向扩展通常是扩充容量的最佳办法，这一点我们在SaaS成熟度模型中已经探讨过了。设计出色的SaaS应用可横向扩展到众多服务器上，每台服务器都运行应用的一个或更多实例。设计“横向扩展型”应用的一些设计指南如下：

l 设计应用运行在无状态模式下，所有必需的用户和会话数据都存储在客户端或分布式存储设备上；

l 任何应用实例都能访问。无状态是指每个事务处理都能由任何实例来完成，用户在一次会话中可用；

l 众多不同的实例进行事务处理，但用户本身并不知情；

l 设计应用进行异步I/O操作，这样应用在等待输入输出完成时也能进行有用的工作；

l 将线程、网络连接和数据库连接等资源集中，这有助于使计算资源最大化，并提高您预测资源使用的能力；

l 采用既可以实现并发最大化，同时还能使排它锁定最小化的方式写入数据库操作。例如，在执行只读操作时，不要锁定记录。

14.3.2 数据扩展

随着数据库向越来越多的用户同时提供服务以及数据库的不断扩大，执行查询和搜索等操作所需的时间也将大幅延长。SaaS应用通常使用相同的数据库同时为数以千计的客户提供服务，因此特别容易受到该类型性能降低的影响。所以，我们要为未来的发展做好充分计划，这一点相当重要。

扩展数据库的简便方法之一就是进行分区，将数据分入较小的块，以提高查询和更新的效率。我们不妨考虑建立分区策略，明确数据分区的最佳途径。例如，如果应用的客户来自世界各地，那么我们可采用地理分区策略，属于欧洲客户的数据位于一个分区，属于亚洲客户的数据位于另一个分区，以此类推。

就大多数情况而言，数据库的大小会不断扩展。因此，我们还应采取一个适当的动态再分区策略，将已经分区的数据进行再分区，以满足性能和扩展的需要，这一点也相当重要。

14.3.3 操作结构

第三个重大思维转变就是优化应用的操作结构：将应用提供给客户需要做哪些工作？如何保证应用的可用性以及如何经济有效地确保应用良好运行？对于许多ISV而言，他们从未帮助客户运行过数据中心，这可能也是SaaS供应商最不熟悉的环节。SaaS供应商不仅应是软件设计和市场营销专家，还需是操作和管理方面的专家。

微软操作框架（MOF）等资源能够针对维护系统可靠性、可用性、可支持性和易管理性等提供大量有益的相关指导。除MOF能解决常见操作问题外，SaaS模式还具有一些自身特有的难题。

14.4 数据模型的可扩展性

l 采用数据模型延伸

不管您使用哪种方法创建可延伸的数据模型，都必须配套采用相关机制，以便将更多的字段集成至应用功能中。客户实施的定制字段将需要对商业逻辑做出相应的修改（这样应用才能使用定制数据），或修改演示逻辑（这样用户就能输入定制数据，并获得输出），或者二者同时修改。这样，您向客户提供的配置界面应使其能够对所有三种模式进行修改，最好使用集成的模式进行修改。

l 可扩展性模式

大型企业软件旨在使数以千计的人同时使用。如果您有过构建这种企业应用的经验，您对创建可扩展体系结构所面临的挑战肯定就具备了第一手经验。对于SaaS应用来说可扩展性尤为重要，因为您必须支持所有属于客户的数据。对习惯于构建内部部署(on-premise)企业软件的独立软件服务商(ISV)来说，支持这样大规模的用户群就好像从低级别联赛晋级参加顶级联赛一样：规则虽然差不多，但赛事本身则是完全不同的级别。这时您所构建的不是一个广泛部署的业务关键型企业应用，而是一个因特网级的系统，需要积极支持数以百万计的潜在用户群。

数据库应该能够具备纵向可扩展性（移植至集成了更强大处理器、更多存储器以及更快速磁盘驱动器的更大型服务器）及横向可扩展性（将数据库在多个服务器上进行分组）。在对共享数据库与专用数据库进行扩展时，应分别采取不同的适用战略。

l 扩展技术

在对数据库进行横向扩展时主要涉及两大工具，即复制与分组。复制是指将数据库的部分或全部数据拷贝到其他位置，然后使副本与原件同步。在单主机复制情况下，只能写入原始主机（即复制主机），这种情况比多主机复制（可写入部分或全部副本，并用某种同步机制来解决不同数据副本间的差异）要便于管理得多。

开发扩展战略时，重点在于区分扩展的是应用（增加应用承担的总工作负荷）还是数据（增加数据存储和工作的容量）。

分组是指从数据库中去除数据的子集，将剪切的数据转移至其他数据库或相同数据库中的其他表。您可通过对整个表格的重定位来实现分组，也可将一个或多个表格横向或纵向分为更小的表格。横向分组是指我们用相同的方案和结构将数据库分为两个或更多较小的数据库，但每个表格中的行数减少。纵向分组是指我们将一个或更多表格分为较小的表格，行数相同，但每个表格包含原始表格的列的子集。我们在扩展数据库时，通常结合使用复制和分组。

l 基于用户的横向分组

共享数据库如果不能满足基本的性能需求，如同时访问数据库的用户太多，或者数据库的容量不足导致查询与更新所需的执行时间过长，抑或是运营与维护任务开始影响数据的可用性等，这时我们就应当对其进行扩展。

对共享数据库进行横向扩展的最简单方法是根据用户ID通过基于行的横向分组来实现。SaaS共享数据库非常适合横向分组，因为每个用户都拥有自己的数据集，因此您可轻松地针对不同的用户数据进行移动。

但是，如果您有100个用户，并希望将数据库分为五块，那么不能简单地认为我们可以一次分出20个用户将其转移。不同用户对应用的要求可能截然不同，我们必须进行认真的规划，避免简单地分出较小的区，结果有的小分组仍然使用非常紧张，而有的小分组则资源遭到浪费。

如果因同时访问数据库的最终用户过多而影响了应用性能，那么这时您可考虑对数据库进行分组，对每台服务器上正处于工作状态的最终用户账户的总数进行平均。举例来说，如果现有的数据库用户A和B各有600个正在工作的用户，而C、D和E各有400个工作用户，那么您在数据库分组时可将C、D和E转移至新的服务器，这样两个数据库分别为1200名最终用户提供服务。

如果问题出在数据库的容量上，比方说执行查询等操作所需的时间过长，那么我们应采用更高效的分组方法来解决数据库的容量问题，重新分配服务器上的用户数量，使每台服务器上的数据量大体相等。

您选择的分组方法可能会对应用开发造成极大影响。无论您选择哪种方法，重要的是您都应准确调查并核实分组决策的标准。应在构建应用时加入对监控功能的支持，这样您就能准确了解用户的使用情况和需要。此外，您可能还需要定期进行数据再分组，因为您的用户会不断发生变化，工作方式也会有所差异。选择分组策略时，要确保不影响生产系统，而且只要有必要分组就能方便地执行。

一家用户有时可能会有非常多的最终用户同时使用数据库或者所使用的数据量非常大，这时有理由将其转移到自有的专用数据库上。如欲了解执行扩展的更多详情，敬请参见下一章节内容“单个用户的横向扩展”。

基于用户的横向分组模式适用于共享架构应用，其对数据库的扩展任务提出了一些特殊的限制。采用这种方法，我们能对共享数据库进行扩展，并同时避免影响应用或性能（如无意中或毫无必要地将一个用户的数据拆分到两个或更多服务器上）。

l 单个用户的横向扩展

如果部分或全部用户都存储并使用大量数据，那么用户数据库就会变得相当庞大，这时就有理由使整个服务器专门为一个用户的数据库提供服务。这种情况下的可扩展性挑战类似于传统的单用户应用所遇到的问题。如果针对一个庞大的数据库采用专门的服务器，那么纵向扩展就是解决数据量不断增长的最简单方法。

如果数据库不断增长，那么将它转移到更强大的服务器这种做法最终在成本上也会变得不可取，这时我们就要将数据库进行分组，横向扩展到一个乃至更多服务器上。专用数据库的横向扩展不同于共享数据库的横向扩展。对于共享数据库而言，最有效的扩展方法是将用户的整个数据集从一个数据库转移至另一个数据库，因此您所用的数据模型的性质并不重要。如果扩展的数据库是某个用户专用的，那么我们就必须分析存储数据的类型，以明确最佳的扩展方案。

我们应考虑的一些横向扩展指导原则如下：

² 用复制方法来创建不常更改的数据的只读副本。有些类型的数据很少更改，或者根本不发生变化，如部件号或雇员社会保险编号等。其他类型的数据会在给定时间内经常发生变化，并进行归档，如采购订单等。这种类型的数据很适合从参考数据库中进行单向复制；

² 位置、位置、位置。要确保数据贴近引用它的其他数据。（这里所说的“贴近”，是指逻辑上的靠近，而不是物理上的接近，不过逻辑上的靠近常常同时也暗示着物理上的接近）。我们在决定是否将不同的数据类型分开时，要考虑其彼此之间的关系，在适当时候用复制方法在不同数据库间分配引用数据的只读副本；

² 举例来说，如果定期检索客户记录这一工作需要从另一表格中选择客户近期的采购订单，那么我们就应在相同的数据库中保留上述两个表格，或通过复制来创建适当数据类型的副本。应尽量找到数据的自然划分，尽可能减小跨数据库之间的通信。例如，我们通常可根据地理位置将与特定地点关联的数据分在一起；

² 明确不应被分组的数据。仓库库存量等资源数据通常不适合复制或分组。我们可用横向扩展技术将其他数据从服务器上移走，为资源数据腾出更多的增长空间。如果您已经移走所有能移走的数据，但还是遇到问题，那么就应考虑纵向扩展，为资源数据采用更大容量的服务器；

² 必要时采用单主机复制。使相同数据的多个副本实现同步非常困难，因此只要可能，我们就应避免采用多主机复制。如果必须更改已复制的数据，那么只能将更改写入主副本。

² 以上模式适用于全部三种方案，不过只有当单个服务器不能满足用户的数据需要时才会用到这些方法。

² 对于独立数据库方案而言，如果用户的数据存储要求不是很高，那么每台服务器可支持数十个数据库；

这时，对于特定服务器的扩展而言，我们只需将一个或多个数据库转移到新的服务器上，并修改应用的元数据以反映新的数据位置即可。

14.5 可扩展性的架构

l 成功的规划是扩展性的最好架构

不管应用程序的规模大小如何，企业都仅应考虑在公布、公开、详细的基准中证实具有极佳的扩展性和卓越性能的报表解决方案。

如果应用程序不具备扩展性，必将自断其成功之路。随着在不能扩展的系统上的用户数量不断增长时，响应时间将不断延长，以至用户无法接受。更糟糕的是不管增加多少硬件，系统都无法处理更多的用户。事实上，一些企业级报表应用程序平台在添加硬件后性能更为糟糕，这种现象称为“消极扩展性”。

l 用户数量增长不可避免

如果企业级报表应用程序取得成功，用户的数量必将不断增长，并远远超出原先估计的用户数量。如果企业内部所有用户都已采用程序，大多数组织接着将应用程序向合作伙伴和客户扩展。此外，随着报表应用程序的价值和成功得到越来越广泛的认可，在同一报表基础结构上开发和运行更多的企业级报表应用程序，用户数量则立即大量增加。最后，当今商业环境风云变幻，收购和并购时时发生，因此用户数量将不可避免地增长。

l 人数增长＋不能扩展的报表＝灾难

成功的报表应用程序必然导致用户数量不断增长，但如果该应用程序是建立在不能扩展的平台之上，所有这种增长可能会带来极大的麻烦。

在不能扩展的架构中，用户请求相互干扰。随着用户数量的增加，用户请求和作业之间的“冲突”将呈指数的增加，导致用户响应时间增长，服务不稳定，以及糟糕的用户体验。增加硬件可以有限地解决问题，但冲突仍呈指数增加，导致每个增加的CPU使用效率越来越低。最终在某一点，添加再多硬件也不会改变用户响应时间，增加的用户也无法获得支持，这就意味着系统已陷入绝境了。

14.6 适用性及扩展性的解决方案

SOA是英文Service-Oriented Architecture，即面向服务架构的缩写。SOA体现的是一种新的系统架构。在基于SOA架构的系统中，具体应用程序的功能是由一些松耦合并且具有统一接口定义方式的组件（也就是service）组合构建起来的。

l 基于SOA应用

图14-2 SOA参考模型

l 基于SOA的业务整合

图14-3 基于SOA应用

1. 表现层

组成：表现层显示模块、表现层配置模块。

2. 对外业务逻辑层

组成：对外业务逻辑API。

将所有的内部商务逻辑通过不同的封装以便提供外部的各种调用。

微软平台开发工具：WCF or Web Servicese。

3. 商务业务逻辑层

组成：多种自己业务逻辑、外部的业务逻辑。

整合所有的商务业务逻辑包括内部和外部调用的服务。

微软平台选择开发工具：WCF和Biztalk。

4. 数据层：

组成：多个自己业务相关的数据库。

这样增加扩展模块可以在业务逻辑层完成，对于数据库的调整和其他调整可以不影响其整体框架和外部开发。

l 从eBay的SOA解决方案谈SaaS扩展性

SaaS开发扩展性是非常重要的，对于ISV来说。将软件由卖Copy转移到卖服务后，将失去客户端软件特有文件格式和对于竞争对手的优势。同类产品的竞争将会在本身提供的服务和后期服务扩展性上展开。这样，对于一个好的扩展性的平台，在市场上将会有非常重要的作用。

SOA是一种IT体系结构样式，支持将系统平台业务作为链接服务或可重复业务任务进行集成，可在需要时通过网络访问这些服务和任务的一种体系结构。对于SaaS来说SOA的关键是一种“松散耦合”的应用程序组件！这样后端扩展将不再限制在特定数据库层面。

对于SOA和SaaS的结合其实已近有了一个很好的例子：eBay，有超过40％的eBay列表是通过调用eBay提供的API实现的。

对于这些eBay API的使用者，eBay按照个人用户免费和商业用户收费。

详细请看下面的收费标准：　

图14-4 eBay的收费标准

另外来看看整个eBay的API服务体系架构。一共包括４个部分：

l 业务逻辑层API（属于eBay内部的处理方式）

l 业务对外API（例如：eBay API（XML）和SOAP API）

l 提供ISV开发Web服务SDK（例如：eBay SDK for based on.net）

l 应用程序（例如：Windows平台的和其它平台的应用）

对于整个SOA架构来说，上图关键是提供了一个很好的业务层API设计，对于系统内部的时限可以通过各种管理模块的组合来完成。例如：商品管理模块、用户管理模块、搜索模块等等。但是对于外部来说，仅仅需要符合业务对外API就可以开发自己的应用。

按照这种IT体系架构来扩展设计SaaS架构可以这样扩展，主要需要ISV自己独立完成表现层的开发。对于SaaSISV可以构建一个如下的一个服务框架。

14.7小结

本章对单实例、多用户数据体系结构的论述远不够全面。在本系列的后续文章中，我们还将讨论相关方法，并通过演示和流程定制等来帮助用户更好地利用数据模型扩展。