如何在乌“云”中达成有效的SOA治理

申请免费试用、咨询电话：400-8352-114

云计算主要是指一种按需服务的交付模式，可涵盖外包的和企业内部的各种平台，如今已成为一种新的、热门的服务模式。

然而云计算也引起了一些IT专业人士的苦恼，他们担心云服务可能会绕开企业辛辛苦苦建成的SOA治理手段的管辖。

在历经艰辛，对企业的Web服务环境好不容易实施了生命周期管理之后，这些IT专业人士们发现，为了跟上外包式云服务的蓬勃发展，他们可能不得不再一次另起炉灶，彻底重来了。

SOA治理（government）也称服务治理，指的是对一些关键性功能的生命周期实施一致性的研发、安全管理、性能管理和其他策略所采用的规则和工具，至于它们是在内部还是外部托管的则无所谓。

有效的SOA治理极其重要。它能够让组织对其分布式环境进行连续地规划、设计、验证、发布、配置、监控、修正、安全和优化等，可确保在企业应用环境中所部署的服务（无论它们是建立在云中，还是建立在主机或其他任何平台上）完全遵从各种管理实践、管理策略、运营规范和其他一些基本原则。

强大的SOA治理是控制云的关键

从某种意义上说，云计算可能会成为SOA治理领域的头等大事，因为云计算的存在使得SOA治理变得愈发重要。

从理论上说，“云”几乎可以将任何形式的IT功能——从应用到中间件、应用平台，甚至存储、进程和其他硬件资源转变成按需订阅的服务模式。

但是，在一个云计算的世界中，IT管理者们如何才能实施完善的管理呢？

“云计算重新激发了管理者们对于治理的兴趣，因为你必须管理跨办公场所的服务，甚至可能是跨越企业边界的服务，”Software AG的副总裁兼代理CTO Miko Matsumura说。“这样做不仅从治理的观点看是十分有益的，而且由于要整合适用于各个场所的云计算应用与基础设施，其复杂程度就要求有一个保障一切都能各得其所的治理框架。”

换句话说，云计算使得SOA治理的前景复杂化了，如果没有合适的治理框架，那么任何人就都可以在任何时候按照他们各自的愿望去部署新的云服务，任何人都可以随意编排云服务，从而导致一种复杂到难以复加的环境模式。

而且，云服务经常与企业的核心SOA环境会发生基本的冲突，结果是IT部门没有办法保证最佳的治理规则（如果有的话）能否适合于这种新的环境。

企业部署用来支持Web服务的很多组件，比如服务的登录入口、服务等级管理的代理和控制台等，在很多公用的或私用的云环境中不是部分缺少，就是完全没有的。

从SOA专家的角度来看，云环境是一块滋生着无文档、无支持、无标准应用服务的土壤。试想，如果企业内的使用者在未获得批准的情况下便开始访问外部提供的云服务，那将会成为怎样的乱局？

此外，外包的云服务可能不会遵守企业IT部门在构建企业内的SOA时所遵守的任何Web服务标准，比如说不遵守XML、SOAP（简单对象访问协议）、WSDL（Web服务描述语言）和UDDI（通用描述发现与集成）等标准。

就像不知不觉间爬满墙壁的藤蔓一样，毫无章法的公用云服务也正在坚定地渗透进企业的IT环境之中，而且还在抵抗着企业试图将其扫地出门的所有努力。这些不速之客如果真的在企业的运营环境中扎下根来，那么企业的IT部门就会发现，这种状况将会严重地妨碍通过监控或驾驭这些服务，以使其符合服务的设计、维护、监控、安全和升级等标准规范的任何努力。

治理需要新工具

除了对云服务是否合规的担忧之外，对云计算缺少了解也是一个令人担忧的因素。当然，如果云计算逐渐成为主流之后，这种担忧最终将不存在，但是现在看来这还需要有一个过程。

企业采纳云服务到了一定程度之后，就会有选择地将一些特定的应用和基础设施外包出去。“云”/SOA治理决策的首要原则之一就是要决定哪些服务应外包给公用的云，以避免内部应用环境不必要的重复部署。

“较重大的业务决策就得要围绕着哪些服务应该或不应该外包出去来做。另外就是要适度，要风险可控。”Interarbor Solutions的首席分析师Dana Gardner说。“一种风险就是人们刚开始进入‘云’中时，一般会是零敲碎打地消费外部服务，因此也不会有什么治理或者集中管理，更不会有全面的监管计划。”

