支付宝远程调用规范

支付宝远程调用规范0.1版1. 现状分析本章以支付宝系统的架构为上下文，分析目前支付宝系统中的服务协作模式、远程调用场景与远程调用技术现状。对现状的分析是改进并形成规范的基础。(1) 支付宝系统架构概述为了满足互联网金融服务系统的快速变化与高度稳定的要求，支付宝系统的架构需要向面向服务架构迁移。面向服务的支付宝系统架构如下图所示：不同类型的服务对部署提出了不同的要求。比如交互服务要求公网可访问、可以快速变化；核心的业务功能服务则要求稳定、具有海量吞吐能力；外部合作服务可能要求提供特殊的网络访问方式，需要包含外部服务商的提供的类库、文件与配置等等。由不同的服务有不同部署要求，因此支付宝系统必须采用进行分布式部署，通过分布式服务间的协作实现业务流程。为了支撑高度可用的服务协作网络，支付宝系统采用了以服务farm为基本单元的部署架构。每一个farm是一个相对独立由多台物理机器组成的高可用集群，用于支撑一组部署要求相近、相互间耦合紧密的服务。farm之间是松耦合的，它们具有不同的服务功能、发布策略、管理策略与软硬件基础。这种基于farm的部署架构如下图所示：对于支撑高度复杂应用的Farm，如前台Farm、后台Farm，其内部还有不同服务器的分工。比如前台Farm的结构如下：(2) 支付宝服务协作模式在对支付宝系统的逻辑架构与部署架构进行了阐述之后，我们得知支付宝系统未来的发展方向是拆分成相对独立的各类服务，并且分布部署在不同的Farm以及Farm中的不同服务器之间。分布部署的服务间如何进行协作以实现高度复杂的业务流程？在本节中，我们探讨支付宝系统中常用的几种服务协作模式。在未来的系统设计中，将尽可能采用标准化的服务协作模式。一、服务请求-响应模式这是最简单的服务协作模式。一方是服务的消费者，一方是服务的提供者，服务的消费者向服务提供者发出服务请求，服务提供者进行服务逻辑处理，并返回给服务提供者处理的结果。服务消费者根据结果进行后续处理。服务请求-响应模式是一种点对点的访问模式。当两个系统间的服务交互比较简单时，这是一种简单有效的方式。当系统中服务越来越多之后，会形成一个复杂的服务提供-消费网络，给管理带来很大的挑战。而且，分布式服务间以同步方式进行远程调用会付出一定的性能与可靠性成本。因此，在对业务流程进行服务分解与服务分解时，要慎用这种方式，多考虑有无其它替代方案，控制好点对点服务请求-响应的使用范围。在支付宝系统中，服务请求-响应模式的典型应用场景例如：n 用户使用证书登录时，调用证书核心服务进行CRL验证，并根据验证结果决定用户登录后具有的角色；n 银行网关在完成银行订单反馈确认与资金入账之后，请求前台应用进行业务分流处理，并根据业务分流的结果跳转到前台系统的特定页面；n 淘宝系统调用支付宝系统创建交易订单；二、异步服务请求模式这也是一种简单的服务协作模式。服务的消费者向服务提供者发出服务请求，然后不等待服务提供者处理完成，就进行后续处理。服务提供者自主地进行服务请求的业务处理，并且不返回结果给服务提供者。为了使服务提供者的处理压力更平滑，提供处理的吞吐量，在服务消费者与服务提供者之间，一般通过ESB进行消息缓存与中转。加入ESB之后的应用模式如下图所示：目前在支付宝系统中使用的异步服务请求模式基本上都是后一种通过ESB进行中介的模式。支付宝系统中异步服务请求模式的应用场景例如：n 支付宝后台Farm中的bops服务器调用bopstask服务器进行长时间的对账处理；n 支付宝银行定时查询程序调用银行网关服务器进行自动意外数据恢复；n 支付宝应用调用可靠通知服务器进行立即通知发送；在异步服务请求模式，服务的消费者是有意识调用服务的，也明确知晓服务提供者的调用方法与服务语义。因此，尽管异步方式使服务消费者与服务提供者在系统层面的耦合度更松，但在逻辑层面，双方还是具有耦合性的，当服务提供者的服务语义发生变化，或者调用接口发生变化，服务消费者也需要同时修改程序。因此，在进行面向服务分析与设计时，也需要 考虑是否有更好的替代方案，避免过多的点对点直接异步服务请求将使系统的拓扑成为难以管理的网络。三、消息发布-订阅模式基于消息发布与订阅模式的服务协作模式是一种松耦合的服务协作模式。在这种模式下，没有静态绑定的服务消费者与服务提供者关系存在，而是由消息总线根据业务集成逻辑，自动将服务消费者产生的消息转换并路由给多个感兴趣的服务提供者。由于这种模式相对复杂，我们举一个例子加以说明。假设消息发布者是交易系统。它在处理完交易之后发布出一个标准消息，其中包含本次交易处理的结果，以及交易的主要情况。发布完消息之后，交易系统进行后续处理。ESB系统收到标准交易消息之后，根据配置进行消息的转换与分发：它将消息转换为沟通系统接收的消息格式，派发给沟通系统进行用户沟通（邮件、短信、IM的定制发送）；它将消息转换为CTU系统要求的消息格式，派发给CTU系统进行风险审核；它将消息转换为可靠消息通知服务器要求的消息格式，派发给通知服务器进行商户的交易状态通知。由于运用了消息发布-订阅模式，交易系统就不再需要知道沟通服务、CTU服务与可靠通知服务接口的语义与调用方式了，甚至不需要知道存在这类系统，完全由消息总线通过配置或相对少量的编码工作完成服务间的协作工作。未来再需要增加新的消息订阅者，比如收费服务，交易系统仍不需变化。消息发布-订阅模式目前在支付宝系统中尚未得到运用，但由于ESB总线作为基础设施已经搭建完成，业务服务之间的关系也正在渐渐理顺，因此有机会将目前存在的不少异步消息请求模式转换为消息发布-订阅模式，降低支付宝系统的服务之间耦合性。在进行面向服务的分析与设计时，建议尽量运用这种模式解决业务流程中服务的协作问题。(3) 支付宝远程调用使用场景在本节中，我们归纳支付宝系统中目前常用的远程调用场景。这些场景不是一个穷举的清单，而是尽量只列举有实际应用价值的场景；对于一些未来有用但现在尚未分析清楚的远程调用场景，本列表也未包含，比如Farm间消息广播等，这些将在后续的工作中进行探讨与改进。应用场景消费者调用模式场所Farm间服务调用内部系统请求-响应Farm间Farm间消息通知内部系统只请求Farm间Farm内消息通知内部系统只请求Farm内外部合作服务调用外部系统请求-响应跨防火墙一、Farm间服务调用Farm间服务调用是指由一个Farm中部署的应用请求另一个Farm中部署的服务，并且等待取得返回结果之后，再进行后续处理。Farm间服务调用的典型例子有：n 前台Farm处理证书登录时，调用数据证书核心Farm检查CRL；n 银行网关Farm处理网银支付结果时，调用前台Farm提供的业务分流服务（即将改造成这种形式）；n 银行网关Farm处理卡通支付时，调用核心银直通服务器提供的银行直通服务（即将改造成这种形式）。n CTU Farm在处理充值退回时，调用后台Farm的充值退回服务；二、Farm间消息通知Farm间消息通知是指由一个Farm中部署的应用构造一条消息，并发送给另一个Farm中的服务；消息的发送方不等待接收者响应就进行后续处理。Farm间消息通知的典型例子有：n 前台Farm在完成用户登录处理之后，向CTU Farm提供的风险控制服务发送登录事件消息；n 后台Farm在完成用户关键信息变更之后，向前台Farm的用户快照服务发送用户信息变更消息；n CTU Farm在完成交易处理之后，向前台Farm提供的可靠消息通知服务发送通知请求消息；n 论坛Farm在发布帖子之后，向前台Farm提供的沟通服务发送沟通消息。三、Farm内消息通知Farm内消息通知是指由Farm内一台机器上部署的应用构造一条消息，并发送给同一个Farm内另一台机器上的服务进行处理；消息的发送方不等待接收者响应就进行后续处理。之所以需要在一个Farm内引入分布式处理，主要是为了将长时间操作转移到特定的服务器上进行异步执行，以保证负责处理用户交互的服务器有足够的资源快速处理用户请求。Farm内消息通知的典型例子有：n 前台Farm pay服务器向前台Farm paytask服务器提供的沟通服务发送事件通知，实现邮件、短信或IM消息的定制发送；n 后台Farm bops服务器向后台Farm bopstask服务器提供的对账处理服务发送事件通知，实现长时间对账处理的异步执行；n 前台Farm pay服务器向前台Farm paytask服务器提供的用户快照服务发送用户信息变更消息，以异步变更用户快照；四、外部合作服务调用外部合作服务调用指支付宝系统与外部系统之间的相互调用。目前的典型例子有：n 淘宝系统调用支付宝系统创建交易；n 支付宝系统调用淘宝系统通知交易状态变更；n 阿里巴巴调用支付宝系统获得会员信息；n 外部系统调用支付宝外部接口产品；n 淘宝CRM系统调用支付宝CRM系统转发小记。(4) 支付宝系统远程调用技术现状支付宝系统中目前使用的远程调用技术主要有以下几种：一、 直接HTTP/HTTPS这是一种直接通过HTTP协议传递调用参数与返回值的方式。根据参数与返回值的复杂程度不同，这种方式又有以下两种主要变体：参数形式返回值形式例子QuerystringQuerystring淘宝创建交易接口QueryStringXML外部统一接口产品系列其中，QueryString是指下面形式的参数或者值的表示：Key1=value1&key2=value2XML是指下面形式的参数或值的表示： T value1 . . . 直接HTTP/HTTPS接口目前主要的应用场景是：n 外部合作服务调用：如支付宝给淘宝提供的专门接口、支付宝的外部统一接口等。n Farm间服务调用：如银直通服务器调用接口、证书CRL验证服务器接口等。二、 Hessian这是在Spring Remoting框架中集成的一种轻量级、快速的基于HTTP的远程调用服务，来自jetty的开发商caucho。由于Hessian无法支持Alibaba Enum类的序列化（具体原因可参看附录中对Hessian序列化机制的分析），而支付宝系统的数据对象中大量使用Alibaba Enum作为枚举值的类型，因此，目前在支付宝系统较少使用Hessian进行内部系统间的远程调用与消息通知。目前在用的场景主要有：n 支付宝CRM系统与淘宝CRM系统间是使用Hessian方式进行相互间的远程调用。n 支付宝CRM系统与论坛系统之间是使用Hessian方式进行相互间的远程调用。n CTU系统的远程配置服务通过Hessian方式提供。三、 HttpInvoker这是Spring框架中为了解决Hessian对象序列化能力不足，而提供的一种与Hessian类似，但采用标准Java序列化方式的基于HTTP的轻量级远程调用服务。目前，Spring HttpInvoker在支付宝系统中主要用于分布式Mule实例间的消息集成，较少有直接使用Spring HttpInvoker的情况。四、 Mule ESB支付宝系统的各个Farm内部与Farm之间通过Mule进行消息的转换、路由与分发，以实现位置透明与协议透明的基于消息的集成。为了提高系统的可用性，避免性能瓶颈与单故障点，在支付宝系统中Mule实例是分布式部署的，每一个应用服务器实例上都内嵌了一个Mule实例。不同的Mule实例间通过Spring HttpInvoker进行集成。Mule ESB目前在用主要场景有：n 各类应用与可靠通知服务（部署在应用Farm内的paytask服务器上）之间的消息通讯。n 各类应用与沟通服务（部署在应用Farm内的paytask服务器上）之间的消息通讯。n 各类应用与CTU服务（单独一个Farm部署）之间的消息通讯。n 银行查询程序调用银行网关服务的银行意外数据自动恢复服务。五、 XFire web serviceXFire是Codehaus组织提供的一种高效、且较完整的web service实现。它的执行效率比老牌的Apache Axis要快数倍，而且在web service栈的实现完整性上接近Axis 2。XFire的另一个优势是与Spring Remoting框架可以方便集成。XFire目前还未在支付宝生产环境上开始使用，但在两个正在进行的项目中（银行网关独立项目与双证书项目）已经开始运用。2. 远程调用模式如前所述，目前支付宝系统中使用了各种不同的远程调用技术，在选择与运用远程调用技术时存在着较大的麻烦与困惑，亟待有一套统一的规范作为设计与开发的指南。但支付宝系统远程调用规范的制定并不仅仅是在若干候选技术中选择某一种作为系统内部的执行标准。这是因为：n 与远程调用的具体实现技术相比，架构模式产生的影响更大，而且切换一种架构模式带来的重构工作量远远大于切换一种远程调用技术；n 任何技术都有其强项与弱点，没有任何一种技术适用于所有的业务与技术场景；这也是目前市场上存着各种远程调用技术，没有一种能够一统江山的原因所在。因此，在远程调用规范的制定过程中，我们强调要对架构模式进行规范；在技术上不是为整个支付宝系统规定一种方式，而针对各种架构模式与业务场景尽可能统一分别规范远程调用方式，以取得最优的系统特性，并满足业务上的约束。远程调用的目的是实现服务之间的协作。我们在支付宝应用架构中考察服务之间的协作。下图是支付宝的应用架构模型：在支付宝的应用架构模型的指导下，我们可以将之前归纳出来的三种分布式的应用之间的服务协作模式与四种使用场景统一为下图所示的四种形式。n 内部服务导出/导入指从一个应用中将服务通过某种机制导出，在另一个应用中导入该服务。导入/导出机制使远程服务能够像本地服务一样调用，提供了使服务位置透明化。n 异步服务请求指从一个组合异步请求另一个应用提供的服务，但不关心服务执行的结果。在这种情况下，我们使用服务总线作为异步服务请求的代理。n 消息发布/订阅指一个应用中发布标准消息表明系统中发生的业务事件与系统事件，由其它感兴趣的应用订阅并处理该消息。消息的发布与订阅也是通过服务总线进行中介的，以提供消息缓存、转换与路由能力。n 外部合作服务供应为外部系统提供服务。外部合作服务的形式受限于外部服务使用者的技术平台、使用习惯与产品包装上的需要。一般说来，外部合作服务对跨平台、简单性、松耦合性的要求更高。与之前归纳的服务协作模式与使用场景相比，我们将不再区分Farm内的远程调用与Farm间的远程调用，因为这两者在技术实质与业务场景上并无很大不同，强制区分反而引起混淆，而且会由于远程调用技术的不同给部署增加额外的约束。在设计服务协作时，需要根据业务与技术上的约束，在上述四种远程调用模式选择合适的方式进行运用。3. 服务数据规范在支付宝应用架构中，服务数据层（正面左边的一纵）是整个支付宝系统的企业数据模型，它定义了跨产品线需要共享的业务概念，构成了企业业务统一语言中的基本名词，确保了业务之间在数据层面上有统一的语法与语义，是可集成的。一般说来，在一个企业系统中会有三类数据模型，一类是存储在DB中的关系数据模型、一类是通过Java程序表示领域数据模型、一类是服务间传递数据的XML消息数据模型。这三类模型各有所长，各有用武之地。关系数据模型适用于数据的存储与分析、Java领域数据模型适用于业务逻辑处理、XML消息数据模型适用于异构系统中的数据交互，因此在相当长一段时间内，系统中这三类数据模型一定会共存。为了保证不同数据模型之间的语义是一致的，结构是可适配的，在企业系统中，需要规定一个企业级的服务数据模型。可以把它看作是一个数据骨架，作为各种不同数据模型建模的统一基础。根据服务数据模型的角色定位，我们要求服务数据模型具备以下特性：n 与业务一致；服务数据模型是为业务概念建模，而不是为实现细节建模。n 严格性：服务数据模型的定义是严格的，最大程度避免解释与转换中产生歧义。n 高度稳定；服务数据模型必须高度稳定，它的变化会产生较大业务风险，而且也会波及到依赖它的其它数据模型与系统。n 有约束的结构：对服务数据的结构存在一定约束，使得它可以转换为关系模型、对象模型与XML模型；n 精简：尽量保证服务数据层的精简，只将确实需要在全系统中共享的业务概念（比如会员、客户、交易等）放到服务数据层中。n 全局可见：服务数据由于被整个支付宝系统共享，因此需要放到一个全局可见的位置。理想的，服务数据的建模需要一种中立于关系模型、对象模型与XML模型的特殊建模标准，SDO（Service Data Object）就是一种正在兴起的服务数据建模标准，对于这种新技术我们需要关注它。但由于目前支付宝系统的开发仍以Java代码为中心，而且在过去已经积累了大量使用Java代码表示的服务数据。因此，现阶段，服务数据仍需要通过Java对象来建模。为了满足以上特性，对于Java对象建模的服务模型必须建立一些约束。这些约束具体如下 ：(1) 服务数据放在beyond-common-domain这个项目中，分产品建立package。比如会员相关的服务数据放在mon.domain.user中。(2) 服务数据代表业务概念，而不是操作参数/返回值。比如UserInfo，是一个代表用户信息的业务概念，它可以作为服务数据；而QueryAccountBalanceVO是针对账户查询服务的一个操作参数，而不是一个业务概念，它就不应该作为服务数据。(3) 只包含数据，不包含业务操作（俗称的“瘦”领域模型），这是因为不是所有的数据模型都支持操作这一概念。(4) 服务数据的Java类满足以下要求：n 有“空构造器”；n 所有可读的属性都对应可写的属性；举个例子：以下类是不符合服务数据的要求的：package com.alipay.poc.remoting.data.basic;public class User private String name; public User(String name) / 没有无参构造器，不符合要求 super(); = name; public String getName() / 只有get方法，没有对应的set方法，不符合要求 return name; 这个要求是为了方便进行自动数据映射。当需要将服务数据对象从源JVM传递到目的JVM时，需要在目的JVM中重新构造这个对象，并恢复它的状态。满足上述约束条件的Java类可以较方便地自动完成这一过程。(5) 服务数据对象的属性必须也是符合服务数据约束的类型，或者以下基本类型n 基本数据类型：boolean，int，short，double，float，long，charn java.lang中的类型：Character，String，Boolean，Integer，Short，Double，Float，Longn java.util中的类型：Date，Calendarn java.sql中的类型：Date，Time，Timestampn java.math中的类型：BigDecimal，BigIntegern 数组类型n 集合类型n 支付宝基础类型：mon.util.Moneyn 阿里巴巴mon.lang.enumeration.Enum类型与其特定的子类这里特别要说明的是在允许的属性类型中包含了Money类与阿里巴巴Enum类型。这是因为这些类型已经成为支付宝系统中的基本类型，为大家所熟悉，得到了广泛应用。(6) 通过枚举、范型等语言特性，严格地定义数据。举一个例子如下：public class User implements Serializable /* serialVersionUID */ private static final long serialVersionUID = L; /* 用户属性 */ private Map properties; /* * return the properties */ public Map getProperties() return properties; /* * param properties the properties to set */ public void setProperties(Map properties) perties = properties;在这个例子中，properties是一个无约束的Map对象，对于服务数据的使用者，他不知道Map中的key与value是什么类型的。这会为数据映射的生成、数据的解释与使用带来不确定性。假设key与value的属性都必须是String，那应该声明成：public class User implements Serializable /* serialVersionUID */ private static final long serialVersionUID = L; /* 用户属性 */ private Map properties; /* * return the properties */ public Map getProperties() return properties; /* * param properties the properties to set */ public void setProperties(Map properties) perties = properties;(7) 服务数据需要稳定。(8) 服务数据需要精简，只在某条产品线中使用的数据，不要公开到服务数据层。比如CertifyActionContext，这个对象只是认证系统内部使用的数据，就不应该公开到服务数据层。服务数据一般不会直接作为消息或调用参数在系统之间传递，一般会被封装成消息再传递。消息不在beyond-common-domain中进行定义，以免在业务数据上增加大量与业务无关的内容，而是在beyond-common-faade中与服务接口定义在一起。详见服务接口规范。4. 服务接口规范在支付宝应用架构中，业务服务层（正面中间的一行）是整个支付宝系统的企业业务功能模型，它定义了跨产品线共享的业务功能，构成了企业业务统一语言中的基本动词，是业务流程的基本组装单元。服务接口的设计是一门艺术，一个良好建模的服务接口具备以下特点：n 具有清晰、完整的业务含义n 能够在各种业务场景中重用n 具有合适的粒度n 具备稳定性，不会因为业务流程的变化而经常变化n 具备健壮性，能够控制使用不当带来的业务与系统风险n 自描述性强，可以通过接口本身了解服务的使用方式。n 全局可见，可被交互层、流程层与组件层使用。目前业界有两种服务接口的定义方法：一种是“schema优先”的方式，即首先通过WSDL等服务描述语言描述服务接口，再通过工具生成代码；一种是“代码优先”的方式，即首先通过代码（比如Java interface）描述接口，再通过工具生成WSDL。从支付宝系统的现状看，后一种方式在目前阶段更适合。在支付宝系统中，服务接口通过Java接口进行定义，按照业务功能分门别类放到不同的package中，比如：会员相关的服务接口放到mon.facade.user这个package中。接口参数、返回值与消息也在beyond-common-faade这个子项目中定义，一般与服务接口放在一个package中，以便于查看与引用。Java 代码可以在一定程度上将服务的调用方式描述清楚（除了绑定方式，但绑定方式可以通过技术手段做到透明），而服务的业务语义与调用契约目前只有通过注释的方式或者单元测试示例代码的方式描述。对服务接口的注释要严格按照Java doc规范执行，单元测试要能够覆盖到服务的所有接口。5. 协议绑定规范本章中，我们对远程调用时使用的具体技术与协议建立规范。这些规范源自于支付宝团队对各种技术的使用经验。由于不同的远程调用模式有不同的需求，因此我们针对第2章中归纳出来的远程调用模式分别讨论其协议绑定规范。一、内部服务导出/导入在内部服务的导出/导入模式下，我们有以下技术需求：(1) 透明远程调用：对开发人员友好，提供透明的远程调用机制(2) 序列化支持：支持包含符合服务数据规范的数据的参数与返回值的序列化(3) 性能：提供高性能的同步调用能力(4) 松耦合：服务消费者与提供者之间松耦合，能容忍一定程度的服务数据不一致，以及服务部署平台的不一致(5) QoS支持：便于增加高级QoS的支持(6) 发展性：面向标准、面向未来针对这些技术需求，我们对目前已掌握的各种候选技术进行比较：HTTP/HTTPS、Hessian、HttpInvoker、XFire web service。技术需求HTTPHessianHttpInvokerXFire透明远程调用注1不支持支持支持支持序列化支持注2弱强直接序列化对象内部数据，不支持Alibaba Enum（扩展的方便性未知）强支持标准Java序列化，要求调用参数与返回值声明为Serializable。强通过简单配置或扩展能够支持符合服务数据规范的所有数据。性能注3高，可控性强高（约3ms）高（约5ms）中（约20ms）松耦合注4平台无关语言无关框架无关能充分容忍消息格式变化平台无关语言无关框架无关能容忍一定消息格式变化平台无关语言相关(java)框架相关(Spring)很难容忍消息内部格式的变化平台无关语言无关框架无关能较好容忍消息变化QoS支持注5 自行控制自行控制自行控制通过WS-*协议簇提供完整支持，处于不断发展中注1：Spring Remoting框架提供了对Hessian、HttpInvoker与XFire的透明远程调用支持注2：序列化支持的分析与测试详见附录中XFire使用指南、Hessian使用指南与HttpInvoker使用指南中的序列化部分。注3：性能方面的结论来自于本地对于普通大小的消息（附录指南中的TradeService）进行循环测试100次取平均的结果。注4：松耦合性的分析与测试详见附录中XFire使用指南、Hessian使用指南与HttpInvoker使用指南中的序列化部分。注5：XFire目前版本对Web service协议栈的支持见下图所示。从上述比较结果看，各种技术各有所长，在取舍上难度较大。但比较之下，XFire是建立在web service计算模型基础上的，相比于简单的Hessian与HttpInvoker的简单RPC模型，web service要完备许多；对QoS与服务管理，web service协议栈也提供了全面的支持；从性能上说，数十毫秒的往返时间也是可以接受的，但一定要设计好服务的粒度，严格控制单次用户请求中进行远程服务访问的次数；系统间耦合度松。但对于支付宝系统中的高频度服务调用、比如每次证书登录时进行的证书CRL远程验证、银行直通支付等，性能就显得非常重要了。在这种场合下不应该使用XFire web service调用，而应该采用性能更高协议绑定方式。综合上述讨论，在内部服务导出/导入模式下，现阶段的支付宝规范是：n 在大多数应用场合中，使用XFire web service作为内部服务导出/导入模式使用的协议绑定；n XFire web service以“代码优先”的方式开发，从Java接口导入WSDL schema，客户端与服务端共享接口代码；n XFire web service通过Spring Remoting框架与支付宝应用系统进行集成，实现透明远程调用。由通用产品线提供Spring Remoting框架与Webx集成的统一解决方案。n XFire web service使用Aegis XML数据绑定，由通用产品线提供Alibaba Enum类与Money等支付宝基础数据类型的XML绑定扩展。n XFire web service统一通过/service/xfire/*Serivce的URL模式发布。n 对于高响应时间、高频度访问要求的应用场合，不使用XFire web service，而采用性能更高的Hessian协议。n Hessian协议通过Spring Remoting框架与Webx集成，实现透明的远程调用能力。n Hessian协议通过/service/hessian/*Service的URL模式发布。n 在使用Hessian协议时，要求接口参数与返回值中不包含Alibaba Enum，并且保证接口稳定性。n 架构师、系统分析师与开发人员在选择服务接口的协议绑定时，通过充分讨论以取得最佳平衡。二、异步服务请求在异步服务请求模式下，我们有与内部服务导出/导入相似的技术需求：(1) 透明远程调用：对开发人员友好，提供透明的远程调用机制(2) 序列化支持：支持包含符合服务数据规范的数据的参数与返回值的序列化(3) 性能：提供高吞吐量的异步任务执行能力(4) 松耦合：服务消费者与提供者之间松耦合，能容忍一定程度的服务数据不一致，以及服务部署平台的不一致(5) QoS支持：便于增加高级QoS的支持由于异步服务强调吞吐量、可靠性，而不是响应时间，因此，通过Mule ESB进行中介，使服务消费者与服务提供者进一步解耦，并获得ESB提供的本地消息缓存、消息路由、QoS与服务管理等能力。目前支付宝的Mule ESB只能提供基于CommandDispatcher的异步服务请求处理能力，尚无法提供强类型的透明远程调用机制。在通用产品线后续的产品发展中，将会考虑增加这一部分能力，以统一服务同步调用与异步调用的编程模型。ESB实例间的数据传输协议由通用产品线内部控制，由于对应用开发是透明的，在此不作规定。综合上述讨论，在异步服务请求模式下，现阶段的支付宝规范是：n 异步服务请求通过CommandDispatcher接口进行调用，由通用产品线提供CommandDispatcher与ESB连接的具体实现类。n 服务提供方提供AO对业务服务接口进行封装，在AO中处理Command与Result的打包与解包，并调用真正的服务接口。n 异步服务请求以Command的形式作为消息载荷在ESB中流转。n 对Command载荷的数据要求与内部服务导出/导入模式相同。n ESB实例间的连接协议由通用产品线进行规定，对外部调用者不可见。由此可见，目前通过ESB进行异步服务请求还是比较麻烦的，在没有现成AO的情况下，可能需要开发一个额外的客户端与AO，而且失去了编译器与IDE的类型检查支持与内容帮助功能。这方面有待通用产品线进行改进。三、消息发布/订阅在消息发布/订阅模式下，我们有以下技术需求：(1) 序列化支持：支持包含符合服务数据规范的数据的参数与返回值的序列化(2) 消息转换支持能够在服务消费者与提供者之间进行消息格式与内容的转换(3) 消息路由支持能够在服务消费者与提供者之间进行消息路由，将消息从发布者派发到感兴趣的订阅者(4) 性能：提供高吞吐量的异步消息转换与路由能力(5) 高度松耦合：服务消费者与提供者之间高度松耦合，服务消费者不需要知道存在哪些服务提供者，更不需要了解它们的接口是什么。(6) QoS支持：便于增加高级QoS的支持(7) 统一消息发布接口：系统提供统一的消息发布接口(8) 高级需求：提供动态消息订阅、可配置转换与路由逻辑的能力消息发布/订阅模式能够大大降低目前支付宝系统不同模块之间的耦合度，降低应用逻辑的复杂性。但这种模式超越了现在ESB的使用模式，在技术提出了较大的挑战。因此，相关的规范有待相关产品线进行探索。消息发布/订阅模式的挑战不仅仅在于ESB，更大的挑战在于规范各个应用模块发布与订阅的消息数据，理清它们之间的消息发布/订阅关系，而这需要对业务模型进行深入的分析与抽象。四、外部合作服务供应外部合作服务供应模式的技术需求与内部系统的技术需求相比，存在着较大差异：(1) 开放支持所有平台与所有语言(2) 易用方便商户集成(3) 安全确保用户只能访问符合商业规则的数据与功能，确保数据的完整性与不可否认性(4) 稳定接口规范一旦发布，必须很稳定，如果要扩展，也必须保证向下兼容(5) 可管理业务部门可以直接管理外部接口的访问规则在这种技术需求下，无论是Hessian、HttpInvoker还是Mule ESB都不是可行的选择了，只有HTTP/HTTPS与Web service可以考虑。目前支付宝系统已经提供了一套无论从技术层面还是产品层面都较完善的基于HTTPS的统一外部接口规范，这个外部接口将是支付宝系统外部合作服务供应的主要接口形式，所有新的外部合作需求都需要纳入到统一外部接口规范中进行管理。在统一外部接口规范出现之前遗留了一些外部接口，这些接口目前也工作得相对稳定，因此它们也会继续存在一段时间。随着支付宝未来服务领域的拓展与服务层次的加深，可能会出现提供web service接口的需求，以支持复杂的数据与功能交互模式。在这种情况下，XFire web service是一个不错的候选技术。但针对外部合作服务的web service开发，需要采用schema优先的方式，而不是代码优先的方式，以提供更严格、更规范、更友好的服务schema以及更加松耦合的客户端与服务端代码。阿里巴巴公司旗下网站之间的集成，只要是纳入外部接口产品进行管理的，也作为外部合作服务看待，遵循统一外部接口规范。对于纯技术的集成，建议使用XFire web service，在保证松耦合的同时提高开发的效率与质量。6. QoS规范一、安全在现阶段，内部的远程调用使用内部端口，Spring Remoting框架下可以直接使用应用服务器的7001端口，Mule实例间的集成使用5200。通过防火墙配置保证远程调用只在局域网内可用。在现阶段，服务提供者与服务消费者之间不进行相互间的身份认证；内部的远程调用传输的数据不进行加密。但关键的用户数据（比如明文用户密码）不出现在数据中；内部的远程调用传输的数据不使用签名机制来保证数据完整性。未来在增加身份认证、数据加密与签名的支持时，优先考虑使用web service协议栈的直接支持。二、负载平衡远程调用走HTTP协议，通过F5提供负载平衡。三、故障切换远程调用走HTTP协议，通过F5提供健康检查与故障切换。四、故障隔离为了避免远程服务提供者的故障波及到服务消费者，发生连锁反应，在所有的远程调用点都需要考虑故障隔离。目前支付宝系统中的故障隔离主要有两种方式：n 受限资源方式：限制特定功能可同时占用的线程资源数n 超时设置：合理设置远程调用的超时在实际应用中，这两者往往同时使用。五、可靠性在需要接近100%的可靠消息通知或者可靠任务执行的场合，可以使用支付宝的通知服务器产品，但代价较大，需要产品owner进行讨论以决定是否使用。由于远程调用的成功率受网络、服务器稳定性的影响较大，因此，如果不需要100%的可靠性，可以在应用中自行加入失败后立即重试一到两次的逻辑，但服务提供方一定要注意保证多次调用情况下不会出现重复执行业务逻辑。如果出现这种情况，后果会很严重。未来会在ESB产品中提供一种相对代价较小的可靠消息传递机制，以满足大多数场合下的可靠性要求。7. 待解决问题本章中提出一些目前尚未有结论的问题，请大家一起探索合适的解决方案。一、服务的版本如何升级？如何在不停止服务的基础上对服务的版本进行升级？二、测试环境下如何管理已部署的不同版本的服务？测试环境下，同一个服务会有处在不同开发分支上的多个版本，如何有效进行管理？三、服务提供者需要回调服务消费者时，如何定位到服务消费者？这种服务请求-回调模式目前没有纳入到之前归纳的远程调用模式中，因为现在请求-回调是看作两次不同的请求来实现的。但如果回调时要求被调用方就是调用的发起方，就需要不同的技术了。如何实现服务请求-回调模式？四、分布式服务间如何实现事务？如何确保发生在分布式系统上的业务操作集合满足业务一致性的要求？ 五、如何管理远程服务的SLA？8. 附录 XFire使用指南(1) 一个基本的XFire web service在本节中，我们构建一个基本的XFire web service服务端与客户端，并借助这个例子解释XFire的基本原理。一、建立基本的web测试项目在这一步中，我们将使用antx建立一个测试项目alipay-remoting，并将该项目导入到eclipse中。假设工作目录为d:workstudy，开启一个命令行窗口，并执行以下命令：d： / 切换到d:盘cd d:workstudy / 进入到d:盘的工作目录 d:workstudymkdir alipay-remoting / 建立项目alipay-remoting的目录cd alipay-remoting / 进入项目