面向服务的虚拟化提升SOA价值

　　面向服务的虚拟化(SOV)是指模拟构成SOA应用软件资产具体行为的IT策略，可以将开发与测试团队从对服务部署与服务实现层的依赖性中分离出来。

　　使用服务器的虚拟化技术可以即时减少硬件与配置成本。但是，仅仅考虑硬件的虚拟化是不够的，我们应该充分发挥虚拟化技术的其它优势。如果我们能在主要企业软件使用方面发挥虚拟化技术的优势，将可以获得更大的效益，毕竟80%以上的IT预算都用在这些企业运营、开发、支持、维护所需的软件上。

　　现在，很多主要业务都建立在以分布式技术和新功能为基础的系统上，比如面向服务的架构(SOA)。虚拟化可以为这些系统提高产品质量、缩短上市时间。但是，有些SOA功能并不在整体团队的控制范围，该如何通过虚拟化提高功能质量、缩短上市时间呢？为实现这个目标，充分发挥SOA的价值，扩展型企业必须虚拟化服务的共享行为。

　　SOA虚拟化的三种方式

　　实现SOA虚拟化有三种截然不同的方式：

　　硬件虚拟化可以在同一物理硬件设备中以虚拟机的方式运行多个操作系统拷贝。这为数据中心里应用程序的使用节省了大量成本，有极好的弹性和风险管理能力，并为复制SOA系统测试平台提供了有效的方法。

　　虚拟端点允许SOA为所调用的服务提供虚拟地址，隐藏服务使用者的实际地址。这是实现SOA应用程序动态过程的理想条件。因为作为业务流程的一部分，服务的物理地址(或URL)可能需要根据使用时间与使用情况而改变。

　　虚拟服务不仅可以用于SOA测试，也可以从整体上将开发与部署实践流水线化，从而提高效率。

　　本文主要讨论第三种虚拟化技术：虚拟服务。这是数据中心外部的虚拟化。在SOA应用生命周期中的其它部分，创建虚拟测试平台的能力也仅限于此。为验证与开发SOA，业务通常依赖于一些具体的实现。但是，现有的硬件虚拟化技术还无法复制这些复杂的交互环境。因此，我们需要将虚拟化技术扩展应用到在这些环境中运行的、具体的分布式组件与服务中。

　　不能虚拟化的SOA缺乏灵活性

　　硬件与数据中心层次上的虚拟化因其节省操作成本可以即时获得可观的回报，有可能立即节省几百万的IT成本。

　　然而，将组件或服务的开发任务分布到多个团队时，我们经常会忽视这些团队在完成自己的开发或测试目标时，仍然需要访问其它组件的最新版本。为实施完整的业务流程，各团队之间仍然必须保留很强的依赖性与互通性。对大规模的企业系统来说，这极其严重地降低了SOA的投资回报率。

　　我们可以通过面向服务的虚拟化(SOV)来解决这个问题：模拟所部署的软件资产的行为，构建架构未完成的部分，最终形成完整的SOA企业应用。

　　如果不使用面向服务的虚拟化技术，是很难在大规模的企业应用中最大化SOA价值的。

　　SOA实现的绊脚石

　　公司可以通过最佳SOA实践认识业务的灵活性和成本效益。然而，当SOA应用需要为满足大型企业的具体需求而进行调整时，即使使用虚拟服务器技术，最好的SOA架构与治理策略仍显不足。这是有许多原因的。

　　1. 系统共享资源的冲突

　　可以认为，SOA就是关于如何以共享资源的方式构建企业系统。然而，SOA实现初期几乎都有对共享资源访问方面的问题。关键ERP系统或主机系统的管理人为保护产品应用的安全性，可能会限制开发与测试团队对应用程序的直接访问以避免无法预料的问题。

　　另外，即使允许访问，具体的服务也经常受到SOA环境下各个企业需求的限制。当团队必须排队等候访问开发与测试的具体环境时，灵活性就大打折扣。在大规模企业应用中，单单利用硬件虚拟化技术创建另一个环境实例花费的成本相当可观。

　　2. 非持续性的开发与集成周期

　　开发人员需要使用服务界面模型作为容器控件以测定他们开发的服务与其它服务之间的互通性。比如，一个开发团队在建立客户数据，同时另一个开发团队在创建财务数据。由于两种应用是前后顺序开发的，因此开发到一定程度时每个团队必须依赖另一个团队的服务才能完成后续开发。各团队必须能对其它临近或已经完成的服务进行访问，以验证他们自己开发的服务可以正确地交互。

　　SOA以松耦合的服务组件的方式实现灵活性，因此这些组件应该可以被更小更分散的团队平行开发或集成。但这些组件之间仍有相互依赖性，如何才能具体实现这种层次的平行呢？

