[注：本文由作者原创，已经发表于《程序员》杂志2011-12月刊，版权归《程序员》所有，经过版权方许可后，在此分享给更多的互联网读者]

引子

    我相信今天已经没有人对SOA的概念感到陌生，或者说没有听到过这个名字。但是，你眼中的SOA是什么？1000个人可能会有1000种理解。我认为造成这种理解上的差异性的原因有两点：其一，给SOA下定义的组织机构太多，没有统一的定义。若干标准化组织，大厂商等都给出了自己对SOA的理解，但是这些理解却并不统一。其二，人们对SOA的理解曾一度被解决方案厂商所误导。或者由于短视，或者迫于抢占市场的压力，SOA解决方案供应商们关心的是打着SOA的旗号卖产品。但凡能沾点边的，都贴上了SOA的标签。

    然而，值得庆幸的是，不论人们是否深入理解SOA，但却似乎都接受了它，也能大致说出它的几大特点和优势——应用程序服务化、松耦合、灵活的架构、支持敏捷，等等。

    SOA是什么？如何实施SOA？解决这一类问题的文章在出版物和网络上可以搜索到一堆，笔者在此就不再重复这些工作了。本文的重点是介绍SOA在当今中国企业中的发展现状。同时，为了全文结构的完整性，先对SOA做一个简单介绍。

SOA简述

    SOA的全称是Service Oriented Architecture，即面向服务的架构。从其名字上看，它有两个核心：一是服务，二是架构。所以：

  • 它以服务为核心。传统的整合架构都是以应用为核心，而SOA里谈的一切都是从服务展开的。

  • 它不是某种特定技术，而是一种架构风格，架构思想或一组指导架构设计原则。在特定风格、思想、原则的指导下设计出来的企业应用架构就是具有SOA的特性和优势的架构。

    SOA的目标是实现IT和业务对齐（如图1所示）。这一目标可作为衡量SOA实施成败与否的重要尺度之一。众所周知，业务是不断发展、变化的，业务创新越来越成为企业核心竞争力的一部分。传统IT支撑业务发展的方式是为新业务构建新的业务系统，设计新的数据库，系统或是“竖井状”的孤岛形式，系统间的连接常见的是点对点的缺乏规划的连接方式。久而久之，这样的方式已经无法满足业务发展对IT带来的要求，IT成为企业的严重短板。SOA出现的主要目的就是彻底改变这种局面，使IT变得灵活，与业务对齐，不再成为企业的后腿。甚至能够促进业务的发展，并创造新的业务价值。

SOA的目标-业务与IT对齐

图1. SOA的目标：IT与业务对齐

 

    为什么SOA能够实现IT和业务对齐呢？这得归功于SOA架构中的若干实施原则：

  • 应用功能的服务化

将应用程序打散成服务是SOA实施的关键之一。一方面，遗留系统的功能和数据不能丢弃，只有重用才能利用其价值。另一方面，将应用作为整体是从技术和实施上都非常难于复用的。所以，SOA的实施原则要求将应用中的功能模块抽象成开放、标准、粒度适中的服务，进而促进现有功能重用、避免重复投资、加速新业务开发的速度。

  • 架构的松耦合原则

SOA的另一重要原则是松耦合，松耦合不仅表现在服务本身，还表现在架构层面。服务的松耦合表现在服务的描述与其底层实现技术是分离的，换言之，一个服务，其底层实现可能是Java，也可能是.NET；架构的松耦合表现在服务消费者与服务提供者的分离，在服务消费者及提供者之间置入仲裁（Mediation）模块。这样，服务提供者对服务的修改对服务消费者产生的影响可降至最低。

  • 面向服务的整合

面向服务的整合是SOA的核心之一，主要由企业服务总线（ESB）提供这一部分的能力。服务消费者之间既有面向服务的调用，也有面向消息的处理。企业服务总线提供的协议转换、数据格式转化、多种消息处理机制、审计、日志等功能能够最大限度地提高SOA架构的灵活性和扩展性。

  • 服务的组合及编排

