海关SOA实践之路

海关SOA实践之路

 

 

 

一、概述

几乎每一位开发人员都抱怨过：“为什么需求又改了，这样做下去什么时候才能结束？！”。这种从未停止的抱怨并没有产生预期的结果，该变的还是在变，即使某段时间内我们可以堵住业务需求的改变，但用不了多久它又会以另外的形式提交到开发人员的桌面。

业务需求的不断改变是客观现实，我们无法拒绝。业务人员总是等系统做出来以后，才提出各种这样那样的问题。“为什么不早说”——这样的反问其实毫无意义，谁家的装修是全部说清楚之后才开始动工的？！谁能说对装修方案没有任何修改，而且做完后没有任何遗憾？！——真正艺术家确实有这样的本领，能真正做到“成竹早已在胸”，当然还有书法家：落笔稳健，一气呵成！

SOA并不指望每个业务人员都是艺术家和书法家，SOA接受业务需求的不断改变。那么它是如何适应需求不断改变的？

SOA即使不是灵丹妙药，至少也是一条正确的道路；

SOA即使不是海关业务改革的指南，也至少是后H2000时代海关信息化建设的必由之路。

谈到SOA如何适应需求的改变，首先从松耦合和软件重用谈起。这是两个相辅相成的概念，松耦合减少了软件模块的关联，从而增加了软件模块重用的机会；而大量的软件重用，会减少不同软件模块中重复的功能，从而形成松耦合的体系结构。

软件重用是一个非常复杂的问题，其中重用的等级可以大致按下图划分：

 

上图已经揭示了软件重用和SOA的关系。对于没有框架(FrameWork)的开发状态，最多达到“模块局部代码重用”这样的级别，对于有成熟框架的开发状态，可以较好实现“模块重用”的等级。但我们可以看到，SOA实现了更高层次，更彻底的软件重用。运行状态的服务重用体现了SOA的本质：“面向服务”。SOA以最彻底的态度为服务请求者提供一切便利，一个可重用的服务是真正随时可用的，从业务人员到开发人员到测试人员到架构师，都以完全相同的方式访问一个“运行状态可重用的服务”，从而使技术人员和业务人员的思维差异降到最低，业务人员所见即所得——需求的修改自然减少了^_^

理解松耦合比软件重用要容易一些。

最典型的松耦合现象就是我们生活中绝对需要的东西：人民币。

人民币这个东西好啊！但本文并不是谈论人民币越多越好，而是从它的原始功能：对商品交换的支持来探讨。

老赵种田收获2000斤米，老马养了100头肥猪，小花织了10匹布。老赵要想吃猪肉，老马要穿衣、小花要吃粮，那么他们直接拿东西来换不是很方便？

——如果他们只需要吃、穿、用，也许这确实够方便了，但这种方便其实是紧耦合：他们必须记着：1头猪换50斤米，1匹布换2头猪。。。

当大米和肥猪需要直接交换的时候，这两者就形成了耦合关系，这种耦合关系导致双方的变化会相互影响。如果他们有更多产品，需要交换更多的东西，很快就会发现生活乱套了。例如：老赵今年改种泰国优质大米，质量提高了，结果老马和小花都需要调整他们的产品和大米的交换比例——这种多方位耦合的现象，就是紧耦合。

有了人民币这个中介者，耦合现象仍然广泛存在，但大家都只是与人民币耦合，大米的质量发生变化后，只需要调整该产品与人民币的比价即可，不需要其它的产品生产者关心——这就是松耦合的效果：我们通过人民币作为中介者，全部产品只需要和人民币交换即可，把紧耦合的体系结构变成了松耦合（如下图）。

 

在没有人民币的紧耦合状态下，大米的质量如果发生改变，需要耗费很大的代价来解决关联的一系列商品交换问题，而人民币使这类问题能轻松解决。

同样的道理，在下图展示的软件体系结构中，ESB的作用相当于人民币，ESB并没有减少业务需求的改变，就像前面说的：SOA接受业务需求改变的客观现实。但SOA的体系结构使我们能够把改变控制在局部，任何改变只是局部的改变，不会影响全局。

 

松耦合是表达最小化依赖的概念，当依赖被最小化时，改动造成的影响也被最小化了。即使部分系统崩溃，整体系统也能运转，最小化依赖有助于容错和灵活性。下面是紧耦合和松耦合更全面的对比，其中，最重要的就是第一点。

 

 