他补充说，“另外一种风险是企业严禁使用云服务，严格执行集中管理制度，因而根本无法利用云计算所带来的任何好处。那么企业也会产生由此带来的机会成本，以及不能迅速采纳新技术而损害到应变与创新能力。”

在未来几年内，IT经理们应该能够看到，会有大量的SOA治理工具涌入云市场。“制定最佳的SOA规则，准备好更新的治理工具和更高的效率，并在跨服务和跨资源的范围内实施强大的治理措施，这将使IT获得巨大收益。”Gardner说。

云服务导致SOA治理复杂化

围绕云服务，产生了大量的炒作，因而在这样一种新环境下，我们很难找到有效的研究SOA治理的适当案例。不过，大多数公用云服务提供商都为管理应用、虚拟机、集成逻辑和服务等级的部署等提供了各种治理工具。随着此类厂商数量的增加，用于跨公用和私用云环境配置和管理服务的各种工具也在增加中。当然，由于云计算尚处于不成熟阶段，所以还没有一个成熟的SOA治理工具厂商能够支持基于云的应用、事务处理、消息或服务等级的管理。

而且，即便当云服务成为主流，即便当云服务厂商按照SOA治理规范来构建云服务，它们对于管理来说仍然是一个巨大的挑战。这种挑战主要来自这样一种新的错综复杂的模式组合：外包服务提供商，专利的公用云，虚拟化的资源池，以及混搭式的服务构建。

综合的SOA治理取决于所有的应用、平台和网络域都处在基于通用政策的管理之下，或者基于自治域的“联邦制度”（Federal）之下。

在一个企业中，或者在一个B2B供应链中，可管理的SOA联邦可能复杂到令人沮丧的程度。但是管理SOA联邦，即管理连接内部应用域和一个或多个外包商（包括像Amazon、Google、微软和Salesforce.com）所提供的外部应用域的联邦，将取决于合同谈判的技巧。

联邦制的云有助于治理

“公用云提供商正在谨慎地接近联邦制的概念，”加州大学计算机系教授Rich Wolski说。他也是开源云计算项目Eucalyptus的负责人。“在公用云之间，目前还几乎没有什么联邦制，但我们已开始看到有了一些关于‘资源跨云联邦’进行分配的讨论。”

Wolski强调指出，当云计算市场遭遇到无数有关联邦制的问题时，服务提供商和他们的企业客户就需要建立一种跨越多层的协议来统一身份认证管理、服务等级管理、存储管理和其他关键性的管理层面。

迄今为止，在企业的SOA环境和公用云服务之间还很少有或干脆没有策略上的联邦制。按照Thomson Reuters的体系架构与业务系统架构副总裁Christopher Crowhurst的说法，选择了公用云服务的企业，实际上处于相当大的风险之中。

“这样的企业把自己的基础设施和应用放在别人的云中运行时，服务商的性能就将成为企业的致命伤。”Crowhurst说。“在这种环境中，公用云服务商很少有责任会去协调自己的计划宕机时间与其客户们的应用运行需求。因此，把企业的应用建立在依赖公用云所提供的服务之上，又没有签订有关其API的稳定性或可用性优先的协议，那将是很危险的。”即便公用云的API没出现问题，“但这些接口一旦发生变化也不会及时通知你。”Crowhurst说。

Crowhurst劝告企业的IT部门应将很多治理特性写入与公用云服务商的合同中。最低限度，这些合同也应包含这样一些条款，例如，公用云服务商必须将其宕机时间、服务变更、新服务展示、版本退化和API修改等信息告知客户。

SOA治理的一条关键性原则是，分布式应用环境应当是与平台无关的，其治理基础设施也应如此。在纯粹的SOA环境中，外部的API应与其底层平台无关。

然而，当企业进入云计算市场时，通常总是会违背这一原则，只去依赖单一的公用云服务商。而后者的大多数服务都有着专利的API、研发工具、虚拟化层和治理特色。尽管有不少云服务也能够与开放的SOA以及Web 2.0的标准有某种程度的吻合。很多专利的公用云之间的互操作性基本上是不存在的，而要跨越这些不同的公用和私用云去治理服务的工具也才刚刚开始出现。

“为了让这些跨云的服务在设计上具有可移植性，公用云服务商应当对其虚拟化服务执行开放的行业标准。”虚拟化工具厂商rPath的创始人兼首席战略官Billy Marshall说。“如果能定义服务遵从开放的虚拟化格式，那我们就能使服务的治理与平台无关。”

