在过去的几年里,ZapThink参与并观察了不少面向服务架构( SOA )的部署和推出。虽然有些部署更多的是Web服务集成化而非真正以服务为导向,而有些则更为成功以服务为导向。简单的重复该架构并将服务投入生产对大多数公司来说是一个进步。这些公司很快意识到创建服务,并部署基础设施运行这些服务实际上很简单。
成功的让用户以可靠的方式使用这些服务同时支持连续变化是很困难的。 ZapThink写了许多关于通过把适当的管控,质量和管理,服务融入生产方面的挑战,但在zapflash,我们希望能专注于更基本的问题:即服务性能。与”安全”和”质量”一样 ,性能……
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
在过去的几年里,ZapThink参与并观察了不少面向服务架构( SOA )的部署和推出。虽然有些部署更多的是Web服务集成化而非真正以服务为导向,而有些则更为成功以服务为导向。简单的重复该架构并将服务投入生产对大多数公司来说是一个进步。这些公司很快意识到创建服务,并部署基础设施运行这些服务实际上很简单。成功的让用户以可靠的方式使用这些服务同时支持连续变化是很困难的。
ZapThink写了许多关于通过把适当的管控,质量和管理,服务融入生产方面的挑战,但在zapflash,我们希望能专注于更基本的问题:即服务性能。与"安全"和"质量"一样 ,性能的是抽象的。对于不同的人它可以指许多不同的东西。这就是麻烦开始。
对于操作和连网的个人来说,性能可以保障正常运行时间并管理资源综合利用,同时保持服务安全、运行无故障。对于商业分析师和项目经理来说,服务性能指整个,过程都是按照规范运行。对于开发商来说,服务性能,要确保功能上的要求得到了满足。对于商业来说,服务性能要满足关键操作和灵活性指标。这就恰当的定义了服务性能,我们要从以下几个方面来看这个概念。
操作性能
在想到服务性能时,最先映入眼帘的就是服务操作方面。服务操作性能就是指一个服务、任何服务在IT环境表现如何。操作行为包括一个服务的正常运行时间和可行性以及众多服务实施中的资源利用和负荷分配。在这方面,我们可以用传统的系统管理方法监视,测量,管理和服务的操作性能。
正如我们对SOA管理这个题目多次讨论的一样,服务对要求响应的可行性和控制服务行为的元数据都会影响服务运行时间。另外,在网络中,可能有许多服务的分散型实施,因此管理服务性能更像是管理一个服务“栅格”而非单个、分离的服务。
除了这种分布式的,松耦合的复杂性之外,我们还需考虑到一个SOA环境的安全性将更为复杂、分散。这意味着网络管理员要把政策管理看作是服务性能一个方面。
高操作性能的服务不能引起更多的等待时间、使用负和安全漏洞,但是,想一想在不断变化的环境中使用服务这就需要网络管理员和操作型重新考虑服务水平协议和服务质量的定义。
在这种情况下,SLA和QoS中的"服务"指在SOA环境中的一个服务而不是广泛应用于其它服务的服务水平协议。我们现在看的是在SOA环境中应用于服务的服务水平协议。这或许可以称作是一个SOA级别协议?
另外,除了广义上的服务质量以外,我们还可以想一想操作环境下的SOA质量。在过去的十年里,我们一直在讨论SOA,但从SOA角度来讲,我们还没能完全定义这些术语,从操作角度来说,试图理解和优化服务性能对于多数IT机构来说都是一个挑战。
功能性能
知道一个服务是否响应要求或者超载基础设施资源不足以了解一个服务是否在运行。从开发商和关注实施的架构角度来说,如果一个服务能够提供客户期望的结果,该服务就在执行。
这就意味着在用我们先前在ZapFlashes讨论的方式应用SOA Quality。
但是,尽管测试并确认服务与不断变化的业务要求相悖,并且元数据控制的环境不足以保障一个服务的功能性能。强功能操作服务满足灵活性的元要求意味着我们可以不需要新的开发就可以为现有的服务找到新的用途。结构设计师需要测量并管理每个服务的灵活性模型以确保其能提供更强的功能操作性。同时要记住,服务更多的是由元数据而不是其实施而定义的。
过程性能
但是,SOA的能力不是来源于分散的、原子服务,而是来自那些能够完成业务流程要求的服务组合。鉴于此,操作和功能性能只有当业务流程这个整体在企业执行时才真正的重要。所以,我们是如何看待SOA过程性能的呢?
一个过程的特点是高性能,不仅在于它能够在业务和功能上能满足过程要求(正如我们上面所定义的) ,但也如进程本身可以展示其高性能的特点。这意味着,设计师和业务分析员应该能够优化以服务为导向的业务流程,并选择从不同的过程定义中,寻找一个最能满足业务需求的过程定义。一个高效的执行过程中的SOA拥有业务流程,建筑师可以很容易重新配置、组合以及通过特定过程中性能指标测量业务流程。
明显的是,令一个SOA进程比其他更高效的原因不只是因为其包含服务,而是因为架构能够通过准许进程伴随不断变化的业务需求演进来定义并管理一个进程。这就意味着架构应建立一个进程水平协议(PLA),该进程水平协议能够加强并与在上面操作和功能环境中定义的SLAs相分离。PLA的一个例子可能是用户能够动态的在一定时间内特殊的情况下重新部署一个进程。其它的PLAY也能用于在进程中的参与以及长期运行的、不同步的进程。
业务性能
从业务角度来说,性能唯一重要的方面就是一个IT生态系统是否能满足目前的业务需求。在这个性能微粒性的级别里,高效的执行业务中的SOA可以满足三个业务"TLAs"(三个字母的缩写)主要性能指标(KPIs),主要灵活性指标(KAIs),和投资回报(ROI).
我们已经写了许多和KPIs有关的内容,使其对于SOA问题来说更为具体,我们明白业务并不关心架构,他们关心他们的核心需求是否得到满足。这可能包括每小时或每个支持处理的的用户支持呼叫的数量,以及每个用户每月获得的收入和制造、分配的产品的时间。每一个都是可测的KPIs,设计师能够轻松的在SOA内部检测到该KPIs。从这方面看,一个高效的执行业务的SOA不仅能满足当前的KPIs,也能使业务创建新的KPIs,并不用额外的开销和等待时间来测量这些KPIs。
KAIs的概念更新,更多的涉及到业务变化的质量方面。KAIs的一个例子可能是
一家公司推出新产品的速度,或速度上的人力资源部提供新的员工的速度,或者增加新的商业合作伙伴来供应链接所需的大量时间和费用。一个高效执行业务中的SOA必须符合KAIs,可以推测的是,一个定向服务的业务通常应该更容易满足KAIs.
当然,对于一个c级别的执行程序来说,业务底线是测量该程序的重要标准。ROI尺度能衡量投资回报,一个高效的执行业务中的SOA一定能够展示一个积极的ROI,同时也能测量机构其它活动的ROI. 这样,我们可以说,一个高效执行业务的SOA是有利可图的,并保证其余的业务是有利可图的。
ZapThink的收入额
经常被人引用的“现代管理学之父”Peter F. Drucker博士曾经说过,“人们无法管理不能测量的东西”这句话对SOA性能也同样适用,因为他和业务的其它方面息息相关。SOA性能独特的地方是,就像SOA的其他领域,服务性能将我们以前认为是单独概念的IT各方面汇集到一起。服务性能也松散耦合在一起,一个性能标准应该不会对其它任何一个标准和复合标准产生影响,因为我们可以结合服务性能的不同方面实现整个系统的整体行为。
照这样,企业设计师需要全方位的了解ZapFlash中定义的服务性能。从这个角度来说,高性能SOA等待时间短、可行性强、功能相关、可持续配置,和业务相关并且能够从中获利。如果你能把服务性能所有方面集中到一起,并使他们工作,你就可以使你的SOA更有价值更成功。
相关推荐
-
SAP收购CallidusCloud 与Salesforce竞争
一直被称为后台办公巨头的SAP现在似乎也想在前台办公大展拳脚。 最新的迹象是SAP收购CallidusClou […]
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响
-
仅凭SOA和云无法解决业务数据管理风险问题
SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。