SOA 应该具备的 -----苏振兴

转载 2006年05月25日 07:51:00

性能是指系统提供的服务要满足一定的性能衡量标准,这些标准可能包括系统反应时间以及处理交易量的能力等;

可升级性是指当系统负荷加大时,能够确保所需的服务质量,而不需要更改整个系统的架构;

可靠性是指确保各应用及其相关的所有交易的完整性和一致性的能力;

可用性是指一个系统应确保一项服务或者资源永远都可以被访问到;

可扩展性是指在不影响现有系统功能的基础上,为系统填加新的功能或修改现有功能的能力;

可维护性是指在不影响系统其他部分的情况下修正现有功能中问题或缺陷,并对整个系统进行维护的能力;

可管理性是指管理系统以确保系统的可升级性、可靠性、可用性、性能和安全性的能力;

安全性是指确保系统安全不会被危及的能力。

1) 性能

我们通常可以根据每个用户访问的系统响应时间来衡量系统的整体性能;另外,我们也可以通过系统能够处理的交易量(每秒)来衡量系统的性能。对于架构设计师来说,无论采取哪种衡量系统性能的方法来构建系统架构,这些对于性能的考虑对系统设计开发人员来说都应该是透明的,也就是说对于系统整体架构性能的考虑应该是架构设计师的工作,而不是系统设计开发人员应该关注的事情。在较传统的基于EJB或者XML-RPC的分布式计算模型中,它们的服务提供都是通过函数调用的方式进行的,一个功能的完成往往需要通过客户端和服务器来回很多次的远程函数调用才能完成。在Intranet的环境下,这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计,但如果我们在基于 SOA 的架构中使用了很多Web Service来作为服务提供点的话,我们就需要考虑性能的影响,尤其是在Internet环境下,这些往往是决定整个系统是否能正常工作的一个关键决定因素。因此在基于 SOA 的系统中,推荐采用大数据量低频率访问模式,也就是以大数据量的方式一次性进行信息交换。这样做可以在一定程度上提高系统的整体性能。

2) 可升级性

可升级性是指当系统负荷加大时,仍能够确保所需的服务质量,而不需要更改整个系统的架构。当基于 SOA 的系统中负荷增大时,如果系统的响应时间仍能够在可接受的限度内,那么我们就可以认为这个系统是具有可升级性的。要想理解可升级性,我们必须首先了解系统容量或系统的承受能力,也就是一个系统在保证正常运行质量的同时,所能够处理的最大进程数量或所能支持的最大用户数量。如果系统运转时已经不能在可接受时间范围内反应,那么这个系统已经到达了它的最大可升级状态。要想升级已达到最大负载能力的系统,你必须增加新的硬件。新添加的硬件可以以垂直或水平的方式加入。垂直升级包括为现在的机器增加处理器、内存或硬盘。水平升级包括在环境中添置新的机器,从而增加系统的整体处理能力。作为一个系统架构设计师所设计出来的架构必须能够处理对硬件的垂直或者水平升级。基于 SOA 的系统架构可以很好地保证整体系统的可升级性,这主要是因为系统中的功能模块已经被抽象成不同的服务,所有的硬件以及底层平台的信息都被屏蔽在服务之下,因此不管是对已有系统的水平升级还是垂直升级,都不会影响到系统整体的架构。

3) 可靠性

可靠性是指确保各应用及其相关的所有交易的完整性和一致性的能力。当系统负荷增加时,你的系统必须能够持续处理需求访问,并确保系统能够象负荷未增加以前一样正确地处理各个进程。可靠性可能会在一定程度上限制系统的可升级性。如果系统负荷增加时,不能维持它的可靠性,那么实际上这个系统也并不具备可升级性。因此,一个真正可升级的系统必须是可靠的系统。在基于 SOA 来构建系统架构的时候,可靠性也是必须要着重考虑的问题。要在基于 SOA 架构的系统中保证一定的系统可靠性,就必须要首先保证分布在系统中的不同服务的可靠性。而不同服务的可靠性一般可以由其部署的应用服务器或Web服务器来保证。只有确保每一个 SOA 系统中的服务都具有较高的可靠性,我们才能保证系统整体的可靠性能够得以保障。

