支付宝远程调用规范 - read.doc

支付宝远程调用规范 0.1版 现状分析 本章以支付宝系统的架构为上下文，分析目前支付宝系统中的服务协作模式、远程调用场景与远程调用技术现状。对现状的分析是改进并形成规范的基础。 支付宝系统架构概述 为了满足互联网金融服务系统的快速变化与高度稳定的要求，支付宝系统的架构需要向面向服务架构迁移。面向服务的支付宝系统架构如下图所示： 不同类型的服务对部署提出了不同的要求。比如交互服务要求公网可访问、可以快速变化；核心的业务功能服务则要求稳定、具有海量吞吐能力；外部合作服务可能要求提供特殊的网络访问方式，需要包含外部服务商的提供的类库、文件与配置等等。由不同的服务有不同部署要求，因此支付宝系统必须采用进行分布式部署，通过分布式服务间的协作实现业务流程。 为了支撑高度可用的服务协作网络，支付宝系统采用了以服务farm为基本单元的部署架构。每一个farm是一个相对独立由多台物理机器组成的高可用集群，用于支撑一组部署要求相近、相互间耦合紧密的服务。farm之间是松耦合的，它们具有不同的服务功能、发布策略、管理策略与软硬件基础。这种基于farm的部署架构如下图所示： 对于支撑高度复杂应用的Farm，如前台Farm、后台Farm，其内部还有不同服务器的分工。比如前台Farm的结构如下： 支付宝服务协作模式 在对支付宝系统的逻辑架构与部署架构进行了阐述之后，我们得知支付宝系统未来的发展方向是拆分成相对独立的各类服务，并且分布部署在不同的Farm以及Farm中的不同服务器之间。 分布部署的服务间如何进行协作以实现高度复杂的业务流程？在本节中，我们探讨支付宝系统中常用的几种服务协作模式。在未来的系统设计中，将尽可能采用标准化的服务协作模式。 一、服务请求-响应模式 这是最简单的服务协作模式。一方是服务的消费者，一方是服务的提供者，服务的消费者向服务提供者发出服务请求，服务提供者进行服务逻辑处理，并返回给服务提供者处理的结果。服务消费者根据结果进行后续处理。 服务请求-响应模式是一种点对点的访问模式。当两个系统间的服务交互比较简单时，这是一种简单有效的方式。当系统中服务越来越多之后，会形成一个复杂的服务提供-消费网络，给管理带来很大的挑战。而且，分布式服务间以同步方式进行远程调用会付出一定的性能与可靠性成本。因此，在对业务流程进行服务分解与服务分解时，要慎用这种方式，多考虑有无其它替代方案，控制好点对点服务请求-响应的使用范围。 在支付宝系统中，服务请求-响应模式的典型应用场景例如： 用户使用证书登录时，调用证书核心服务进行CRL验证，并根据验证结果决定用户登录后具有的角色； 银行网关在完成银行订单反馈确认与资金入账之后，请求前台应用进行业务分流处理，并根据业务分流的结果跳转到前台系统的特定页面； 淘宝系统调用支付宝系统创建交易订单； 二、异步服务请求模式 这也是一种简单的服务协作模式。服务的消费者向服务提供者发出服务请求，然后不等待服务提供者处理完成，就进行后续处理。服务提供者自主地进行服务请求的业务处理，并且不返回结果给服务提供者。 为了使服务提供者的处理压力更平滑，提供处理的吞吐量，在服务消费者与服务提供者之间，一般通过ESB进行消息缓存与中转。加入ESB之后的应用模式如下图所示： 目前在支付宝系统中使用的异步服务请求模式基本上都是后一种通过ESB进行中介的模式。 支付宝系统中异步服务请求模式的应用场景例如： 支付宝后台Farm中的bops服务器调用bopstask服务器进行长时间的对账处理； 支付宝银行定时查询程序调用银行网关服务器进行自动意外数据恢复； 支付宝应用调用可靠通知服务器进行立即通知发送； 在异步服务请求模式，服务的消费者是有意识调用服务的，也明确知晓服务提供者的调用方法与服务语义。因此，尽管异步方式使服务消费者与服务提供者在系统层面的耦合度更松，但在逻辑层面，双方还是具有耦合性的，当服务提供者的服务语义发生变化，或者调用接口发生变化，服务消费者也需要同时修改程序。因此，在进行面向服务分析与设计时，也需要 考虑是否有更好的替代方案，避免过多的点对点直接异步服务请求将使系统的拓扑成为难以管理的网络。 三、消息发布-订阅模式 基于消息发布与订阅模式的服务协作模式是一种松耦合的服务协作模式。在这种模式下，没有静态绑定的服务消费者与服务提供者关系存在，而是由消息总线根据业务集成逻辑，自动将服务消费者产生的消息转换并路由给多个感兴趣的服务提供者。 由于这种模式相对复杂，我们举一个例子加以说明。假设消息发布者是交易系统。它在处理完交易之后发布出一个标准消息，其中包含本次交易处理的结果，以及交易的主要情况。发布完消息之后，交易系统进行后续处理。ESB系统收到标准交易消息之后，根据配置进行消息的转换与分发：它将消息转换为沟通系统接收的消息格式，派发