紧耦合

松耦合

1.       

物理连接

点对点

通过中介者

2.       

通信风格

同步

异步

3.       

数据模型

公共复杂类型

只有简单的公共类型

4.       

类型系统

强

弱

5.       

交互模式

通过复杂的对象树导航

以数据为中心，自足的消息

6.       

业务逻辑控制

集中控制

分布式控制

7.       

绑定方式

静态

动态

8.       

平台

平台依赖性

平台无关

9.       

事务性

2PC（两阶段提交）

补偿

10.   

部署

同时进行

非同时进行

11.   

版本划分

显式升级

隐式升级

上面表格中几个概念的说明：

l  补偿

既保证总体的一致性，同时耦合程度也更松的方法是补偿。使用这种方法时，你先修改第一个后端系统，再修改第二个后端系统；如果只有一个修改是成功的，你就需要针对具体问题做出适当的“补偿”。例如，你可以回滚之前调用的服务的影响，或者，你必须向某个错误监控桌面机发出问题报告，引起某人来检查问题的细节，并手工处理。

l  交互模式

基本类型：a)请求/应答；b)单程；

复杂类型：c)请求/回调；d)发布/订阅；

l  隐式升级

一个完整的SOA体系结构，没有一个统一的版本，全局看来只是维持着应用项目交互方式的稳定，但不同应用项目内部不断有各种新变化。

 

另外，还有两个方面说明SOA如何有效应对需求不断变化的问题：

1、支持敏捷开发

举一个最简单的例子：

当某个系统需要实现传真功能，但我们之前还没有做过传真的功能。

这时，我们通过ESB，仍然只需要编写一行代码，即可调用一个发传真的服务——虽然我在1周的工期中不可能有时间编写任何传真服务的代码，但这并不影响服务的实现：综合科一位同事会替大家手工完成这个服务。3个月后，当我终于把自动传真的服务编写完成后，综合科的同事就可以省事了，同时，使用这个服务的程序无需任何修改——在ESB的支持下，自动切换到自动传真服务。

以往，领导常说的一个要求是：“先按最简单的模式做出来，上线试点后再逐步完善”——这个策略当然是正确的，但这个“逐步完善”可是个大文章，这正是开发人员长期困扰的问题，表面上是“逐步完善”，实际上是却只有“重做”和“不完善”两种选择，但有了ESB，我们真的可以实现“逐个完善”。

2、向后兼容

向前兼容是指某个系统升级后，原有数据和流程得以继续继承，并且相关联的另外一个系统无须任何改变，即可适应和拥有关联部分的功能。

“向后兼容”可以从下面的例子谈起：使用Outlook写邮件，写邮件的过程实际上是使用了word作为编辑器，如果Word增加了一个智能中英文翻译的功能，则Outlook本身无需任何改变，就会在写邮件功能中，会自动拥有这项功能——这时，Outlook实际上是拥有了向后兼容的能力。反之，MSN的编辑器是内嵌的（非SOA），这时不论是word升级还是notepad升级都与MSN的编辑功能无关，只有MSN自己升级，才能改善它的编辑功能——即：不能向后兼容。

在SOA架构下，服务之间是相互依赖关系，被依赖的服务如果升级，会自动体现在依赖者的功能中，相当于实现了向后兼容。

向后兼容是应对业务需求不断改变的最重要的手段之一。每次需求的变化，往往针对某个功能特性，但这个功能特性又对全局产生影响。SOA方法论要求我们的架构设计能支持这种个别功能特性的升级自动在全局产生预期的效果——即：向后兼容。

二、SOA和大型系统、老系统的关系

 

前面谈的需求改变的问题，只是一个很表面的现象。更深层次的问题是：SOA在大型系统、老系统的维护、改造和发展的影响。

（一）业务功能整合问题广泛存在

我们谈的最多的是“整合”，而不是“重建”，因为信息化发展到现在，几乎没有哪个组织和部门在信息化方面是一片空白。这时，业务功能整合无疑是最重要的问题，SOA正是为“业务整合而生”，结果也正是“业务整合最有效的方法论和实践手段”。