　　请看一个典型的项目计划图。项目中总有一个第二开发团队开发下一组件之前必须满足的依赖性组件。这就是我们希望从SOA中分离出来的模型。

　　3. 持续增长的复杂性与相异性

　　虽然SOA的初衷有很大一部分是为了实现Web服务(WSDL/SOAP)，但仍然只有50%的顶级企业其SOA是以Web服务为目的。另一部分企业实施SOA是因为有许多可以创建SOA中间件的技术对他们来说非常有用，甚至优于Web服务包，比如使用对Web服务几乎没有依赖性的企业服务总线。

　　为保证SOA的质量，团队必须验证不同技术下的实现与副作用，而不能仅仅测试他们选择的Web服务或中间件层。

　　4. 维护与支持SOA测试环境的高成本消耗

　　为实施SOA应用的服务，许多企业尝试复制并维护自己的测试环境。然而，复制公司各个阶段所有需要交互的组件需要极高的管理成本。包括需要很高的配置、授权与维护成本，以保持当前的测试版本是最新的。即使这个测试版本是运行在虚拟化的硬件设备上，也同样需要很高的授权费用。许多采用SOA架构的企业系统过于臃肿，有太多需要虚拟化的操作。

　　与其尝试复制诸多随时可能变化的服务来创建臃肿的测试基础设施，不如发展将各个团队从对实现的依赖性中分离出来的策略。这将提供可行的、对当前部署进行测试的方法。

　　5. 大量数据与系统记录

　　最后也是最难解决的一个问题是，实现具体的SOA企业应用所需管理的大量系统记录与数据。为得到测试SOA应用所需的具体结果，需要一整套具体的业务数据作为输入，然后创建一个可供测试的环境。

　　虽然可以根据在架构设计过程中产生的数据元集实现大部分与服务对应的交互，一旦经过连接端点的理想模型阶段，开发团队仍然需要应付CRM主机或企业系统，以及这些系统的管理人员。这些系统里存储着不同客户几年的数据与业务逻辑。实现一个完整的系统与数据镜像进行测试需要另一个企业授权和实现团队，这种做法的成本实在太高。

　　面向服务的虚拟化技术

　　面向服务的虚拟化(SOV)是指模拟构成SOA应用软件资产的具体行为的IT策略，可以将开发与测试团队从对服务部署与服务实现层的依赖性中分离出来。

　　SOA涉及以虚拟服务的方式建模、模拟设计，及已部署服务的实践，这可以让外部SOA团队开发并测试自己的服务和业务流程，而无需依赖具体的服务实例。当团队从对服务部署和实现层的依赖中分离出来时，预期的SOA在灵活性、上市时间和实施成本方面的优势便可以得到充分的显现。简单地说，可以认为SOV与SOA的关系就像硬件虚拟化技术与数据中心一样。

　　SOV应用案例

　　SOV不只可以影响已完成应用的质量，还可以加速SOA周期中的开发与治理过程。我们可以找到很多可供实施SOV实践企业参考的案例。

　　SOV用例1：灵活开发SOA新功能

　　大多数企业已经不再使用过去单一、拖沓的实现方法在集中的管理机制下顺序进行开发、测试和发布全部应用。

　　现在，这些应用由松耦合的服务构成，由灵活的运行时业务流程实现弹性，由灵活的开发人员构成分布式团队进行管理，最终实现可以满足不断变化的业务需求的、灵活的SOA应用基础设施。

　　为发布满足业务需求的服务，开发人员与质量保证团队还必须对开发中的虚拟服务进行测试。如果公司要取得SOA的灵活性，那么所有这些团队必须按照自己的开发进度平行开发和发布各自的服务，而不能依赖其他的团队。

　　使用SOV建模

　　这些团队应该以虚拟服务的方式对所依赖的服务进行建模，而不必等待其他团队提供对已完成的服务的访问。

　　需要其他团队提供的服务拷贝以进行测试的团队，可以根据服务的行为、控制与响应方式，以及服务的实现基础和数据来开发虚拟服务。

　　开发过程中，开发人员也可将不完整的、或者即将完成的服务版本以虚拟服务的形式发布。

　　虚拟服务是供其他开发和质量保证团队用来测试自己团队所开发服务的。

　　这可节省开发与质量保证测试的成本，以及编写准确的测试客户端或“模拟服务”的时间。

　　可以在企业中实现高平行、灵活的开发与测试协作，减少新功能的开发时间，并可更精准地预测上市时间。

　　实例：实现经济服务公司发布灵活性

　　某家在经济服务市场占主导地位的公司将其集中的开发能力以类SOA的方式分为不同的业务流程交给特定的开发团队完成，以达到缩短服务实施周期的目的。虽然初期结果显示实施速度确实有所提高，但随着越来越多的支持SOA应用的服务部署，产生越来越严峻的客户服务方面的问题。

