架构设计师与SOA(二)

2019-11-17 04:54:50

字体：大中小

来源：转载

供稿：网友

本文将延续第一部分的内容，向您介绍了 SOA 为企业级架构设计带来的影响，以及在构建基于 SOA 架构的企业系统时应该怎样保证所构建的系统架构能够满足系统中不同的服务级别需求。 1. SOA 为企业级架构设计带来的影响1.1 SOA 的特点及其使用范围SOA 既不是一种语言，也不是一种具体的技术，它是一种新的软件系统架构模型。 SOA 最主要的应用场合在于解决在Internet环境下的不同商业应用之间的业务集成问题。Internet环境区别于Intranet环境的几个特点主要是:(a)大量异构系统并存，不同计算机硬件工作方式不同，操作系统不同、编程语言也不同;(b)大量、频繁的数据传输的速度仍然相对较缓慢并且不稳定;(c)无法完成服务(service)的版本升级，甚至根本就无法知道互联网上有哪些机器直接或者间接的使用某个服务。SOA 架构具有一些典型特性，主要包括松耦合性，位置透明性以及协议无关性。松耦合性要求 SOA 架构中的不同服务之间应该保持一种松耦合的关系，也就是应该保持一种相对独立无依靠的关系;位置透明性要求 SOA 系统中的所有服务对于他们的调用者来说都是位置透明的，也就是说每个服务的调用者只需要知道他们调用的是哪一个服务，但并不需要知道所调用服务的物理位置在哪里;而协议无关性要求每一个服务都可以通过不同的协议来调用。通过这些 SOA 架构所具有的特性我们可以看到，SOA 架构的出现为企业系统架构提供了更加灵活的构建方式，假如企业架构设计师基于 SOA 来构建系统架构，就可以从底层架构的级别来保证整个系统的松耦合性以及灵活性，这都为未来企业业务逻辑的扩展打好了基础。1.2 SOA 架构的分层模型接下来简要介绍一下 SOA 系统中的分层模型，整个 SOA 架构的分层模型如图2所示。架构设计师与SOA(二)（图一）

在 SOA 系统中不同的功能模块可以被分为7层:第一层就是系统已经存在的程序资源，例如ERP或者CRM系统等。第2层就是组件层，在这一层中我们用不同的组件把底层系统的功能封装起来。第3层就是 SOA 系统中最重要的服务层，在这层中我们要用底层功能组件来构建我们所需要的不同功能的服务。总的来说，SOA 中的服务可以被映射成具体系统中的任何功能模块，但是从功能性方面可以大致划分为以下三种类型:(1)商业服务(business service) 或者是商业过程(business PRocess)。这一类的服务是一个企业可以暴露给外部用户或者合作伙伴使用的服务。比如说提交贷款申请，用户信用检查，贷款信用查询。(2)商业功能服务(business function service)，这类服务会完成一些具体的商业操作，也会被更上层的商业服务调用，不过大多数情况下这类服务不会暴露给外部用户直接调用，比如说检索用户帐户信息，存储用户信息等。(3)技术功能服务(technical function service)，这类服务主要完成一些底层的技术功能，比如说日志服务以及安全服务等。在服务层之上的第4层就是商业流程层，在这一层中我们利用已经封装好的各种服务来构建商业系统中的商业流程。在商业流程层之上的就是第5层表示层了，我们利用表示层来向用户提供用户接口服务，这一层可以用基于portal的系统来构建。以上这5层都需要有一个集成的环境来支持它们的运行，第6层中的企业服务总线(ESB)提供了这个功能。第7层主要为整个 SOA 系统提供一些辅助的功能，例如服务质量治理，安全治理这一类的辅助功能。2. SOA 架构中的非功能性服务级别(service-level)需求除了系统的业务需求，架构设计师还必须要保证构建出来的系统架构能够满足系统中的非功能性服务级别(service-level)需求以及服务质量(QoS)方面的需求。在项目初始及细化阶段，架构设计师应该与系统所有涉及方(Stakeholders)一起，为每一个服务级别需求定义其相关的衡量标准。构建出的系统架构必须要能满足以下几方面的服务水准要求:性能、可升级性、可靠性、可用性、可扩展性、可维护性、易治理性以及安全性。架构设计师在设计架构过程中需要平衡所有的这些服务级别需求。例如，假如服务级别需求中最重要的是系统性能，架构设计师很有可能不得不在一定程度上牺牲系统的可维护性及可扩展性，以确保满足系统性能上的要求。随着互联网的发展，新构建的系统对于服务级别需求也变得日益重要，现在基于互联网的企业系统的用户已经不仅仅局限于是本企业的雇员，企业的外部客户也会成为企业系统的主要用户。架构设计师的职责之一就是要尽可能地为提高系统设计人员和系统开发人员的工作效率考虑。在构建整个企业系统架构的过程中，需要充分重视各种服务级别需求，从而避免在系统开发和运行的时候出现重大问题。一个企业级系统中的服务级别需求往往是十分错综复杂的， SOA 架构设计师需要凭借丰富的专业经验和扎实的理论知识来分离和抽象系统中不同的服务级别需求，图3展示了这种分析的过程。架构设计师与SOA(二)（图二）

图3经过 SOA 架构设计师分析和抽象的服务级别需求主要分为以下几类:
性能是指系统提供的服务要满足一定的性能衡量标准，这些标准可能包括系统反应时间以及处理交易量的能力等;可升级性是指当系统负荷加大时，能够确保所需的服务质量，而不需要更改整个系统的架构;可靠性是指确保各应用及其相关的所有交易的完整性和一致性的能力;可用性是指一个系统应确保一项服务或者资源永远都可以被访问到;可扩展性是指在不影响现有系统功能的基础上，为系统填加新的功能或修改现有功能的能力;可维护性是指在不影响系统其他部分的情况下修正现有功能中问题或缺陷，并对整个系统进行维护的能力;可治理性是指治理系统以确保系统的可升级性、可靠性、可用性、性能和安全性的能力;安全性是指确保系统安全不会被危及的能力。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带来一定的执行效率损耗。3.结束语本系列两部分介绍了有关架构设计师以及 SOA 架构的知识，分析了 SOA 架构师在设计 SOA 系统架构时有哪些应该非凡注重的地方并在最后简要介绍了在构建基于 SOA 架构的企业系统时应该怎样保证所构建的系统架构能够满足系统中不同的服务级别需求。从架构设计师的角度， SOA 是一种新的设计模式，方法学。因此， SOA 本身涵盖了很多的内容，也触及到了系统整体架构设计、实现、维护等各个方面。本文的内容只是涉及到了有关于架构方面的一部分内容，希望能对广大的 SOA 系统开发设计人员起到一定的帮助作用。

上一篇：架构设计师与SOA(一)

下一篇：SOA的构建原则