服务梳理出来之后，基于服务的组合和编排就成为可能。服务的组合和编排能够最大限度地重用现有功能，支持业务的创新。偏重于技术层面的服务/消息组合可由ESB提供，而偏业务层面的服务组合和编排可通过BPM组件实现。

    当然，SOA实施原则还有许多，如服务治理、安全访问，信息服务，门户服务的实施原则，本文不再赘述。

    然而，SOA并非完美，它不能解决所有的问题。其一，它通过抽象、封装和松耦合来换取架构的灵活性，其代价就是性能损耗，即单次服务请求时性能的损耗。基于此，我们可以想到许多不适合于使用SOA的场合，比如时效性极高的实时控制系统。其二，正确实施SOA要求从企业范围内对其业务进行整体的分析及梳理，这项工作对SOA实施主体IT来说是一项极为困难的任务，若得不到企业高层和业务的大力支持，实施效果可能会与SOA的价值呈现相去甚远。其三，SOA的投资收益见效慢（渐进式实施SOA会好很多，但是SOA产品供应商很少这么推）。对于许多IT主管而言，实施SOA是“前人植树，后人乘凉”的事情，因此IT主管们对它喜忧参半。

中国式SOA在企业中的发展现状

    前几年，硝烟弥漫、战火纷飞，各路厂商奋力拼杀在SOA的市场上。大厂商拼的是在市场上的统治地位，小厂商若能分得一杯羹也满意了。喧嚣之后总要归于沉静。转眼间，云计算铺天盖地的席卷而来，绚丽的云彩抓住了大众的眼球。SOA像是退居幕后的明星、落幕的英雄，很少再被人提起，甚至有人宣布“SOA已死”。那么，SOA真的销声匿迹了么？中国式SOA的当前状态是怎样的呢？

表面上呼声渐弱，实际上如火如荼

    国内的SOA发展基本遵循Gartner的技术成熟度曲线模型。以下是笔者根据自己的经历做出如下粗略划分：

SOA在中国企业的成熟度曲线图

图2.  国内SOA技术成熟度模型

    技术萌芽期（2006年之前）：在这一阶段中，SOA思想已经被少数国人接受，一些研究单位开始研究它，这个词语也已经出现在一些研究生论文当中。而在同时期，在一些国际巨头和国内少数技术领先的企业里，SOA已经是非常热门的词汇。可是，即便人们听说过这个词，但大多数人还停留在“只缘生在此山中，不识庐山真面目”的阶段。

    概念过热期（2006-2008）：在这一时期，SOA的概念在中国得到迅速扩张。这与IBM，BEA等公司的大力宣传是分不开的。虽然他们的最终目的是销售其中间件、数据库、流程引擎、企业服务总线等产品，但是其宣传在市场上产生的积极作用却是不可忽视的。在此阶段，市场上出现了许多第一批尝螃蟹的企业，也涌现出了许多SOA创新中心，SOA解决方案架构师、SOA分析设计师。这批SOA技术专家多数拥有多年的企业应用整合相关的经历，他们对SOA的认同奠定了SOA在幻灭期之后走向复兴的基础。 

    幻灭期（2009年前后）：在06-08年期间，有一些第一批尝螃蟹的企业中并没有从SOA中获益。他们也许买了一大堆昂贵的中间件产品，却没有很好地使用起来。这里面的原因一方面是实施者对SOA的理解不够深入，另一方面这些产品本身的成熟度也存在问题。投入多却收效微导致人们对SOA心生怀疑，也使得人们从“过热”的情绪中冷静下来，恍然透悟，原来SOA不是银弹，不能解决所有问题，它有适用的场景，也有不适用的场景。 

    复苏期及平稳增长期（从2010年之后）。经过了幻灭期的思考，人们意识到SOA作为一种架构风格的益处，认识到松耦合、服务化在企业级应用整合中的价值，加上过热期一些正确实施SOA的企业此时已经看到它的成效。所以，伴随着人们对SOA的正确理解，SOA真正走上了蓬勃发展的道路。

    当前市场宣传中再也听不到，也看不到SOA了，这是事实。从表面上看，SOA似乎已经销声匿迹，殊不知，实际上SOA却走到了应用最为广泛的时期。经过几年的历练，SOA在国内不论从理论和实践上，还是从产品上都得到了长足的发展。首先，中国培养了一大批掌握SOA实施精髓的系统集成商（SI）和独立软件提供商（ISV），如华为、东软、用友、金蝶、中软……，数不胜数。他们或将SOA的理念植入到其解决方案中，或将SOA理念融合进其产品之中。其次，SOA架构师、整合架构师的队伍也不断壮大，他们成了SOA的最忠实粉丝和最坚实的拥戴者。此外，中国也拥有了自主研发的SOA中间件产品，如普元、炎黄盈动的流程引擎；锐易特、东方通、金蝶的ESB都是市场上的佼佼者。伴随着国人对SOA的理解越来越深入，越来越成熟和专业的SOA产品及解决方案将会随之而来。

    SOA已经深入人心。现在，几乎所有待建的系统和平台都要求基于SOA架构。SOA已经成为基本的架构原则，不论是系统间的整合，还是平台的建设，人们会不约而同地采用SOA原则来架构灵活、易于扩展的系统。 