4) 可用性

可用性是指一个系统应确保一项服务或者资源应该总是可被访问到的。可靠性可以增加系统的整体可用性,但即使系统部件出错,有时却并不一定会影响系统的可用性。通过在环境中设置冗余组件和错误恢复机制,虽然一个单独的组件的错误会对系统的可靠性产生不良的影响,但由于系统冗余的存在,使得整个系统服务仍然可用。在基于 SOA 来构建系统架构的时候,对于关键性的服务需要更多地考虑其可用性需求,这可以由两个层次的技术实现来支持,第一种是利用不同服务的具体内部实现内部所基于的框架的容错或者冗余机制来实现对服务可用性的支持;第二种是通过UDDI等动态查找匹配方式来支持系统整体的高可用性。在 SOA 架构设计师构建企业系统架构的时候,应该综合考虑这两个方面的内容,尽量保证所构建的 SOA 系统架构中的关键性业务能具有较高的可用性。

5) 可扩展性

可扩展性是指在不影响现有系统功能的基础上,为系统添加新的功能或修改现有功能的能力。当系统刚配置好的时候,你很难衡量它的可扩展性,直到第一次你必须去扩展系统已有功能的时候,你才能真正去衡量和检测整个系统的可扩展性。任何一个架构设计师在构建系统架构时,为了确保架构设计的可扩展性,都应该考虑下面几个要素:低耦合,界面(interfaces)以及封装。当架构设计师基于 SOA 来构建企业系统架构时,就已经隐含地解决了这几个可扩展性方面的要素。这是因为 SOA 架构中的不同服务之间本身就保持了一种无依赖的低耦合关系;服务本身是通过统一的接口定义(可以是WSDL)语言来描述具体的服务内容,并且很好地封装了底层的具体实现。在这里我们也可以从一个方面看到基于 SOA 来构架企业系统能为我们带来的好处。

6) 可维护性

可维护性是指在不影响系统其他部分的情况下修改现有系统功能中问题或缺陷的能力。同系统的可扩展性相同,当系统刚被部署时,你很难判断一个系统是否已经具备了很好的可维护性。当创建和设计系统架构时,要想提高系统的可维护性,你必须考虑下面几个要素:低耦合、模块性以及系统文档记录。在企业系统可扩展性中我们已经提到了 SOA 架构能为系统中暴露出来的各个子功能模块也就是服务带来低耦合性和很好的模块性。关于系统文档纪录,除了底层子系统的相关文档外,基于 SOA 的系统还会引用到许多系统外部的由第三方提供的服务,因此如果人力资源准许的话,应该增加专职的文档管理员来专门负责有关整个企业系统所涉及的所有外部服务相关文档的收集、归类和整理,这些相关的文档可能涉及到第三方服务的接口(可以是WSDL)、服务的质量和级别、具体性能测试结果等各种相关文档。基于这些文档,就可以为 SOA 架构设计师构建企业 SOA 架构提供很好的文档参考和支持。

7) 可管理性

可管理性是指管理系统以确保整个系统的可升级性、可靠性、可用性、性能和安全性的能力。具有可管理性的系统,应具备对服务质量需求(QoS)的系统监控能力,通过改变系统的配置从而可以动态地改善服务质量,而不用改变整体系统架构。一个好的系统架构必须能够监控整个系统的运行情况并具备动态系统配置管理的功能。在对复杂系统进行系统架构建模时, SOA 架构设计师应该尽量考虑利用将系统整体架构构建在已有的成熟的底层系统框架(Framework)上。对于 SOA 架构设计师来说,可以选择的底层系统框架有很多,可以选用基于MQ, MessageBorker,WebSphere Application Server等产品来构建企业服务总线(Enterprise Service Bus)以支持企业的 SOA 系统架构,也可以选用较新的基于WebSphere Application Server 6中内嵌的Sibus来构建企业的ESB以支持 SOA 系统架构。具体选择哪种底层框架来实施 SOA 系统架构要根据每个系统各自的特点来决定,但这些底层的框架都已经提供了较高的系统可管理性。因此,分析并选择不同的产品或底层框架来实现企业系统架构也是架构设计师的主要职责之一。有关于如何利用已有底层架构来构建 SOA 系统,中国 SOA 设计中心已经发表了一系列相关的文章,大家可以在DeveloperWorks中的 SOA 专栏看到它们。

