摘 要：以一个营业集中项目为例，介绍了电信业务支撑域的SOA服务模型定义、构建方法与具体过程，并分享项目实施中的相关经验和教训。
关键词：基于服务的架构；服务；操作；无状态
中图分类号：TP311.1
文献标识码：A
文章编号：1007-3043（2012）10-0006-04
0 前言
电信运营商的业务运营支撑系统（BSS）通常是较为复杂的大型定制化应用软件系统，随着电信市场竞争日趋激烈，新的营销策略、产品、业务受理规则、计费规则、合作政策层出不穷，要求BSS具备快速应变与支撑能力，以占据市场竞争先机，这与面向服务的体系结构（SOA）的宗旨不谋而合。
SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型。SOA可以看作是B/S模型、XML/Web Service技术之后的自然延伸。
SOA具有松耦合、重用度高、灵活应变、易维护、易管理等优点，得到了IT业界的广泛推崇，但引入并实施SOA并不容易，国内外的失败案例屡见不鲜。一方面是因为SOA本身缺乏标准规范与指导性文件，过度依赖实施厂商的项目经验积累与专家技术水平；另一方面则是客户心理准备不足，认为SOA仅仅是部署“ESB+BPM”，而没有认识到对企业业务流程与IT系统进行重构，将系统能力与功能抽象为SOA服务才是最重要，也是最困难的。
下面以笔者曾参与过的一个营业集中项目（以下简称本项目）为例，介绍SOA服务设计的通用方法与梳理过程，并分享其中的一些经验与教训，为后续的BSS领域SOA项目实施提供借鉴。
1 项目背景与挑战
该运营商希望建设集团一级架构的营业受理系统，作为全网用户业务办理与查询的唯一入口，为用户提供统一的业务使用体验，提升前台服务水平，实现营销政策、业务办理流程、业务受理与收费规则的全国统一，加强管控力度。但是订单处理、三户资料管理、渠道管理、业务资源管理、账务计费等核心功能仍然保留在省分BSS，一级营业受理系统通过后台接口调用省分BSS的数据服务或业务能力，实现面向用户的前台营业服务。
在系统层面，确定了“一级架构营业受理系统、总部ESB、省分ESB、省分BSS”的集成架构（见图1）。
服务设计是SOA的核心与精髓，也是难点所在。服务设计的方法与具体过程没有国际标准规范可以遵循，部分厂商提供了服务设计原则与最佳实践，但局限于特定业务领域。
本项目对服务设计的要求比较高，因此面临着非常大的挑战。
a） 本次设计的服务集需要支撑全国所有省分前台电信业务差异化受理流程，包括移动、固定与融合业务流程，超过1 000个流程，10万个产品套餐。
b） 针对新需求能够快速应变，在服务层稍微调整甚至不需要调增的情况下即可满足需要，将支撑周期从原先的3~6个月缩短至1~2个月。
c） 提升用户体验与美誉度，一级营业受理系统的主要营业指标与省分系统保持一致，用户对系统替换无感知，不影响使用习惯。
d） 充分考虑系统集中化趋势，将系统集中所带来的数据与功能迁移对服务层的影响降至最小，从而屏蔽对一级营业受理系统的影响。
2 服务设计方法
为应对上述挑战，需要设计一套统一规范、高效率、灵活、易于管理的服务集，满足当前与未来的需求。而为达成这个目标，需要先建立基础服务模型，找到一套行之有效的服务梳理方法，并将其清晰合理地分类，最终形成完整的服务目录。
2.1 服务模型定义
SOA中对服务的定义是“一个与业务功能或业务数据相关的接口，以及约束这个接口的契约，如服务质量要求、业务规则、安全性要求、法律法规的遵循、关键业绩指标 （KPI）等。接口和契约采用中立、基于标准的方式进行定义，它独立于实现服务的硬件平台、操作系统和编程语言。”
与服务紧密相关的一个概念是操作，一个服务一般包括一个或多个操作，操作是服务所支持的具体处理逻辑的体现，是系统之间实际通信的实体， 服务与操作的关系类似对象与操作的关系。
服务是对业务系统某种业务能力或业务逻辑的抽象，而操作则是服务的具体实现。以用户积分查询为例，可以分为用户综合积分查询、用户积分生成记录查询、用户积分消费记录查询等几类，它们既有区别又有联系，一个比较合理的办法是将其归类为用户积分查询服务，包含综合积分查询、积分生成记录查询、积分消费记录查询3个操作。
服务模型是对服务应包含要素的统一规范，根据本项目的实际需求，服务包括服务编码、服务名称、服务说明、所包含操作编码与名称、服务地域（全国/省分）、所属业务域、服务提供者编码、预期服务消费者编码等信息，其中最核心的是服务编码、服务名称与服务说明。
操作则包括操作编码、操作名称、操作说明、性能要求、可靠性要求、传输模式、是否压缩、是否加密、调用地址、调用方式等信息。其中操作编码、操作名称、操作说明、调用地址、调用方式是调用方比较关心的信息，而性能要求、可靠性要求、传输模式等信息是服务提供方比较关心的内容。
2.2 服务梳理方法
服务模型解决了什么是服务的问题，而服务梳理方法则回答如何找到服务的问题。服务的本质是系统间交互能力的抽象，因此想找到所需要的服务，应首先搞清楚系统间有哪些交互，然后再分析这些交互是否是固定模式，是否可以分类，然后一步步地找到所需的服务。
本项目采用了业界推荐的“需求-流程 -服务”三步骤映射方法，并根据电信业务的特点对流程进行了细化与补充。
a） 业务需求分析。业务需求是IT系统的唯一源泉与动力，详细与全面的需求分析是后续工作的基础。
b） 确定业务流程。根据需求分析结果，从业务角度而非系统实现角度讨论业务的具体步骤与参与方，并编制具体的流程。
c） 确定系统交互流程。将业务流程进行细化，并考虑系统实现，确定流程中的每一个环节涉及到哪些系统与功能，需要传递哪些数据，并编制具体流程。
d） 交互框架设计。对多个系统交互流程所涉及到的公共与核心环节进行抽象与统一设计，例如几乎所有营业受理流程都涉及到订单，分为营业费用计算、订单校验与提交、免填单打印、用户缴费与打印发票几个步骤，各个流程稍有区别，这就要求设计统一的订单提交框架。
e） 交互点定义与归类。交互流程中每一次系统的交互定义为一个系统交互点，包括交互系统、交互数据、功能等要素，将所有系统交互流程的交互点全部列出来，并根据交互数据与功能的相似度进行合并。
f） 操作抽取与反向验证。多个交互点合并之后即可抽取为一个操作，为了确保抽取后的操作没有遗失原来交互点的信息，必须将操作带入交互流程进行反向验证，验证之后再进行操作的颗粒度检查。检查项包括是否有类似的操作可以合并，操作是否包含功能太多需要拆分。
g） 操作编写。操作抽取完成之后，可以按照统一的数据模型与编码，进行操作的具体编制，包括操作编码、操作名称、操作说明、操作属性、输入参数、输入参数说明、输出参数、输出参数说明等内容。
h） 服务目录生成。在操作确定以后，可以根据操作的功能、数据、业务域等要素进行归类，确定操作所归属的服务，并将服务归类为几大业务域。
上述流程中，交互点合并、操作的抽取与反向验证是最关键的步骤，可能需要多次反复讨论才能达到预期目标。
3 经验与教训分享
本项目从立项到上线的整个周期长达2年左右，在服务设计与项目实施过程中，有很多经验值得分享，也有很多教训需要借鉴。
3.1 颗粒度设计
颗粒度包括服务颗粒度与操作颗粒度2个层面。
操作颗粒度主要考虑操作所包含的功能、涉及的流程与系统数量，设计的原则是完整而内聚。以用户积分查询操作为例，用户有3种查询方式（手机号码+服务密码、用户ID、营业员工号+手机号码），由于都是针对用户的积分查询，是完整而内聚的，因此可以在一个操作中实现，这个操作可以供多个流程调用。相对的，以新开户操作为例，内部又可以细分为客户创建、用户创建、账户创建、订购关系生成、服务开通、信息同步等几个步骤。这些步骤不适合拆分为单独的操作，因为这个几个步骤关联性很强，一旦失败必须回退，只能由省分BSS控制，而不能由总部系统直接调用，避免产生不可预料的错误。
服务颗粒度相对简单，主要考虑服务所包含的操作数量。在工程实施中，每一个服务会发布一个WSDL文件，如果所包含的操作数量太多，则每一个操作的细微修订都要求WSDL文件的重新发布，进而影响到服务的所有操作；另外一个极端是每一个服务只包含一个操作，这样做会导致服务数量急剧膨胀，难以管理。经过工程实施检验，一个服务包含3～6个操作是比较合适的。
3.2 无状态设计
无状态指的是服务不应依赖于使用者和提供者间长期存在的关系，操作调用也不应隐式地依赖于前一个调用，这是保证系统伸缩性、可用性与简化复杂度的一个常用设计手段，也是很多技术专家所推荐的。
粗颗粒度设计往往在很大程度上可以帮助进行服务无状态设计，因为粗颗粒度意味着服务本身是内聚而完整，不依赖于其他服务。
实现服务无状态的关键在流程设计阶段，进行流程步骤分解时，要注意检查各个步骤之间是否存在显式或隐含的依赖关系，如果存在，可以通过流程步骤合并、关键数据要素重复、数据标记状态等方法进行解决。
以开户流程为例，用户在开户时需要依次输入客户、账户、用户、产品、号码等信息，如果每一步都设计为一个操作，则这些操作之间必然是有状态的，因为账户创建依赖于客户先创建，用户创建依赖于用户先选择号码，为了避免这些服务调用之间的依赖关系，比较可行的办法就是前台对数据进行缓存，最终通过一个开户操作提交所有信息，实现服务无状态。
3.3 服务管理
一个工程项目的服务数量必然是非常多的，服务状态也会实时发生变化，如果不进行有效的管理，可能会导致混乱与业务错误。
服务管理应首先建立一套完整的服务目录，形成“服务目录、业务域、服务、操作、参数”的层级结构，并对服务的全生命周期进行定义，包括设计、开发、上线运行、暂停、下线等状态。
服务管理包括系统、服务与操作3个颗粒度，既可以实现以服务（也就是WSDL）和更细粒度操作为单位的状态与权限变更，也可以按照用户要求，实现对某系统所提供服务的整体状态变更。
服务管理中最困难的是服务版本维护，理论上，一个ESB可以同时部署并维护一个服务的多个版本，但在实际工程管理中，这往往导致管理复杂度与工作量的成倍增加，业务风险急剧加大。
在本项目中针对服务版本，采用了主版本与工程版本叠加的方法，允许在系统开发、联调测试阶段使用工程版本，一旦工程版本稳定，就必须在某一个时点升级，和主版本进行融合。这种方法的优点是管理复杂度比较低，也可以适应测试阶段的服务多版本管理。
3.4 运行性能
经过本项目的实际运行测试，在每一次服务调用中，消耗在ESB系统中的平均时间不超过1.2 s，占总响应时间的4%左右，而且与每个服务的操作数量、参数多少等因素关系不大。
评价服务运行性能不应看单个服务的响应速度，而应从用户体验出发，估算每个业务流程的整体响应时间，这样的评价更有意义。
4 结束语
SOA已经不是一个新事物，但在国内电信行业的应用案例仍然不多，主要是由业务管理及处理流程的适应性、规范不完善、依赖专家知识、应用目的不明确等因素导致的。
因此在实施SOA时，既要注意参考现有的规范材料与成功案例，更要从本行业、本项目的实际需求出发，综合考虑各方面因素，确定服务设计、管理、运行维护的整体思路，找到适合自身的服务模型与服务设计方法， 并按照此方法逐步实施并不断优化。
需要指出的是SOA服务的设计与完善需要一个较长的周期，不可能一蹴而就，因此设立一个专门的服务管理小组，专门负责整个集团层面的需求分析、服务设计、服务优化与发布工作。
SOA与云计算的结合正在成为新的发展趋势，而服务设计工作的重要性与复杂性也会更加凸显，希望本文在这方面能够对读者有所帮助与启迪。
参考文献：
［1］ IBM技术支持库［EB/OL］. ［2012-07-19］. http://www-900.bm.com/cn/support/viewdoc/detail?DocId=2633095A12000.
［2］ 实现SOA的相关技术［EB/OL］. ［2012-07-19］. http://searchwebservices.techtarget.com.cn/158/2116658.shtml.
［3］ XML［EB/OL］. ［2012-07-19］. http://www.xml.org/.
［4］ JAVA语言进阶:什么是Web Service［EB/OL］. ［2012-07-19］. http://java.ccidnet.com/art/3539/20061205/967669_1.html.
［5］ 2007年 OASIS探寻标准SOA参考架构［EB/OL］. ［2012-07-19］. http://searchwebservices.techtarget.com.cn/comment/46/3034546.shtml. 