中国式SOA实施的几个不足

    尽管SOA已经深入人心，但是并非所有的人都能将SOA原则使用得很好。若不能很好的运用SOA，就无法收获相应的价值。下面笔者给出几处常见的不足之处，笔者无法在这篇文章中展开讨论这些问题，但还是期待从业人员正视这些不足之处，找到正确的实施方法。 

1.对SOA的理解参差不齐。

若不能充分理解SOA，未能理解SOA的目标和架构原则，就无法正确实施SOA。在一些项目实施过程中，旧系统被直接推翻，而不是先将遗留系统服务化，然后再循序渐进式的改进。若所有旧系统全部推翻后重建，势必会耗费大量时间和人物力才能完成，不符合SOA多次少量投入的特点。此外，许多人理解的服务就是Web Service规范的服务。而事实上，SOA不限定采用何种技术，只要是开放的、标准的技术即可，比如JMS，RESTful Service等。

2.忽略服务梳理和服务描述的重要性。

笔者清楚地记得一个项目，用户通过这样的方式生产Web服务：将系统里的某个通用Java接口中的所有方法全部暴露出来，使用某个WSDL自动生产工具生成一个超级大的WSDL文件以及许多关联的数据描述（XSD）文件。WSDL中暴露了大量原有程序中的Java包结构和数据结构信息。这个例子是一个糟糕的实践。

哪些功能应该封装成服务，服务该如何描述，这些工作是需要规划的。我们需要根据业务、现有系统等方面，全方位（或局部）梳理业务，才能找到那些适合于暴露成服务的功能。确定好应该暴露的服务之后，进一步确定服务规约，描述其输入和输出、与其他系统的依赖关系、服务非功能性需求等等。

3.重视工作流（Workflow），忽视服务自动编排（Service Choreography）

笔者见到的大多数BPM项目都是关于工作流的，工作流是以审批为主的业务流程，在中国尤为突出。这种流程在某种程度上比此前从一个办公室走到另一办公室、然后再到下一个办公室的场景已经先进许多了。但是，除了工作流之外，BPM还有其他形式，比如服务自动编排，这样的场景却在很大程度上被忽视了。

4.服务治理未得到充分重视。

服务治理或管理对于长期SOA实施的成败至关重要。随着SOA的持续发展，企业中的服务会越来越多、服务的变更、服务位置的变化、服务的版本升级相关工作越来越频繁，如何让这些变化造成的影响控制到最小？再者，当服务多了之后，如何快速便捷地找到所需的服务也是极为重要的工作。所以，服务管理和治理越发显得重要。

企业级应用，SOA还是ROA？

    随着Web2.0和云计算的兴起，REST应用再次变得火热起来。与REST的相关的词汇也出现了好几个，RESTful Service和ROA （Resources Oriented Architecture）就是典型的代表。甚至有许多人认为ROA会替代SOA。事实上是这样的么？

    认为ROA胜过SOA的人一般指的是RESTful Service胜过SOAP，这种观点产生的原因是RESTful Service简单、扩展性高、高性能（缓存机制）；而大多数SOAP缺省基于RPC方式（注：SOAP并不限制一定使用RPC）， 这种机制需要在客户端建立一个代理才模拟服务短的接口，进而调用服务端的服务。相对而言，SOAP的客户端和服务端的耦合要紧密一些，这限制了分布式应用的扩展。另外，RESTFul Service推荐的消息传输格式是JSON，它比SOAP要求的数据格式SOAP信封要简单许多，这也是RESTful Service胜出的另一方面。

    笔者认为，要回答这个问题，首先需要看看企业级应用的特点以及两种架构风格的适用性。

    由于遗留原因，目前企业内的大多数应用并非基于Web，应用系统间的交互大多基于RPC方式，ROA很难在这种环境下开枝散叶。此外，企业应用间互相访问的功能多数是基于过程而非基于资源交互，例如“核准保单”，虽然可以通过REST实现这种场景，但毕竟没有RPC使用起来那么直观。可喜的是，近年来Web应用越来越多地在企业内使用，这为ROA提供了有利的土壤，使得ROA在企业架构中的应用变得多起来。

    从两种架构风格的适用性角度看，一方面，SOA适合于企业级应用自不必说，这么多年来SOA一直在企业范围内应用。另一方面，到目前为止，ROA则更多地应用于基于Web的前端应用的数据聚合，所以ROA在企业内的适用性要窄一些。

    基于以上考虑，笔者认为，ROA可适用于企业内的Web应用之间的整合和协作。ROA通过RESTful Service的形式暴露服务，这些服务可通过SOA架构进一步与企业的其他非Web应用进行整合；SOA则是更高层次的企业级架构风格，RESTful Service可作为描述服务的开放、标准的形式之一。此外，企业也可以通过RESTfulService方式向合作伙伴或客户提供自己的服务。图3描述了如下ROA与SOA集合的方式。