8) 安全性

安全性是指确保系统安全不会被危及的能力。目前,安全性应该说是最困难的系统质量控制点。这是因为安全性不仅要求确保系统的保密和完整性,而且还要防止影响可用性的服务拒绝(Denial-of-Service)攻击。这就要求当 SOA 架构设计师在构建一个架构时,应该把整体系统架构尽可能地分割成各个子功能模块,在将一些子功能模块暴露为外部用户可见的服务的时候,要围绕各个子模块构建各自的安全区,这样更便于保证整体系统架构的安全。如果一个子模块受到了安全攻击,也可以保证其他模块相对安全。如果企业 SOA 架构中的一些服务是由Web Service实现的,在考虑这些服务安全性的时候也要同时考虑效率的问题,因为WS-Security会为Web Service带来一定的执行效率损耗。

相关文章推荐

SOA架构设计经验分享—架构、职责、数据一致性

阅读目录: 1.背景介绍 2.SOA的架构层次 2.1.应用服务(原子服务) 2.2.组合服务 2.3.业务服务(编排服务) 3.SOA化的重构 3.1.保留服务空间,为了将...

基于SOA的数据同步方案

2.1 SOA及其相关技术     面向服务的体系架构(service—orientedarchitectI埔,SOA)是一种粗粒度、松耦合的服务结构。SOA是服务的集合,服务是最核心的抽象手段,业...

Dblink接口向Oracle Soa Suite迁移,实现数据复制和日志功能

Dblink接口向Oracle Soa Suite迁移,实现数据复制和日志功能

使用 Dojo 工具包和 JSON-RPC 构建企业 SOA Ajax 客户端

了解如何使用 Dojo 工具包为 Java™ Platform Extended Edition (Java EE) 应用程序构建企业 SOA 客户端,以及如何使用 JavaScript Object...

管理支撑办公系统技术架构选型对比讨论(J2EE与SOA对比)

续:管理支撑办公系统技术架构选型及相关技术应用范围、方法分析 通过两个技术方案介绍,汇总技术内容(SOA与JavaEE对比),为了便于选型,没有优劣定义、评价标准,开放性的听取专家建议或更加简洁的方案...
  • xiaoyw
  • xiaoyw
  • 2014年04月22日 13:58
  • 2034

第五代呼叫中心之SOA(六)

这一章我们看看坐席业务软件的故事,这一章,我们只说一个故事。   坐席业务软件一直是呼叫中心中需求最为复杂的一部分软件。坐席业务软件为了方便坐席的管理,经常呼叫中心的各个业务软件的信息集成在一起...
  • newsxy
  • newsxy
  • 2011年09月11日 13:59
  • 409

云架构师=企业级架构师+SOA架构师+云技术专家

云架构师=企业级架构师+SOA架构师+云技术专家 ----不要将云架构师误认为成企业架构师 写在前面:原作者经常被猎头公司委托寻找云架构师,这是该作者写的一篇简单清晰明了的关于云架构师应该具备什么...

[SOA] Mule ESB 3.x 入门(一)—— 消息流

关于Mule ESB,简单来说Mule接受一个消息,按照某种顺序处理这个消息,这样的处理可导致多种结果。有时,Mule改变或变换消息返回到原来的消息来源(request-response)。或者,在其...

微服务SOA架构与RPC远程过程调用

微服务架构 --- SOA架构思想的一种实现 定义: 采用一组服务的方式来构建一个应用,服务独立部署在不同的进程中,不同服务通过一些轻量级交互机制来通...
  • he90227
  • he90227
  • 2015年12月18日 11:25
  • 4548
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:SOA 应该具备的 -----苏振兴
举报原因:
原因补充:

(最多只允许输入30个字)