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

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友