　　为解决这个问题，公司恢复了对发布服务的集中化管理，要求在11月之前提交所有“终端”服务。这样，经过两个月的测试周期，可以在2月前创建一个完整的SOA环境。但如果在以年为单位的测试周期中产生任何错误，系统管理人员就必须将服务换回前一版本。这意味着在正常情况下，一年只能进行一个开发周期，发布一个版本。不管从哪方面来讲，这都是非常不灵活的。

　　后来公司引进SOV模型，很大程度地缩短了开发周期。开发团队以虚拟服务的方式对环境进行建模，并在此环境下进行按需测试。他们还可以提供托管的虚拟服务，方便其它开发团队更早地进行测试。结果，公司解散了管理委员会，实现了每季一次的发布周期，周期变得更有持续性和灵活性，并可根据客户要求更快地进行编译和测试。

　　SOV用例2：复制完整的SOA环境

　　在内部应用开发过程中，在虚拟机上运行的虚拟化硬件和虚拟测试平台是一种很有效的复制服务器环境的方式，可以为新开发的组件提供针对现有软件的开发和测试环境。这种实践可以节省硬件与配置两方面的成本。

　　然而，SOA应用经常需要与第三方系统进行自由交互，而第三方系统一般不在集中的团队控制下。并且，SOA应用还需要与业务的基础系统(主机、ERP系统等)进行交互，而这些系统的实现可能要花费几百万美元的成本，并且储存有大量的关键数据。一般来说，开发过程中是禁止在这些系统上使用测试数据进行测试的，因为测试增加的负载可能会导致主要系统崩溃或者产生意料外的行为。并且，不管是从系统负载还是从配置成本方面考虑，用硬件虚拟化技术复制这样一个庞大的系统都是不可能的。

　　使用SOV复制SOA应用行为

　　即使用虚拟机复制部分功能，为完整的SOA应用实例配置与维护一个由独立组件组成的、完整的测试环境仍然需要巨大的的维护与支持费用。

　　SOV实践虚拟化了整个模拟测试系统的行为。各个团队对于测试或开发的复制需求由对所需的系统行为进行抓取和建模代替了。

　　以虚拟服务的方式模拟相关服务代替受到使用限制的具体应用，不管这些服务是由WSDL生成、基础的实现或集成层服务的模型。

　　在恰当的时间重新捕捉或建模新的虚拟服务组件，比花费数周甚至数月才能复制完成的SOA实例能提供更新的目标服务模型。

　　在SOA应用中不断实践所有系统，为具体的业务数据创建一个丰富的测试平台，进而使用这些数据从虚拟服务中获得更多动态变化的行为。

　　远离服务部署进行开发与测试(测试、开发与修改过程中，SOV不能取代具体实现中对服务的集成测试)。

　　使用这个模型，企业可以在硬件、软件和维护方面节省数百万美元的成本，并缩短产品上线时间。

　　实例：解决电子商务全面数据监控问题

　　某全球化的高科技生产公司要实现使用CRM平台、ERP系统及其它存储与逻辑系统的电子商务解决方案。基本的Web服务层的可扩展性和兼容性在相关标准下的测试比较容易，但背后的数据交互系统却无法测试，因为这些系统已在使用并管理着关键的指令。

　　公司并没有花费大量资金去复制这些系统，而是选择采用SOV过程捕捉了主机和与系统交互的服务层的上千具体事务处理和交互(包括正面与负面的结果)。然后，使用这些丰富的数据集为主机设计与真实行为相近的虚拟服务，让团队在预算范围内准时完成有高可靠性的新系统。

　　下一步：从SOV到SOA集成的转换

　　一旦完成面向服务的虚拟化所有方面的协作开发与测试，虚拟服务便进入具体的集成过程。SOV不能取代具体的SOA应用对集成测试、性能测试和功能验证的需求。如果服务不能正确地与满足业务需求的服务交互的数据元协作，仍然可能产生负面效果。

　　有效的SOV策略可以产生两方面的价值：

　　灵活性：可以最优化分散的SOA开发与测试团队之间的协作性，使团队进入更平行的开发与发布周期，缩短新产品与功能的上市时间。

　　降低成本：可以在软件授权、配置、维护、数据管理、开发与测试效率等方面为每个SOA环境下的开发节省几百万的IT成本。SOA应用的协作性与互通性越强，虚拟服务能带来的效益就越高。

　　总之，对于使用分布式团队与资源开发的大规模的企业应用来说，SOA的圆满实现离不开SOV实践。因此，我们应该进行面向服务的虚拟化实践，用SOV技术解决SOA实现过程中的障碍，让SOA为企业带来更大的效益。