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.

当服务调用失败比率超过阀值时，通知运维人员。