地铁服务确实在改变了很多人的出行方式，移动电话使人们的沟通方式发生巨变、互联网服务显然是极大地改变了整个世界的状态，GPS使很多不可能的事情变为可能

上述这些现实生活的情况说明：当新颖并且符合潮流的服务出现后，相关的社会秩序自然会朝“整合”的目标发展。在软件系统的建设中，SOA实现了应用项目之间标准统一的交互方式，这使新颖有效的服务很容易被其它应用项目分享，在自身发展的同时，也改变了其它应用项目的实现方式。

解决各种各样的业务矛盾并不是推进SOA的最佳手段；当我们提供了很多新颖而有效的服务后，业务整合就已经在前进了。

（二）面向服务的整合手段

传统的整合手段总是试图对当前业务的状态和可预计的未来业务状态进行总体规划，并从整体上创建符合规划的基础设施和总体架构；而SOA则不期望“总体规划”。SOA的目标是抽象出具有长期稳定性的业务边界，SOA更强调“边界”的稳定性，而不是业务模块本身的稳定性，通过增强业务模块之间相互关系的稳定性，实现了总体架构的可持续发展。

我们目前不断出了很多“翻新”的项目：新版舱单、新版旅客管理、新版企业诚信管理、新版价格资料管理系统。。。

虽然这些领域确实出现了很多新的需求，但我们如果仔细分析一下：旧的业务模式完全消失了吗？如果没有完全消失，为什么老项目中原有的对应功能无法重用？我们是否必须在把老项目完全取代，全部重建？——其实，SOA方法论最强调的一个方面，就是对老项目要进行改造，而不是重建取代之。

不少新项目仍然试图从“总体”上对整体业务进行规划，总是根据过去和当前的经验判断未来发展趋势。主要的缺陷有如下几方面：

1.         没有哪个部门能真正从“全局”上对业务进行总体规划；

2.         任何一个所谓的“总体规划”，最终都需要与其它系统和其它业务打交道，即使我们可以预计未来90%的情况，但只要出现10%不一致，也会导致业务系统之间交互的很大困难；

3.         业务状态过去在不断变化，今后也会不断变化，任何对“总体方案”进行规划的行为，都必须有效解决变化的问题，而且这些变化一定会超出最初的预计。

4.         最后一点，也是最重要一点：我们是否有清晰定义出各个业务功能的边界，该做哪些、不该做哪些，如何避免与其它业务系统的功能的重复，如果多个“全局”的应用项目中，出现重复或类似的业务功能时，在具体的应用中必然产生很多需要协调的问题，这些协调的过程和结果会导致系统不断需要修改。

 

（三）SOA是大型系统的维护手段

大型系统都有下面几个特征：

1)      异构

2)      不完美

3)      复杂

4)      冗余

大型系统必须处理“老系统”，引入SOA时，不可能从头设计一切。当前在用的大部分系统会一直用下去，建立SOA不是一个设计新系统的项目。实际上，SOA是对大型系统开展“维护”工作的方法。

大型系统的数据往往比功能有更长的生命周期，数据需要延续，而功能需要不断“维护”。

有了SOA，你会发现：原来不可维护或者一定程度上失控的大型系统变得可控和易维护了；SOA给我们提供了和“老系统”打交到，并实现向后兼容的解决方案。

SOA很适合处理复杂的分布式系统，SOA使需要一定分布式能力的实体能够定位、使用这些功能，方便了服务供应者和服务消费者之间的交互，使复杂业务功能的实现成为可能。

SOA接受大型系统中的异构现象：我们能从容应对开发工具的升级和管理好第三方软件；

SOA认为需求变化是正常的，可接受的；

 

三、SOA在海关的实施指南

（一）循序渐进——SOA成熟度模型

SOA成熟度模型是衡量一个组织在SOA方面的演进阶段的标志，目前IT界提出的比较典型的成熟度模型有下面两种：

SonicSOA成熟度模型：

1.      出现了某些服务，这些服务“体现了采纳SOA时最初的学习和最开始的项目阶段”；

2.      服务使用了“被设定来对SOA的实施进行技术监管“的标准；

3.      通过技术组织和业务组织间的合作，为保证SOA的使用提供明确的业务响应能力；

4.      主要工作集中于“实施内部和外部业务流程”；

5.      拥有“优化后的业务流程SOA”，以致“SOA信息系统已经成了”企业神经系统；

