SOA项目实施总结

SOA描述了一个信息系统理想的结构，基于ESB (Enterprise Service Bus),BPM (Business Process Management), BO (Business Optimization) 中间件平台，将整个系统划分实现为基础的数据服务，基础的公共功能服务，业务逻辑和流程服务，各种渠道接口和客户端展现框架。在这种结构下可以最快地开发一个新的应用产品，最大程度地复用已有的功能，利用成熟的中间件产品。当然目前距离实现这个理想状况，还是路漫漫其修远兮。 做过一些SOA项目， 遇到设计，开发，实施层面的各种问题， 在此总结一下希望能抛砖引玉。
（1） 最大的难题在设计层面，即信息系统的服务定义和划分。很好地完成这个工作需要对业务很精通，同时了解已有的各个IT系统，对SOA有很深的理解和经验，这些还只是必要条件。 设计问题是没有固定答案的，设计的好坏可以在之后不久的开发实施中就能体现，也可能要等很长时间以后，出现新的业务需求，构建新的应用产品时才能体现。 见过一些SOA项目，软件平台买了装了，只做了些简单的集成流程，一对一的封装一些已有功能的接口就结束了，远没达到SOA信息系统的标准。究其原因就是没有足够的能力来做整个系统的服务规划和设计。
（2） 性能问题也是目前一个很重要的问题，即服务的吞吐量，并发量，访问时延的要求。虽说SOA服务接口并限制哪种接口技术，但最常用和最标准的还是Web Service。 XML的数据格式，Web Service的接口技术，这两项选择导致SOA系统的性能成为很大的瓶颈，最根本的还是使用了XML来表示数据。如果整个系统数据模型比较复杂，层次较多， XML数据在内存在网络上都有很大的时间和空间开销。一般采用的解决方法是，尽可能简化数据模型，简化XML Schema , 或者采用XML硬件加速设备。 除此之外就是做系统集群了，通过增加服务器的方式来达到服务性能要求。
（3） 事务，尤其是分布式事务。 分布式事务的实现一直都是个麻烦的事情，很多系统干脆从设计上避免使用事务，比如银行系统使用冲正操作来解决非正常结束交易带来的业务数据或者状态不一致问题。但还是有系统有支持分布式事务的需求。 Web Service虽然有Transaction 扩展协议，但目前很多ESB产品包括其中的Adapter适配器都不支持事务。如果基于这些ESB平台，开发有事务需求的逻辑就比较麻烦了。
（4） 发布订阅式服务的实现。 Web Service接口比较适合请求/应答的服务模式；对于服务方向被服务方推送数据的发布订阅式的服务模式，通常我们采用消息接口。这种模式的服务一般都是数据量巨大，又要求高实时性，所以比起普通的请求/应答式的服务，这种服务更不容易满足性能方面的要求。
（5） 服务监控系统。ESB产品都是包含服务监控功能的， 但现在客户的需求是越来越多，越来越细了，碰到现有ESB产品满足不了客户方监控需求的时候，就需要做二次开发来实现这些监控需求。这在很多项目中也是个不容易解决的问题。下面列出通常的服务监控需求：
a. 服务运行状态，单笔服务调用处理时间。
b. 单位时间内，服务请求调用次数统计，服务调用平均处理时间统计。
c. 服务调用成功笔数和失败笔数统计。
d. 服务调用方统计。
e. 排队状态的服务请求数目，即到达服务端但还没有处理的请求数。
f. 当服务负载过大时，通知服务调用方，控制调用服务频率。
g. 当服务调用失败比率超过阀值时，通知运维人员。

（6） 服务流量控制。 要求能控制服务请求调用的数量，不能把后台跑死了。不是所有的服务接口技术，或者ESB产品都提供流量控制。 使用消息服务接口是个好选择，消息层可以定义队列大小，起到控制服务调用流量的作用。
（7） 服务接口是否使用统一的技术方式。各个系统的多个服务使用一样的接口技术（比如 Web service）当然比较方便。然而受限于各种因素，可能服务的接口技术不只一类（比如Web service, JMS Message, EJB etc），出现这种情况，如果SOA平台能提供比较方便使用的服务调用端API库，那用户也能接受。
（8） SOA平台从技术层面解决的是异构服务接口互联互通的问题。异构接口技术的互联互通比较简单，主流的ESB产品都支持各种接口技术。麻烦的是接口里数据模型的统一，SOA项目的一个重点就是要做到各个系统的多种服务尽量能达到数据模型的统一。现在企业应用也推荐使用行业数据标准。如果遗留系统太多，不容易短时间将所有系统都改造成使用统一的数据标准，那至少让这些系统暴露的服务接口使用统一的数据模型，方便彼此的互联互通。
（9） ESB产品的限制。 没有十全十美的产品，在项目实施过程中，遇到一些产品的缺陷。有的ESB产品对编程语言的种类支持不够，比若只支持使用Java开发服务，不支持C, C++等语言；有的不提供服务客户端调用代码生成机制，让实施人员自己编写服务调用编码，比较费事。
（10） 监控功能的服务。 SOA的目的是让系统解耦成具备标准接口的服务的集合，利于功能复用，利于系统互联互通，利于新应用新产品的快速开发。我们在构建封装一系列业务功能服务时，也别忘了构建监控功能的服务。试想每个系统都有这样的监控服务，可以方便地以标准的接口获取各个系统的监控信息，可以构建一个覆盖所有系统的监控程序，在一个监控界面里看到所有的系统。
SOA项目的几项关键工作。先是要做整个服务的划分和定义；定义统一的服务调用接口Schema，以及接口里要使用的数据模型标准；再根据具体的要求，决定每个服务使用什么样的接口技术；之后决定每个服务如何来构建或者封装。