SOA和ROA融合

图3. SOA和ROA的关系

    不过随着企业级应用越来越Web化，遗留系统正逐步淘汰，ROA与SOA的结合可能会成为未来企业级解决方案的重要组成部分。

    简言之，SOA不会被替代，ROA的地位会越来越高；二者并非排他关系，而是相辅相成，共荣共赢的关系。

云计算冲击下的SOA

    云计算是新宠，就像当年的SOA一样。当市场在大肆宣传云计算时，SOA在一旁淡然地笑了。喜欢挑起争端的人会说，“云计算来了，SOA该靠边站”。这种说法只能当作不负责任的市场噱头，不能当真。

    然而，二者并非同一层面的事物，不具有可比性，所以也就不存在谁替代谁的问题。相反，二者的关系十分密切，而且是互相补充，彼此促进的关系。笔者最近在InfoQ翻译过一篇文章：“圆桌论坛：SOA与云计算”。在这篇文章中，几位重量级人物从不同的角度各自阐述了他们对SOA与云计算间关系的理解。有兴趣的读者可以扩展阅读这篇文章。

    大师们的思想总是高屋建瓴，笔者自叹不及。以下是笔者对于SOA和云计算间关系的几点浅薄认识。

     1. 云计算的发展需要SOA的支撑。

一方面，云计算供应商需要使用SOA原则来架构自己的内部系统。众所周知，云计算的核心同样是服务，计算、存储、网络、软件等，一切皆服务，并且以服务的形式向云端用户提供按需供应的能力。那么，如何将这些能力封装成服务，以良定义的接口向外界提供服务，这正是SOA的强项。所以，从这个角度说，云计算的兴起更加促进了SOA的应用。

另一方面，云计算发展的一个重要标志是越来越多的企业将其数据、服务、流程转移到云端。在理想情况下，云计算的终极目标是一切数据、服务和流程都运行在由几大云供应商的共有云中。暂不论此终极状态是否能达到，即使能实现这一目标，也需要漫长的过程。现阶段，企业不可能将其核心数据、流程全部搬迁到云平台中。所以，当企业同时使用云服务内部系统时，势必产生二者之间的服务互访、流程整合等问题。此时，只有SOA才能将这一切有效地整合、管理起来。

     2. SOA的一些实施原则可运用于云计算。

SOA的松耦合、对外提供良定义服务以及服务治理的原则都能很好地运用于云计算。

首先，云计算的一大特点是弹性伸缩。若其内部系统不是松耦合的，那么其扩展性和弹性就无从谈起。只有其内部组件之间的连接是松耦合的，云计算供应商才能方便控制需伸缩的部分执行弹性伸缩。

其次，若没有良定义的服务，云服务消费者在查找、理解、集成云服务时的体验就会大打折扣。用户体验是云计算供应商维系用户的重要内容，所以不容忽视。

第三，当云服务及其用户数量越来越多时，服务更新、版本升级、服务隐退等动作都会对云用户产生很大的影响。云计算供应商需要有很好的服务管理策略才能使这些动作对用户造成的影响最小化。

3. SOA和云计算的最佳结合点是企业。

目前SOA大量应用于企业级应用及流程整合，而云端应用大量分布在互联网上。

首先，二者结合的一种方式是企业将一部分业务从现有系统中剥离出来，放入云平台（如PaaS）中，以享受云计算带来的种种运维上的益处。此时，应用间的整合成为SOA的典型需求；

其次，企业还可以租用互联网上现成的服务，来丰富其业务流程，从而实现业务上的创新。此时，流程编排的服务即包括本地应用中的服务，也包括云端服务；

第三，企业私有云的建设也是SOA与云计算的很好结合点。

小结

    经历凤凰涅盘后的SOA在中国大地上已经深入人心，并且走上了稳健发展的大道。虽然它不能解决所有问题，但它的确是公认的优秀的企业级架构风格之一。请人们不要再执着于比较SOA、ROA以及云计算孰优孰劣之类的问题了，这些不同的架构风格、思想及其使用的技术各自从不同的视角解决了不同的IT需求，我们应更多地思考如何将它们合理地融合起来，并运用到我们的解决方案之中。