IBM提供的SOA成熟度模型：

1.      单个软件（数据集成）

2.      已集成（应用集成）

3.      已组件化（功能集成）

4.      简单服务（流程集成）

5.      组合服务（供应链集成）

6.      虚拟服务（虚拟基础设施）

7.      可动态配置服务（生态系统集成）

（二）从哪里入手？

前面说了很多SOA的优势，那么我们该从哪里入手？如何开始？

这里只是谈几条可行的意见：

1.      全力倡导大家学习SOA——就像改革开放和科学发展一样，首先要形成意识形态方面的共识；

2.      需求分析：这个环节可以算是入手点，需求分析的第一步是划分服务，拿到一份业务需求，先仔细分析需求的本质内容，然后考虑服务该如何划分，哪些服务可以重用（更多情况是完善后重用）？需要新增哪些服务？

有了合格的、SOA化的需求分析，后续的架构设计、开发、测试、运维就更容易理顺。

3.      科技业务一体化：需求分析环节的改变，无疑会与现实的很多人的思路有差异，会引起一定的混乱甚至迷惑，这时我们需要宣传和耐心细致的协商甚至某些局部的妥协，这就像围棋中盘的纠缠一样，需要细节的功力来处理好，从宏观上看，这部分工作正是“科技业务一体化工作组”可以做的事情。

SOA能力中心在技术方面要求会很高，在技术团队内部也算是更专业的部门，SOA能力中心最好作为科技业务一体化工作组的一个下属小组来开展工作。

4.      外部咨询服务：SOA的实施带有一定行业特性（业务整合是最重要工作目标），从外部资源看，具备海关或类似行业经验的丰富经验人员较少，不容易得到有成效的咨询服务，因此，估计还是立足自主建设，适当采购一些软件为妥。

（三）建立海关信息系统的服务总线（ESB）

SOA范畴的基础设施就是ESB（企业服务总线）。ESB的关键特性是：支持同构和异构系统之间的服务调用。它的职责包括：数据转换、智能路由、处理安全性和可靠性、服务管理、监测，以及日志。

ESB可以提供各种增值服务，其中最重要的是分布式调试的能力。

ESB是协议驱动还是API驱动，这是个基本决策。API驱动的ESB为供应者和消费者提供API，它被用来实现和/或调用服务。这使得协议的细节透明，但要求ESB按某种方式向供应者和消费者不是生产的代码和/或程序库。

总线代表了高度的互操作性。对我们的启示是：不去为不同系统间创建和维护单独的通信渠道，每个系统只要和总线连接就能够和所有其它系统连接起来。

你需要由技术规则、组织规则和模式所提供的结构。高度互操作性伴随着定义良好的架构、结构和过程。

虽然SOA本质上是方法论，但作为核心技术手段——ESB仍然是不可或缺的。

自从有了C++语言，我们就可以真正开始面向对象的编程，同样，有了ESB，我们才可以真正开始面向服务的架构设计。

业务和业务流程整合，必须完全是业务导向，符合真实的业务需要，整合后的业务组件以服务的形式提供，这些服务之间必须通过ESB才能良好交互。

ESB从业务服务的本质出发，支持同步和异步服务，同构和异构的服务，支持服务的寻址、暂停处理、复杂环境调用、服务稳定性观察、后备服务多种情形，甚至还会包括服务计费、身份认证、日志审计等安全管理方面。

这里可以再举一个典型的例子：

目前网上流行的“人肉搜索”，实际上就是一个服务，而ESB可以让我们直接用一行代码就实现对这个服务的调用，我们就像传统调用子程序一样，输入参数是“关于此人的描述(Description)”即可。

Description=edit(“请说明关于此人的描述”);

result=HpexBus.GetBus(“PersonSearch”).Go(Description);

Display result;

（四）基础性服务的演进过程

有了服务总线，在海关实施SOA的初期，还需要创建大量的基础性服务，我们必须控制好这些基础性服务的“演进过程”，以避免在SOA实施的初期耗费过多的资源。

演进过程大致描述如下：

阶段

步骤说明

要求

 

(一)  

定义出合理的服务边界和功能

1)   功能尽量单一；

2)   避免环境依赖性，依赖于另外一个服务而不是依赖某个特定环境，例如：流程服务不应该假设当前网络环境是单一的，而应该通过MQ服务实现流程信息的共享；

 

