soa架构的优缺点解析

概述

在企业传统的系统开发中，企业往往在设计架构的时候都是采用了紧耦合形式，这是封闭的，自成一体的。这种架构下的的MRP、ERP、OA等产品很难适应或快速响应市场或客户灵活多变的需求，以及后续的扩展。在这样的市场、及客户需求下，从而催生了软件产品一种新的设计或架构的理念：面向服务架构（SOA架构）。

SOA架构，是一种粗粒度、开放式、松耦合的服务结构，要求软件产品在开发过程中，按照相关的标准或协议，进行分层开发。通过这种分层设计或架构体系可以使软件产品变得更加弹性和灵活，且尽可能的与第三方软件产品互补兼容，以达到快速扩展，满足或响应市场或客户需求的多样化、多变性。

SOA体系架构带来的主要观点是业务驱动IT，即业务驱动和业务更加紧密地联系在一起。以粗粒度的业务服务作为基础来对公司业务进行建模，这样就可以产生简洁的业务和系统视图;以业务服务为基础来实现的IT系统更灵活、更易于重用、也更快地应对企业业务需求的变化;以业务服务为基础，通过显式地方式来定义、描述、实现和管理业务层次的粗粒度服务（包括业务流程），提供了业务服务模型和相关IT业务之间提供了更好的“可追溯性”，缩小了它们之间的差距，使得业务服务的变化更容易传递到IT。

利用SOA架构开发的时候，其基于松耦合的特性能给企业带来诸多的好处：

第一、更易维护

业务服务提供者和业务服务使用者的松散耦合关系及对开放标准的采用确保了该特性的实现。建立在以 SOA基础上的信息系统，当需求发生变化的时候，不需要修改提供业务服务的接口，只需要调整业务服务流程或者修改操作即可，整个应用系统也更容易被维护。

第二、更高的可用性

该特点是在于服务提供者和服务使用者的松散耦合关系上得以发挥与体现。使用者无须了解提供者的具休实现细节。

第三、更好的伸缩性

依靠业务服务设计、开发和部署等所采用的架构模型实现伸缩性。使得服务提供者可以互相彼此独立地进行调整，以满足新的服务需求。

现在，国内许多企业已经使用了SOA架构，但是是否它就真的没有缺点，答案显然不是：

SOA的不足

作为一个具有发展前景的应用系统架构，SOA尚处在不断发展中，肯定存在许多有待改进的地方。随着标准和实施技术的不断完善，这些问题将迎刃而解，SOA应用将更加广泛。

缺憾之一 ： 可靠性（Reliability）

SOA还没有完全为事务的最高可靠性——不可否认性（nonrepudiation）、消息一定会被传送且仅传送一次（once-and-only-once delivery）以及事务撤回（rollback）——做好准备，不过等标准和实施技术成熟到可以满足这一需求的程度并不遥远。

缺憾之二 ： 安全性（Security）

在过去，访问控制只需要登录和验证；而在SOA环境中，由于一个应用软件的组件很容易去与属于不同域的其他组件进行对话，所以确保迥然不同又相互连接的系统之间的安全性就复杂得多了。

缺憾之三：编排 （Orchestration）

统一协调分布式软件组件以便构建有意义的业务流程是最复杂的，但它同时也最适合面向服务类型的集成，原因很显然，建立在SOA上面的应用软件被设计成可以按需要拆散、重新组装的服务。作为目前业务流程管理（BPM）解决方案的核心，编排功能使IT管理人员能够通过已经部署的套装或自己开发的应用软件的功能，把新的元应用软件 （meta-application）连接起来。 事实上，最大的难题不是建立模块化的应用软件，而是改变这些系统表示所处理数据的方法。

缺憾之四：遗留系统处理（Legacy support）

SOA中提供集成遗留系统的适配器， 遗留应用适配器屏蔽了许多专用性API的复杂性和晦涩性。一个设计良好的适配器的作用好比是一个设计良好的SOA服务：它提供了一个抽象层，把应用基础设施的其余部分与各种棘手问题隔离开来。一些厂商就专门把遗留应用软件“语义集成”到基于XML的集成构架中。 但是集成遗留系统的工作始终是一种挑战。

缺憾之五 ： 语义 Semantics

定义事务和数据的业务含义，一直是IT管理人员面临的最棘手的问题。语义关系是设计良好SOA架构的核心要素。 就目前而言，没有哪一项技术或软件产品能够真正解决语义问题。为针对特定行业和功能的流程定义并实施功能和数据模型是一项繁重的任务，它最终必须由业务和IT管理人员共同承担。不过，预制组件和经过实践证明的咨询技能可以简化许多难题。

采用XML技术也许是一个不错的主意。许多公司越来越认识到制定本行业XML标准的重要性。譬如，会计行业已提议用可扩展业务报告语言（XBRL）来描述及审查总账类型的记录。 重要的是学会如何以服务来表示基本的业务流程。改变开发方式需要文化变迁，相比之下，解决技术难题只是一种智力操练。

性能（performance）：SOA的第六个缺憾？

批评SOA的人士经常会提到性能是阻碍其采用的一个障碍，但技术的标准化总需要在速度方面有一些牺牲。这种怀疑观点通常针对两个方面：SOA的分布性质和Web服务协议的开销。

不可否认，任何分布式系统的执行速度都不如独立式系统，这完全是因为网络的制约作用造成的。当然，有些应用软件无法容忍网络引起的延迟，例如那些对实时性要求很高的应用软件。所以在应用SOA架构之前，搞清楚它的适用范围就显得很重要了。

除了上述几点之外，笔者认为还有两点也颇值得关注：

松耦合和敏捷性要求之间的权衡难题：

服务松耦合设计其实是一把双刃剑，在带来应变敏捷性的同时，也给业务建模和服务划分带来难题。这就是为什么在SOA讨论中，业务建模的争论总是最多的原因。

跨系统集成难题：

面向服务的体系结构设计将跨越计算机系统，并且还可能跨越企业边界。我们不得不考虑在使用 Internet 时安全性功能和需求，以及如何链接伙伴的安全域。Internet 协议并不是为可靠性（有保证的提交和提交的顺序）而设计的，但是我们需要确保消息被提交并被处理一次。当这不可能时，请求者必须知道请求并没有被处理。

其次，个性化问题。SOA通过所谓粗粒度服务接口和分级，确实提高了效率。实现流程化以后，也确实简化了开发难度。如果这个流程不适合我这个企业的实际情况，我还是需要个性化开发。国内的中小企业占到了企业总量的70%，他们的需求很具个性化，而且比较在意价格的因素。实际上这和SOA高度集成的性质是不相符的。