解决这一问题的一个规范就是开放虚拟化格式（OVF），这是分布式管理任务组（DMTF）提出的一个标准草案，这一标准为在虚拟机（VM）中运行的软件的包装和分布定义了一种可扩展格式。rPath负责工程设计的副总裁Brett Adam说，这是为VM跨越多个云的可移植性制定的一个关键性的规范，但它到目前为止仍处于1.0版，还不能为VM“镜像”提供支持其复杂生命周期治理所需的全部内容。

VM的繁衍进一步增加了管理的难度

大多数SOA治理其实只停留在企业IT环境的表面：只能管理应用层中某些服务的子集，以及建立在XML、SOAP、WSDL和其他核心SOA规范上的那些Web服务。与之相对照的是，很多公用云服务商却能提供层次较深的按需服务堆栈、扩展的应用、软件平台、集成的中间件，甚至能到达硬件层。事实上，虚拟化的、以网格为基础的“硬件作为服务（HOA）”的资源池也成为了一种颇受欢迎的云服务，可以提供足够的处理能力和存储容量。

由于很多云服务已深入到企业的应用堆栈，因此也已超出了今天的SOA治理工具的治理能力。因此要想依靠传统的SOA治理工具对云计算环境实行统一的规划、设计、配置、监控是不可能的。

云治理和传统的SOA治理的一个关键性的差别就是前者关注VM的生命周期治理。为了让深层应用的自动配置和VM堆栈的集成更方便，云管理环境应能提供预包装的“服务模板”。

这些嵌入了预包装策略定义的模板可控制重要生命周期服务的VM治理功能，包括VM在一个或多个公用和私用云上的部署、设置、启动、监测、控制、优化和扩展。云治理甚至可满足对于旧的VM实例实施“退役和丢弃”的周期性需求，并可以新的VM实例取代它们。

实际上，这样的云对于云治理来说将是一种杀手级应用：可预防VM实例跨越公用和私用虚拟化基础设施的未经验证的繁衍。繁衍问题，有时也称为“VM的蔓延”，代表着维护上的沉重负担和对云CPU、存储和网络资源的过度消耗。

逐渐增多的商用云管理工具可提供跨各种不同的hypervisor控制VM蔓延的能力。除此之外，hypervisor平台厂商，如VMware、Citrix、微软以及公用云服务商都已为其各自的管理工具添加了这一重要的管理功能。这种有时也被称作“实例管理”的管理特色，正是传统的SOA治理工具所缺少的。

SOA最佳实践触碰云层

不过，云服务还是有很多好处是值得企业的SOA治理执行者们学习的。惠普软件与解决方案集团的SOA产品经理Tim Hall认为，“最重要的是，你需要一份服务目录来维护与服务有关的元数据，能够控制服务的开卡和构建过程，并向使用者公开服务的可见性和可用性。”

另外，联邦制的协议也能在公用云和企业的SOA、REST以及其他应用环境之间设定自配置的服务定义。Hall认为，从宏观的角度来看，服务可直接转换成价值，可帮助企业赚钱、省钱或者缓解风险。

很显然，SOA治理正在逐渐成熟，而云计算才刚刚起步。糟糕的是，云计算领域在未来几年内仍会继续迅速地发生变化，所以要想达成一致性的服务治理实践还很困难。

因此，在这一新的、野生状态下的强大的服务治理依然处在云里雾里，只不过一些稀稀拉拉的明亮星光已经透过云层在向我们眨眼了。美国《Network World》特供本报专稿。（更多内容详见：http://www.cnw.com.cn/P/1019）

相关链接：混搭的泥潭

传统的SOA治理工具的研发是自上而下的。它要求有大量的先期架构设计，将各种基础功能分解成平台无关的、还需要与研发人员按照Web服务标准签署松耦合的服务合同。通常情况下，它还会包含一份核心服务目录，例如UDDI，以及支持关键接口标准，如WSDL和SOAP的各种工具和平台。

与之相反，云服务则鼓励草根式的开发风格——通常被称为Web 2.0、面向Web架构或者代表性状态传输（REST）来进行服务的配置、研发与管理。任何人只要有信用卡便可注册并访问云服务，这又带来了各种应用与企业内部的应用重复、冗余的局面。

利用相同的标志，任何人都可借助浏览器把各种可用的云服务组件混搭在各种应用中，这也就会越来越偏离符合企业标准的应用设计规范。而从企业级服务的角度来看，这就有可能导致严格管理的安全措施出现缺失。在REST范式中，UDDI、WSDL、SOAP和其他WS*标准也是有明显缺失的。所以，“混搭式治理”令一些SOA专家颇感忧虑就不足为奇了。（来自互联网）