(二)  

以最简单的形式实现服务

1)   尽量在现有老系统基础上封装合理的接口来实现，而不是重新开发；检查是否已经有可用的同类服务，如果已经有，则增强原来的服务，而不是新建一个；

2)   符合当前项目的业务要求；

3)   符合前面定义的服务边界；

4)   可以不通过ESB实现服务调用；

5)   效率、压力方面以满足当前需要为限；

6)   先满足特定环境下的功能实现；

 

前面两个阶段已经满足传统项目建设过程的要求，

但我们仍然需要在项目建设完成后，有计划地完成后续三个阶段任务。

(三)  

把服务迁移到ESB上

如果上一步已经通过ESB调用服务，则这一步骤可跳过

 

(四)  

完善服务功能

1)   一般在2-3个项目中重用该服务时，逐步完善；

2)   可以在前期工作基础上完善，也可以适时推翻重来；

 

(五)  

服务功能完美化

1)   运行效率很高；

2)   能应付高强度压力；

3)   能适应多种复杂运行环境；

4)   实现人机结合的智能化(例如：预归类服务，最终完美化后，肯定是背后有经验丰富的海关人员在为各业务现场提供商品归类的实时服务)

 

 

四、SOA实施过程中的几个典型问题

（一）系统运行稳定性问题

仍然是一个基本观点：SOA是解决稳定性问题的必由之路。

在SOA环境下，服务不但在开发层面是重用，而且在实际运行中，也完全重用。SOA实施的高级阶段，开发环境和实际运行环境不再有明显区分，在ESB的支持下，服务可以区分出开发测试、业务测试和实际运行等不同形式的请求。比较合适的比喻是奥运安保的演习，除了没有真正造成大规模破坏和人员伤亡的后果外，测试过程的其它元素都是真实的。

SOA对稳定性的支持，关键原因是：以往的重用是开发层面的模块、代码可以重用，但运行环境不可重用，而运行环境的不可重用意味着每个新的应用项目都必须经历一个从不稳定到稳定的过程。而ESB则支持运行环境的重用，我们调用一个现有的服务时，只要它现在是稳定运行的，那么它被新的系统重用时，也一定是稳定的。

另外一个方面是监控。成熟的商业版本的ESB都提供了以服务为单元进行监控的功能，这时，监控人员看到的不仅仅是服务器的CPU，I/O，积压文件个数等信息，而是某个业务服务（例如：报关单放行、舱单核销）的执行状态，这种监控与业务人员的实际感受非常一致，我们可以更加准确跟踪业务系统当前状态，而且，这类的监控功能已经现实存在了，我们要做的事情只是把我们的服务挂到ESB上。

（二）压力问题（独木桥问题和云计算）

服务重用后，尤其是在运行环境重用后，被重用的服务会产生压力问题。

这方面的解决方案难以用三言两语说清楚，我这里先说下面几点：

1.      真正的压力最终体现在CPU和磁盘I/O两方面，近期兴起的“云计算”就是针对CPU和I/O压力问题的最终解决方案；你可以“像水龙头一样获取CPU和I/O资源”，只需要简单的把水龙头拧大一些；

有了“云计算”服务，我们不再直接使用某台服务器的CPU或某个磁盘柜的I/O，而是找某块“云”来存储和计算我们的东西，这时，压力问题转变成水龙头拧多大的问题——不再是问题；

2.      虽然微软已经推出成熟的“云计算”基础软件，但短期内估计还是难以真正应用。目前比较现实的做法是：服务内部主动按照一定的业务环境进行负载搭配，例如：物流平台读H2000报关单的服务需求量非常大，我们就专门搭建一台高性能服务器来运行这个服务；

——可以这样形象点比喻：“云计算”给我们提供了一个超大变焦能力的镜头，在我们拿到这个“超级变焦镜头”之前，我们只能估摸着当前的景象大致有多远，然后拿一个相应的固定焦距的镜头来拍照。

（三）效率问题

如果直接使用技术层面的业界标准或工具，例如：WebSerivce、JMS、BizTalk、WebSphereESB等，在极少数特殊情况下确实存在效率问题。

这些效率问题主要体现在通过ESB调用服务，服务参数XML转换等操作。

但如果因此认为SOA不适合效率要求高的场景，则完全是误解。

