别让SOA踏上不归死亡之路-爱ERP网

别让SOA踏上不归死亡之路

作者：佚名文章来源：本站原创点击数：更新时间：2008-7-8

上一篇文章：何时采用SOA 何时不采用SOA…

建立在面向服务架构(SOA)上的Web应用程序将极大的提高IT效率和业务灵敏度。SOA 建立起了数据和协议方面的统一标准，以使得现有的内部和第三方应用程序模块或服务能够有效的重复利用，并可以进一步重新组合进业务应用程序。但不幸的是，在SOA迅速促进业务应用程序实施的同时，这些应用于生产的程序也大大增加了其性能管理的复杂性――这在很大程度上降低SOA应用所能实现的优势。如果没有有效的方法来监控应用程序的性能、迅速找出症结所在并加以解决，那么SOA应用就很有可能成为死亡之路(dead on arrival ，DOA)。

　　在实施SOA有几个方面的原因导致IT很难管理应用程序的性能：

　　造成低效的共同要素：一个SOA应用程序所提供的服务，其水平受到网络中该SOA应用程序所需性能的服务水平限制。为了达到最大限度的灵活性，服务甚至可以由第三方供应商提供，并有可能在不同的计算平台上运行。这使得IT从实际操作上不可能界定出服务构件的性能特点，更不可能完全控制那些影响程序交付和执行的众多机动部分。服务的重新利用还意味着通用服务中所存在的性能缺陷也在程序应用中被复制过来，产生了无法预计的故障。这样以来，就很难从数量上确定服务水平是否超过终端客户的期望或至少达到服务水平协议(SLA)中规定的性能目标。

　　联动实验效果：对于一个通过Web发布的SOA应用程序来说，要确认其服务的发起和交付时存在哪些问题同样是非常困难的。问题根源可能存在于交付机制中任何一个“机动部分”，比如客户的个人电脑、网络、数据中心、服务组件和/或第三方服务提供商的服务或基础架构。在这样一个复杂的环境中，没有一张“嫌疑列表”足够巨细无遗列出所有的可能性。

　　繁杂的网络环境：在处理这些通过Web发布的应用程序或基础架构时缺少一种可预见性或事先确定的步骤去实现操作，也进一步使得诊断SOA应用性能问题的任务变得更加复杂。在客户端或服务器端的计算环境中，一个目录查询是经由定义的网络分段，并由安装在固定服务器上的ERP应用程序加以支持;而在SOA环境中的目录查询可能经由网络动态的进行，.并且由多个虚拟或实际服务器所在基础架构的多层逻辑中加以支持。第三方Web服务需求也能传输给提供商的基础架构从而从提供商自身开始说明详细目录。这种复杂的组合需要涉及非确定性的操作路径，这使得改造或诊断整体应用性能的问题变得十分困难。

　　为了应对如上的这些挑战，使得SOA应用不至走上死亡之路(DOA)，IT需要两种能力为其所用。首先，IT必须能够像真正的用户那样监控应用程序的性能，因为这是唯一能感受到所有服务组件的环节要素所在。除此以外，如果发现服务水平受到影响，他们必须能够迅速的追踪不利操作，查明引起性能下降的问题根源所在。如果能系统的利用这些能力，IT就能够：

　　· 通过发现性能瓶颈与缩短问题解决时间来提高服务水平。

　　· 排除不必要的评估会议和毫无成果的改造尝试，降低操作管理的成本和失误几率。

　　那么现存的终端用户在实现其应用程序满足IT需求的同时应该如何监控其技术交付从而避免应用程序走上死亡之路(DOA)呢?让我们看看对于监控技术在应用于SOA性能管理的调查情况：

　　· 嗅探器或是其他的包捕获程序即可很容易的评估出在传输规则下包响应的来回时间，但是对于那些传输路径并未通过在网络中安装了这些程序的关键点的交易则无法判断出准确的响应时间。拿Mashups应用做一个例子：关键的数据项目由第三方应用程序提供，旁路的嗅探器会安装在网络服务器前端。在数据中心，基于SOA应用的基础上嗅探器依旧会遗漏掉Web服务而是更多的监测到来自服务器端或是第三方的服务。

　　· 服务器监测工具只能针对其所监测的局限范围做出事务处理时间响应的报告。举例而言，流行的J2EE应用程序服务器端监测工作只能对安装了这个应用程序服务器的范围内做出事务处理响应时间的判断。直接由Web或是第三方服务所提供的事务处理服务没有涉及到应用程序层面则无法被J2EE监测工具直接管理。.

　　· 传统的网站性能监测服务可以准确的监测到SOA应用程序是否可行。但是它并不能就性能做出一个有经验可参考的报告提供给真正的使用者，或是给出一份针对问题的精细记录信息从而完成纠正性的完善。

　　· 纯粹的SOA管理产品可以帮助IT部门从相互依赖的各种服务中建立起有效模型，从而提供有限的事务处理方式的信息，但是这样的产品往往会忽视整体基础架构的良性发展。最关键的是它无法对最终的性能表现做出预判并给予最终用户以经验指导。

　　在提供“真实”可行的信息以管理SOA的性能方面，这些遗产工具不仅在所收集的性能数据类型上不够完善，在收集数据的来源方面也存在缺陷。至关重要的是要界定应用程序性能在被终端用户感应到的反应时间，而不是服务器、网络J2EE、数据库或其他局限范围内的度量。毫无疑问的是，终端用户体验是唯一重要的事情。此外，在mashup应用程序中，网页是由多个服务器或第三方数据中心来支持的，当应用程序通过内容传输工具执行的时候，程序在内容都已经到达浏览器的时候也许都还没有组合起来。结果，唯一衡量SOA应用性能好