支付宝远程调用规范doc.docx
《支付宝远程调用规范doc.docx》由会员分享，可在线阅读，更多相关《支付宝远程调用规范doc.docx（118页珍藏版）》请在冰豆网上搜索。
支付宝远程调用规范doc
支付宝远程调用规范
０．1版
1.现状分析
本章以支付宝系统的架构为上下文，分析目前支付宝系统中的服务协作模式、远程调用场景与远程调用技术现状。
对现状的分析是改进并形成规范的基础。
（1）支付宝系统架构概述
为了满足互联网金融服务系统的快速变化与高度稳定的要求，支付宝系统的架构需要向面向服务架构迁移。
面向服务的支付宝系统架构如下图所示:
不同类型的服务对部署提出了不同的要求.比如交互服务要求公网可访问、可以快速变化;核心的业务功能服务则要求稳定、具有海量吞吐能力;外部合作服务可能要求提供特殊的网络访问方式,需要包含外部服务商的提供的类库、文件与配置等等。
由不同的服务有不同部署要求，因此支付宝系统必须采用进行分布式部署，通过分布式服务间的协作实现业务流程。
为了支撑高度可用的服务协作网络,支付宝系统采用了以服务farm为基本单元的部署架构.每一个farm是一个相对独立由多台物理机器组成的高可用集群,用于支撑一组部署要求相近、相互间耦合紧密的服务。
farｍ之间是松耦合的，它们具有不同的服务功能、发布策略、管理策略与软硬件基础.这种基于ｆarm的部署架构如下图所示:
对于支撑高度复杂应用的Farｍ,如前台Ｆarm、后台Farｍ，其内部还有不同服务器的分工.比如前台Ｆarm的结构如下:
（2）支付宝服务协作模式
在对支付宝系统的逻辑架构与部署架构进行了阐述之后，我们得知支付宝系统未来的发展方向是拆分成相对独立的各类服务，并且分布部署在不同的Farｍ以及Farm中的不同服务器之间。
分布部署的服务间如何进行协作以实现高度复杂的业务流程?
在本节中，我们探讨支付宝系统中常用的几种服务协作模式。
在未来的系统设计中，将尽可能采用标准化的服务协作模式。
一、服务请求—响应模式
这是最简单的服务协作模式。
一方是服务的消费者，一方是服务的提供者,服务的消费者向服务提供者发出服务请求，服务提供者进行服务逻辑处理，并返回给服务提供者处理的结果.服务消费者根据结果进行后续处理。
服务请求—响应模式是一种点对点的访问模式。
当两个系统间的服务交互比较简单时，这是一种简单有效的方式。
当系统中服务越来越多之后，会形成一个复杂的服务提供-消费网络，给管理带来很大的挑战.而且,分布式服务间以同步方式进行远程调用会付出一定的性能与可靠性成本。
因此，在对业务流程进行服务分解与服务分解时，要慎用这种方式,多考虑有无其它替代方案，控制好点对点服务请求-响应的使用范围.
在支付宝系统中，服务请求—响应模式的典型应用场景例如：
⏹用户使用证书登录时，调用证书核心服务进行CRL验证,并根据验证结果决定用户登录后具有的角色;
⏹银行网关在完成银行订单反馈确认与资金入账之后，请求前台应用进行业务分流处理，并根据业务分流的结果跳转到前台系统的特定页面；
⏹淘宝系统调用支付宝系统创建交易订单；
二、异步服务请求模式
这也是一种简单的服务协作模式.服务的消费者向服务提供者发出服务请求,然后不等待服务提供者处理完成，就进行后续处理。
服务提供者自主地进行服务请求的业务处理，并且不返回结果给服务提供者。
为了使服务提供者的处理压力更平滑，提供处理的吞吐量,在服务消费者与服务提供者之间，一般通过ESB进行消息缓存与中转。
加入ESB之后的应用模式如下图所示:
目前在支付宝系统中使用的异步服务请求模式基本上都是后一种通过EＳＢ进行中介的模式.
支付宝系统中异步服务请求模式的应用场景例如：
⏹支付宝后台Ｆarｍ中的bｏps服务器调用bopｓtasｋ服务器进行长时间的对账处理;
⏹支付宝银行定时查询程序调用银行网关服务器进行自动意外数据恢复;
⏹支付宝应用调用可靠通知服务器进行立即通知发送；
在异步服务请求模式，服务的消费者是有意识调用服务的,也明确知晓服务提供者的调用方法与服务语义.因此，尽管异步方式使服务消费者与服务提供者在系统层面的耦合度更松,但在逻辑层面，双方还是具有耦合性的,当服务提供者的服务语义发生变化，或者调用接口发生变化，服务消费者也需要同时修改程序。
因此,在进行面向服务分析与设计时，也需要考虑是否有更好的替代方案，避免过多的点对点直接异步服务请求将使系统的拓扑成为难以管理的网络。
三、消息发布—订阅模式
基于消息发布与订阅模式的服务协作模式是一种松耦合的服务协作模式.在这种模式下，没有静态绑定的服务消费者与服务提供者关系存在,而是由消息总线根据业务集成逻辑,自动将服务消费者产生的消息转换并路由给多个感兴趣的服务提供者.
由于这种模式相对复杂，我们举一个例子加以说明。
假设消息发布者是交易系统。
它在处理完交易之后发布出一个标准消息，其中包含本次交易处理的结果,以及交易的主要情况。
发布完消息之后,交易系统进行后续处理。
ESB系统收到标准交易消息之后,根据配置进行消息的转换与分发:
它将消息转换为沟通系统接收的消息格式,派发给沟通系统进行用户沟通（邮件、短信、IM的定制发送）;它将消息转换为ＣTU系统要求的消息格式,派发给CTU系统进行风险审核；它将消息转换为可靠消息通知服务器要求的消息格式，派发给通知服务器进行商户的交易状态通知。
由于运用了消息发布—订阅模式，交易系统就不再需要知道沟通服务、ＣTU服务与可靠通知服务接口的语义与调用方式了,甚至不需要知道存在这类系统,完全由消息总线通过配置或相对少量的编码工作完成服务间的协作工作.未来再需要增加新的消息订阅者，比如收费服务,交易系统仍不需变化。
消息发布-订阅模式目前在支付宝系统中尚未得到运用，但由于ESＢ总线作为基础设施已经搭建完成，业务服务之间的关系也正在渐渐理顺，因此有机会将目前存在的不少异步消息请求模式转换为消息发布-订阅模式，降低支付宝系统的服务之间耦合性。
在进行面向服务的分析与设计时，建议尽量运用这种模式解决业务流程中服务的协作问题。
（3）支付宝远程调用使用场景
在本节中，我们归纳支付宝系统中目前常用的远程调用场景。
这些场景不是一个穷举的清单,而是尽量只列举有实际应用价值的场景;对于一些未来有用但现在尚未分析清楚的远程调用场景,本列表也未包含，比如Ｆａｒm间消息广播等,这些将在后续的工作中进行探讨与改进。
应用场景
消费者
调用模式
场所
Farm间服务调用
内部系统
请求－响应
Farｍ间
Farm间消息通知
内部系统
只请求
Ｆaｒm间
Fａrm内消息通知
内部系统
只请求
Ｆarm内
外部合作服务调用
外部系统
请求－响应
跨防火墙
一、Ｆａrm间服务调用
Ｆarm间服务调用是指由一个Farm中部署的应用请求另一个Farm中部署的服务,并且等待取得返回结果之后，再进行后续处理.Farm间服务调用的典型例子有：
⏹前台Farm处理证书登录时，调用数据证书核心Fａrm检查ＣRL;
⏹银行网关Ｆaｒm处理网银支付结果时，调用前台Fａrm提供的业务分流服务（即将改造成这种形式）；
⏹银行网关Ｆarｍ处理卡通支付时,调用核心银直通服务器提供的银行直通服务（即将改造成这种形式）.
⏹ＣＴUFarｍ在处理充值退回时，调用后台Ｆarｍ的充值退回服务；
二、Fａrm间消息通知
Farm间消息通知是指由一个Faｒm中部署的应用构造一条消息,并发送给另一个Faｒｍ中的服务;消息的发送方不等待接收者响应就进行后续处理。
Fａrm间消息通知的典型例子有：
⏹前台Faｒm在完成用户登录处理之后,向CTUＦａrm提供的风险控制服务发送登录事件消息；
⏹后台Farｍ在完成用户关键信息变更之后，向前台Ｆａrm的用户快照服务发送用户信息变更消息；
⏹CTU Fａrm在完成交易处理之后，向前台Ｆarm提供的可靠消息通知服务发送通知请求消息；
⏹论坛Ｆaｒm在发布帖子之后，向前台Fａｒm提供的沟通服务发送沟通消息.
三、Farm内消息通知
Ｆａrｍ内消息通知是指由Faｒｍ内一台机器上部署的应用构造一条消息,并发送给同一个Faｒm内另一台机器上的服务进行处理；消息的发送方不等待接收者响应就进行后续处理。
之所以需要在一个Fａrｍ内引入分布式处理，主要是为了将长时间操作转移到特定的服务器上进行异步执行，以保证负责处理用户交互的服务器有足够的资源快速处理用户请求。
Farm内消息通知的典型例子有：
⏹前台Farmｐay服务器向前台Fａrm paｙtaｓk服务器提供的沟通服务发送事件通知，实现邮件、短信或IＭ消息的定制发送;
⏹后台Farm bops服务器向后台Farm bopｓtasｋ服务器提供的对账处理服务发送事件通知，实现长时间对账处理的异步执行；
⏹前台Fａrmｐａｙ服务器向前台Fａrmpaytａｓk服务器提供的用户快照服务发送用户信息变更消息，以异步变更用户快照；
四、外部合作服务调用
外部合作服务调用指支付宝系统与外部系统之间的相互调用。
目前的典型例子有：
⏹淘宝系统调用支付宝系统创建交易；
⏹支付宝系统调用淘宝系统通知交易状态变更；
⏹阿里巴巴调用支付宝系统获得会员信息;
⏹外部系统调用支付宝外部接口产品;
⏹淘宝CRM系统调用支付宝CRM系统转发小记.
（4）支付宝系统远程调用技术现状
支付宝系统中目前使用的远程调用技术主要有以下几种:
一、直接ＨTＴＰ/ＨTＴPＳ
这是一种直接通过HＴTP协议传递调用参数与返回值的方式.根据参数与返回值的复杂程度不同,这种方式又有以下两种主要变体：
参数形式
返回值形式
例子
Querystｒｉng
Querｙstrｉng
淘宝创建交易接口
QueryＳtriｎg
XＭＬ
外部统一接口产品系列
其中,QuｅryStriｎg是指下面形式的参数或者值的表示:
Ｋey1＝valuｅ１＆kｅy2=value2
XMＬ是指下面形式的参数或值的表示:
〈？
xmlversion＝”1。
０" ｅｎcｏdｉng＝＂GBK”？
>
〈ａlipay＞
＜ｒｅquest＞
〈param ｎａmｅ=＂param1＂〉vａlue１
〈/ｒequest＞
〈rｅspｏnsｅ＞
．。
。
〈ｓｉgn_tｙpe＞..。
〈/ｓigｎ_typｅ>
直接HＴＴP／ＨTＴPＳ接口目前主要的应用场景是:
⏹外部合作服务调用：
ﻫ如支付宝给淘宝提供的专门接口、支付宝的外部统一接口等。
⏹Farm间服务调用：
如银直通服务器调用接口、证书ＣＲL验证服务器接口等。
二、Hessｉａn
这是在SpringReｍotiｎｇ框架中集成的一种轻量级、快速的基于ＨTＴP的远程调用服务,来自jetty的开发商cａuchｏ.
由于Hessｉａn无法支持Aｌibaba Enum类的序列化（具体原因可参看附录中对Hesｓｉan序列化机制的分析），而支付宝系统的数据对象中大量使用Alｉbaba Ｅnｕm作为枚举值的类型，因此，目前在支付宝系统较少使用Hessian进行内部系统间的远程调用与消息通知。
目前在用的场景主要有:
⏹支付宝CRM系统与淘宝ＣＲＭ系统间是使用Heｓsian方式进行相互间的远程调用.
⏹支付宝CRM系统与论坛系统之间是使用Ｈessian方式进行相互间的远程调用。
⏹CTU系统的远程配置服务通过Hesｓian方式提供。
三、HtｔpIｎvoｋer
这是Spring框架中为了解决Heｓｓian对象序列化能力不足,而提供的一种与Ｈessｉan类似，但采用标准Javａ序列化方式的基于ＨTＴＰ的轻量级远程调用服务。
目前，Sｐriｎg ＨttpＩnvoker在支付宝系统中主要用于分布式Mｕｌe实例间的消息集成,较少有直接使用SｐｒingＨttｐＩnvokｅｒ的情况。
四、MulｅＥSB
支付宝系统的各个Farｍ内部与Fａrm之间通过Mule进行消息的转换、路由与分发，以实现位置透明与协议透明的基于消息的集成。
为了提高系统的可用性，避免性能瓶颈与单故障点,在支付宝系统中Ｍｕle实例是分布式部署的,每一个应用服务器实例上都内嵌了一个Mulｅ实例.不同的Muｌｅ实例间通过SpriｎgHｔtpInｖｏker进行集成。
ＭuleESB目前在用主要场景有：
⏹各类应用与可靠通知服务（部署在应用Faｒm内的payｔask服务器上）之间的消息通讯.
⏹各类应用与沟通服务（部署在应用Ｆarm内的paytask服务器上）之间的消息通讯。
⏹各类应用与CTU服务（单独一个Faｒm部署）之间的消息通讯。
⏹银行查询程序调用银行网关服务的银行意外数据自动恢复服务.
五、XFirｅweb sｅrvice
ＸＦire是Codehaus组织提供的一种高效、且较完整的ｗebｓervice实现。
它的执行效率比老牌的AｐachｅAxｉs要快数倍，而且在weｂserｖice栈的实现完整性上接近Aｘiｓ2。
XFｉre的另一个优势是与SｐriｎgRemoｔiｎg框架可以方便集成.
XFire目前还未在支付宝生产环境上开始使用，但在两个正在进行的项目中（银行网关独立项目与双证书项目）已经开始运用.
2.远程调用模式
如前所述，目前支付宝系统中使用了各种不同的远程调用技术，在选择与运用远程调用技术时存在着较大的麻烦与困惑,亟待有一套统一的规范作为设计与开发的指南。
但支付宝系统远程调用规范的制定并不仅仅是在若干候选技术中选择某一种作为系统内部的执行标准。
这是因为：
⏹与远程调用的具体实现技术相比，架构模式产生的影响更大，而且切换一种架构模式带来的重构工作量远远大于切换一种远程调用技术；
⏹任何技术都有其强项与弱点，没有任何一种技术适用于所有的业务与技术场景;这也是目前市场上存着各种远程调用技术，没有一种能够一统江山的原因所在.
因此，在远程调用规范的制定过程中,我们强调要对架构模式进行规范；在技术上不是为整个支付宝系统规定一种方式,而针对各种架构模式与业务场景尽可能统一分别规范远程调用方式,以取得最优的系统特性，并满足业务上的约束.
远程调用的目的是实现服务之间的协作。
我们在支付宝应用架构中考察服务之间的协作。
下图是支付宝的应用架构模型：
在支付宝的应用架构模型的指导下,我们可以将之前归纳出来的三种分布式的应用之间的服务协作模式与四种使用场景统一为下图所示的四种形式。
⏹内部服务导出／导入
指从一个应用中将服务通过某种机制导出，在另一个应用中导入该服务.导入/导出机制使远程服务能够像本地服务一样调用，提供了使服务位置透明化。
⏹异步服务请求
指从一个组合异步请求另一个应用提供的服务,但不关心服务执行的结果。
在这种情况下，我们使用服务总线作为异步服务请求的代理。
⏹消息发布／订阅
指一个应用中发布标准消息表明系统中发生的业务事件与系统事件,由其它感兴趣的应用订阅并处理该消息。
消息的发布与订阅也是通过服务总线进行中介的,以提供消息缓存、转换与路由能力.
⏹外部合作服务供应
为外部系统提供服务。
外部合作服务的形式受限于外部服务使用者的技术平台、使用习惯与产品包装上的需要。
一般说来，外部合作服务对跨平台、简单性、松耦合性的要求更高。
与之前归纳的服务协作模式与使用场景相比，我们将不再区分Fａrｍ内的远程调用与Fａｒm间的远程调用，因为这两者在技术实质与业务场景上并无很大不同,强制区分反而引起混淆，而且会由于远程调用技术的不同给部署增加额外的约束。
在设计服务协作时，需要根据业务与技术上的约束,在上述四种远程调用模式选择合适的方式进行运用。
3.服务数据规范
在支付宝应用架构中，服务数据层（正面左边的一纵）是整个支付宝系统的企业数据模型,它定义了跨产品线需要共享的业务概念，构成了企业业务统一语言中的基本名词，确保了业务之间在数据层面上有统一的语法与语义，是可集成的.
一般说来，在一个企业系统中会有三类数据模型，一类是存储在DB中的关系数据模型、一类是通过Java程序表示领域数据模型、一类是服务间传递数据的ＸＭL消息数据模型.这三类模型各有所长，各有用武之地。
关系数据模型适用于数据的存储与分析、Ｊava领域数据模型适用于业务逻辑处理、XML消息数据模型适用于异构系统中的数据交互，因此在相当长一段时间内,系统中这三类数据模型一定会共存。
为了保证不同数据模型之间的语义是一致的，结构是可适配的，在企业系统中,需要规定一个企业级的服务数据模型。
可以把它看作是一个数据骨架，作为各种不同数据模型建模的统一基础。
根据服务数据模型的角色定位，我们要求服务数据模型具备以下特性:
⏹与业务一致；
服务数据模型是为业务概念建模,而不是为实现细节建模。
⏹严格性：
服务数据模型的定义是严格的，最大程度避免解释与转换中产生歧义.
⏹高度稳定;ﻫ服务数据模型必须高度稳定，它的变化会产生较大业务风险，而且也会波及到依赖它的其它数据模型与系统.
⏹有约束的结构：
ﻫ对服务数据的结构存在一定约束，使得它可以转换为关系模型、对象模型与XML模型；
⏹精简:
ﻫ尽量保证服务数据层的精简，只将确实需要在全系统中共享的业务概念（比如会员、客户、交易等）放到服务数据层中.
⏹全局可见：
服务数据由于被整个支付宝系统共享,因此需要放到一个全局可见的位置。
理想的，服务数据的建模需要一种中立于关系模型、对象模型与ＸMＬ模型的特殊建模标准，SDO（ＳeｒｖｉcｅDａｔaOｂｊect）就是一种正在兴起的服务数据建模标准，对于这种新技术我们需要关注它.但由于目前支付宝系统的开发仍以Ｊava代码为中心，而且在过去已经积累了大量使用Ｊａｖａ代码表示的服务数据。
因此，现阶段，服务数据仍需要通过Javａ对象来建模.
为了满足以上特性，对于Ｊava对象建模的服务模型必须建立一些约束。
这些约束具体如下：
（1）服务数据放在ｂｅｙoｎｄ-cｏｍｍｏn—domain这个项目中,分产品建立ｐａｃｋage。
比如会员相关的服务数据放在ｃoｍ。
aliｐay。
ｃoｍmon。
domain．uｓeｒ中。
（2）服务数据代表业务概念，而不是操作参数/返回值。
比如ＵsｅｒＩｎfo,是一个代表用户信息的业务概念,它可以作为服务数据；而QueryAｃｃouｎtBalanceVO是针对账户查询服务的一个操作参数，而不是一个业务概念，它就不应该作为服务数据。
（3）只包含数据,不包含业务操作（俗称的“瘦"领域模型），这是因为不是所有的数据模型都支持操作这一概念。
（4）服务数据的Jaｖa类满足以下要求：
⏹有“空构造器”；
⏹所有可读的属性都对应可写的属性;
举个例子：
以下类是不符合服务数据的要求的：
ｐａcｋａｇｅcｏm．aｌｉｐａy.poｃ.rｅmoｔｉｎg。
ｄａtａ.ｂａsic；
pｕｂlic ｃlａsｓ Ｕｓeｒ ｛
priｖaｔeＳｔringｎame;
publicUsｅｒ（Stｒｉｎgname） ｛／/ 没有无参构造器，不符合要求
super（）；
this。
nａme=namｅ;
}
public ＳtringgｅtName（）｛ // 只有get方法，没有对应的sｅt方法，不符合要求
reｔｕrnnamｅ;
｝
｝
这个要求是为了方便进行自动数据映射。
当需要将服务数据对象从源JVM传递到目的ＪVM时，需要在目的JＶM中重新构造这个对象,并恢复它的状态。
满足上述约束条件的Jaｖa类可以较方便地自动完成这一过程。
（5）服务数据对象的属性必须也是符合服务数据约束的类型，或者以下基本类型
⏹基本数据类型：
boolean,iｎt，ｓhort,ｄouble，floaｔ，lｏｎg,ｃhaｒ
⏹jａvａ。
lang中的类型：
Chaｒacter，Sｔrｉng，Boｏｌeaｎ，Integeｒ，Shｏｒt，Dｏublｅ，Float，Long
⏹ｊava．utｉl中的类型：
Datｅ，Ｃaleｎｄar
⏹java。
sql中的类型：
Ｄaｔｅ，Time，Timｅstaｍp
⏹ｊａｖa。
ｍatｈ中的类型：
BigＤｅcimal,ＢiｇInｔegeｒ
⏹数组类型
⏹集合类型
⏹支付宝基础类型：
com．iｗaｌleｔ。
moｎ．util.Money
⏹阿里巴巴ｃoｍ.ａlｉｂaｂa.coｍmon.lａnｇ.ｅｎｕmeration。
Enuｍ类型与其特定的子类
这里特别要说明的是在允许的属性类型中包含了Monｅy类与阿里巴巴Enum类型。
这是因为这些类型已经成为支付宝系统中的基本类型，为大家所熟悉，得到了广泛应用.
（6）通过枚举、范型等语言特性,严格地定义数据。
举一个例子如下：
publicclassＵｓerimｐｌementｓＳｅriaｌizａｂｌe ｛
/＊＊ seｒialVeｒsionUIＤ＊／
private sｔatic fｉnallongsｅｒialVeｒsｉonUID=57９84360L；
/**用户属性 *／
ｐrｉvateMap propertieｓ；
／＊＊
＊＠rｅtuｒnthepｒoｐerｔｉｅｓ
＊／
pｕblic MaｐgetPrｏpｅｒties（）{
rｅtｕrnpropertｉes;
｝
/＊*
＊ ＠ｐaram propｅrtiestｈｅ pｒoperｔｉestosｅt
＊/
pubｌiｃvoidsetＰroperties（Ｍａpｐｒopeｒties） ｛
ｔhｉs。
propｅrｔieｓ =propeｒｔies；
}
在这个例子中,ｐｒopｅrties是一个无约束的Mａp对象，对于服务数据的使用者，他不知道Maｐ中的kｅy与vａlue是什么类型的。
这会为数据映射的生成、数据的解释与使用带来不确定性。
假设keｙ与ｖalue的属性都必须是Strｉnｇ，那应该声明成：
publicclassＵserｉmpleｍeｎtsSeｒializａｂle｛
/＊＊seriａlVｅrｓioｎUIＤ＊/
privatestａtic final loｎgseriaｌVｅｒsｉonUID=579８43６0Ｌ；
/＊＊用户属性＊/
prｉｖatｅＭap prｏpeｒtｉes；
／＊＊
* ＠retｕrn the pｒoperties
*/
pｕbliｃMaｐ〈Striｎg,Ｓtｒing〉getProｐｅrｔies（）{
retuｒn properｔies;
｝
/＊＊
＊ ＠param pｒopertieｓtheｐropertiestoseｔ
＊/
publｉcvoｉdｓｅtPropeｒｔies（Ｍapｔhis.pｒｏpｅrｔies =ｐroｐｅrties;
｝
（7）服务数据需要稳定。
（8）服务数据需要精简，只在某条产品线中使用的数据，不要公开到服务数据层。
比如CeｒtｉfyActionCｏnｔexｔ,这个对象只是认证系统内部使用的数据，就不应该公开到服务数据层。
服务数据一般不会直接作为消息或调用参数在系统之间传递,一般会被封装成消息再传递。
消息不在ｂeyoｎd—commoｎ—doｍaiｎ中进行定义,以免在业务数据上增加大量与业务无关的内容，而是在bｅyond—commｏn—ｆaçａｄe中与服务接口定义在一
升级会员 