SOA更主要的内容是方法论，实施SOA并非要在100%的场合选择这些与效率有矛盾的工具、标准等。我们遵循SOA方法论对业务进行梳理和整合，但在技术上完全可以使用传统的方法实现，不通过ESB调用服务，服务参数仍然保持内部格式——这完全是可行的。

因此，只有不正确的SOA实施方法，才可能产生效率问题，SOA和效率问题丝毫不应该成为矛盾的双方。

另外，传统的设计方法同样存在很严重的效率问题。例如：由于基础设施方面的环境问题，我们经常不得不在不同网络、不同数据库的环境之间传输大量数据，现实情况表明，传统的设计方法由于重用性较低，导致很多相同或很相近的内容在其中大量重复传输，最终后果就是业务上的效率低下；而SOA方法能有效提高重用度，同时可以在全局层面提供增量传输的解决方案，使整体系统效率有较大改善。[!4]

（四）开发工具改变问题

显然，即使是最主流的开发工具，我们也已经我们经历了很多“时代”：COBOL、VB、.NET1.0、.NET1.1、.NET2.0-3.5等，另外很多周边或小型项目还用到了更多的开发工具。直到现在，我们实际运行环境中，仍然有VMS-COBOL的影子。现实已经很明显，我们必须承受这种多开发工具的局面。

ESB在解决服务调用的复杂性问题的同时，也解决了异构服务之间的调用。在理想的SOA场景下，整个大型生产系统中包含了大量的服务，这些服务在ESB的支持下相互关联，每个服务实现相对独立的管理，每个服务有自己的版本，而整个生产系统并没有明显的版本。我们只需要保持某一个服务内部使用统一的开发工具即可。

例如：挂号服务需要用到总署人事系统的人员信息，这两个系统分别使用.NET1.1和.NET3.0开发，在ESB的支持下，相互调用完全没有问题。

（五）第三方软件管理和软件外包问题

根据SOA方法论，我们外包的不再是“项目”，而是“服务”。我们可以准确规划、定义、检验、衡量外包服务的功能特性和质量特性。尤其ESB可以实现对外包服务的质量特性进行有效监控，及时发现问题，定期得到统计数据，使我们能够对外包软件实现量化管理，准确评估，合理分类。

对于重要的业务功能，我们甚至可以双重外包，让两个不同的软件外包公司分别开发相同的一个服务，并且同时运行，其中一个作为备份服务，从而大大降低软件外包和引入第三方软件而产生的风险。

当然，SOA也并非能解决全部外包和第三方软件的管理问题，少数情况下，某些第三方软件无法与ESB衔接，或者我们无法区分是衔接过程的问题还是第三方软件本身的问题。对于这些情况，我们都需要在SOA方法论的指导下，采取其它更多的辅助手段进行规范和完善。

（六）注意解决好几方面的风险

根据外部经验和海关现状，SOA实施过程可能存在下面几点风险，但只要充分重视，措施得当，这些风险应该可以有效避免。

1.         技术团队内部对SOA的理解可能出现不一致，导致实施过程的混乱；

2.         业务人员对SOA缺乏了解，有可能导致误解甚至抗拒；

3.         SOA更强调相互协助和配合，对提供基础服务者来说，甚至是一定程度上的无私奉献和默默无闻，而目前的工作机制以短期和局部的成功为导向，甚至为了局部的成功经常不惜违反规则，这个因素也许是SOA实施的最大风险；

当然，针对这个风险，也有解决方案：引入服务计费，这与现实生活一样，使用服务是要付费的；但这一步要谨慎，计费本身涉及比较复杂的关系，大部分情况下，消耗会大于效益。就像高速公路一样，从全社会看，最好都不设收费站，但从短期政策导向以及平衡各方面利益的角度，还是收费更好。

五、结论

SOA需要积极主动的主人翁态度才有可能实施好，同时也会使我们变被动为主动，我们有可能解决好当前海关信息化建设中的许多问题和困扰。虽然存在的一定的风险，但比起巨大的效益来说，显然是值得投入的。

另外，SOA也已经是IT发展的必然趋势，即使我们现在还可以不那么重视，但将来某一天，我们也不得不面对并接受，当然那时候我们可以避免很多前人走过的弯路，但同时我们的主动权也更加少了。