支付宝远程挪用标准.docx
《支付宝远程挪用标准.docx》由会员分享，可在线阅读，更多相关《支付宝远程挪用标准.docx（32页珍藏版）》请在冰豆网上搜索。
支付宝远程挪用标准
支付宝远程挪用标准
版
1.现状分析
本章以支付宝系统的架构为上下文，分析目前支付宝系统中的效劳协作模式、远程挪用处景与远程挪用技术现状。
对现状的分析是改良并形成标准的基础。
（1）支付宝系统架构概述
为了知足互联网金融效劳系统的快速转变与高度稳固的要求，支付宝系统的架构需要向面向效劳架构迁移。
面向效劳的支付宝系统架构如以下图所示：
不同类型的效劳对部署提出了不同的要求。
比如交互效劳要求公网可访问、能够快速转变；核心的业务功能效劳那么要求稳固、具有海量吞吐能力；外部合作效劳可能要求提供特殊的网络访问方式，需要包括外部效劳商的提供的类库、文件与配置等等。
由不同的效劳有不同部署要求，因此支付宝系统必需采纳进行散布式部署，通过散布式效劳间的协作实现业务流程。
为了支撑高度可用的效劳协作网络，支付宝系统采纳了以效劳farm为大体单元的部署架构。
每一个farm是一个相对独立由多台物理机械组成的高可用集群，用于支撑一组部署要求相近、彼其间耦合紧密的效劳。
farm之间是松耦合的，它们具有不同的效劳功能、发布策略、治理策略与软硬件基础。
这种基于farm的部署架构如以下图所示：
关于支撑高度复杂应用的Farm，如前台Farm、后台Farm，其内部还有不同效劳器的分工。
比如前台Farm的结构如下：
（2）支付宝效劳协作模式
在对支付宝系统的逻辑架构与部署架构进行了论述以后，咱们得知支付宝系统以后的进展方向是拆分成相对独立的各类效劳，而且散布部署在不同的Farm和Farm中的不同效劳器之间。
散布部署的效劳间如何进行协作以实现高度复杂的业务流程？
在本节中，咱们探讨支付宝系统中经常使用的几种服务协作模式。
在以后的系统设计中，将尽可能采纳标准化的效劳协作模式。
一、效劳请求-响应模式
这是最简单的效劳协作模式。
一方是效劳的消费者，一方是效劳的提供者，效劳的消费者向效劳提供者发出效劳请求，效劳提供者进行效劳逻辑处置，并返回给效劳提供者处置的结果。
效劳消费者依照结果进行后续处置。
效劳请求-响应模式是一种点对点的访问模式。
当两个系统间的效劳交互比较简单时，这是一种简单有效的方式。
当系统中效劳愈来愈多以后，会形成一个复杂的效劳提供-消费网络，给治理带来专门大的挑战。
而且，散布式效劳间以同步方式进行远程挪用会付出必然的性能与靠得住性本钱。
因此，在对业务流程进行效劳分解与效劳分解时，要慎用这种方式，多考虑有无其它替代方案，操纵好点对点效劳请求-响应的利用范围。
在支付宝系统中，效劳请求-响应模式的典型应用处景例如：
⏹用户利用证书登录时，挪用证书核心效劳进行CRL验证，并依照验证结果决定用户登录后具有的角色；
⏹银行网关在完成银行定单反馈确认与资金入账以后，请求前台应用进行业务分流处置，并依照业务分流的结果跳转到前台系统的特定页面；
⏹淘宝系统挪用支付宝系统创建交易定单；
二、异步效劳请求模式
这也是一种简单的效劳协作模式。
效劳的消费者向效劳提供者发出效劳请求，然后不等待效劳提供者处置完成，就进行后续处置。
效劳提供者自主地进行效劳请求的业务处置，而且不返回结果给效劳提供者。
为了使效劳提供者的处置压力更滑腻，提供处置的吞吐量，在效劳消费者与效劳提供者之间，一样通过ESB进行消息缓存与中转。
加入ESB以后的应用模式如以下图所示：
目前在支付宝系统中利用的异步效劳请求模式大体上都是后一种通过ESB进行中介的模式。
支付宝系统中异步效劳请求模式的应用处景例如：
⏹支付宝后台Farm中的bops效劳器挪用bopstask效劳器进行长时刻的对账处置；
⏹支付宝银行按时查询程序挪用银行网关效劳器进行自动意外数据恢复；
⏹支付宝应用挪用靠得住通知效劳器进行当即通知发送；
在异步效劳请求模式，效劳的消费者是成心识挪用效劳的，也明确知晓效劳提供者的挪用方式与效劳语义。
因此，尽管异步方式使效劳消费者与效劳提供者在系统层面的耦合度更松，但在逻辑层面，两边仍是具有耦合性的，当效劳提供者的效劳语义发生转变，或挪用接口发生转变，效劳消费者也需要同时修改程序。
因此，在进行面向效劳分析与设计时，也需要考虑是不是有更好的替代方案，幸免过量的点对点直接异步效劳请求将使系统的拓扑成为难以治理的网络。
三、消息发布-定阅模式
基于消息发布与定阅模式的效劳协作模式是一种松耦合的效劳协作模式。
在这种模式下，没有静态绑定的效劳消费者与效劳提供者关系存在，而是由消息总线依照业务集成逻辑，自动将效劳消费者产生的消息转换并路由给多个感爱好的效劳提供者。
由于这种模式相对复杂，咱们举一个例子加以说明。
假设消息发布者是交易系统。
它在处置完交易以后发布出一个标准消息，其中包括本次交易处置的结果，和交易的要紧情形。
发布完消息以后，交易系统进行后续处置。
ESB系统收到标准交易消息以后，依照配置进行消息的转换与分发：
它将消息转换为沟通系统接收的消息格式，派发给沟通系统进行用户沟通（邮件、短信、IM的定制发送）；它将消息转换为CTU系统要求的消息格式，派发给CTU系统进行风险审核；它将消息转换为靠得住消息通知效劳器要求的消息格式，派发给通知效劳器进行商户的交易状态通知。
由于运用了消息发布-定阅模式，交易系统就再也不需要明白沟通效劳、CTU效劳与靠得住通知效劳接口的语义与挪用方式了，乃至不需要明白存在这种系统，完全由消息总线通过配置或相对少量的编码工作完成效劳间的协作工作。
以后再需要增加新的消息定阅者，比如收费效劳，交易系统仍不需转变。
消息发布-定阅模式目前在支付宝系统中尚未取得运用，但由于ESB总线作为基础设施已经搭建完成，业务效劳之间的关系也正在渐渐理顺，因此有机遇将目前存在的很多异步消息请求模式转换为消息发布-定阅模式，降低支付宝系统的效劳之间耦合性。
在进行面向效劳的分析与设计时，建议尽可能运用这种模式解决业务流程中效劳的协作问题。
（3）支付宝远程挪用利用场景
在本节中，咱们归纳支付宝系统中目前经常使用的远程挪用场景。
这些场景不是一个穷举的清单，而是尽可能只列举有实际应用价值的场景；关于一些以后有效但此刻尚未分析清楚的远程挪用处景，本列表也未包括，比如Farm间消息广播等，这些将在后续的工作中进行探讨与改良。
应用场景
消费者
调用模式
场所
Farm间服务调用
内部系统
请求-响应
Farm间
Farm间消息通知
内部系统
只请求
Farm间
Farm内消息通知
内部系统
只请求
Farm内
外部合作服务调用
外部系统
请求-响应
跨防火墙
一、Farm间效劳挪用
Farm间效劳挪用是指由一个Farm中部署的应用请求另一个Farm中部署的效劳，而且等待取得返回结果以后，再进行后续处置。
Farm间效劳挪用的典型例子有：
⏹前台Farm处置证书登录时，挪用数据证书核心Farm检查CRL；
⏹银行网关Farm处置网银支付结果时，挪用前台Farm提供的业务分流效劳（即将改造成这种形式）；
⏹银行网关Farm处置卡通支付时，挪用核心银直通效劳器提供的银行直通效劳（即将改造成这种形式）。
⏹CTUFarm在处置充值退回时，挪用后台Farm的充值退回效劳；
二、Farm间消息通知
Farm间消息通知是指由一个Farm中部署的应用构造一条消息，并发送给另一个Farm中的效劳；消息的发送方不等待接收者响应就进行后续处置。
Farm间消息通知的典型例子有：
⏹前台Farm在完成用户登录处置以后，向CTUFarm提供的风险操纵效劳发送登录事件消息；
⏹后台Farm在完成用户关键信息变更以后，向前台Farm的用户快照效劳发送用户信息变更消息；
⏹CTUFarm在完成交易处置以后，向前台Farm提供的靠得住消息通知效劳发送通知请求消息；
⏹论坛Farm在发布帖子以后，向前台Farm提供的沟通效劳发送沟通消息。
三、Farm内消息通知
Farm内消息通知是指由Farm内一台机械上部署的应用构造一条消息，并发送给同一个Farm内另一台机械上的效劳进行处置；消息的发送方不等待接收者响应就进行后续处置。
之因此需要在一个Farm内引入散布式处置，主若是为了将长时刻操作转移到特定的效劳器上进行异步执行，以保证负责处置用户交互的效劳器有足够的资源快速处置用户请求。
Farm内消息通知的典型例子有：
⏹前台Farmpay效劳器向前台Farmpaytask效劳器提供的沟通效劳发送事件通知，实现邮件、短信或IM消息的定制发送；
⏹后台Farmbops效劳器向后台Farmbopstask效劳器提供的对账处置效劳发送事件通知，实现长时刻对账处置的异步执行；
⏹前台Farmpay效劳器向前台Farmpaytask效劳器提供的用户快照效劳发送用户信息变更消息，以异步变更用户快照；
四、外部合作效劳挪用
外部合作效劳挪用指支付宝系统与外部系统之间的彼此挪用。
目前的典型例子有：
⏹淘宝系统挪用支付宝系统创建交易；
⏹支付宝系统挪用淘宝系统通知交易状态变更；
⏹阿里巴巴挪用支付宝系统取得会员信息；
⏹外部系统挪用支付宝外部接口产品；
⏹淘宝CRM系统挪用支付宝CRM系统转发小记。
（4）支付宝系统远程挪用技术现状
支付宝系统中目前利用的远程挪用技术要紧有以下几种：
一、直接HTTP/HTTPS
这是一种直接通过HTTP协议传递挪用参数与返回值的方式。
依照参数与返回值的复杂程度不同，这种方式又有以下两种要紧变体：
参数形式
返回值形式
例子
Querystring
Querystring
淘宝创建交易接口
QueryString
XML
外部统一接口产品系列
其中，QueryString是指下面形式的参数或值的表示：
Key1=value1&key2=value2
XML是指下面形式的参数或值的表示：
xmlversion=""encoding="GBK"?
>
T
value1
...
...
...
直接HTTP/HTTPS接口目前要紧的应用处景是：
⏹外部合作效劳挪用：
⏹如支付宝给淘宝提供的专门接口、支付宝的外部统一接口等。
⏹Farm间效劳挪用：
⏹如银直通效劳器挪用接口、证书CRL验证效劳器接口等。
二、Hessian
这是在SpringRemoting框架中集成的一种轻量级、快速的基于HTTP的远程挪用效劳，来自jetty的开发商caucho。
由于Hessian无法支持AlibabaEnum类的序列化（具体缘故可参看附录中对Hessian序列化机制的分析），而支付宝系统的数据对象中大量利用AlibabaEnum作为列举值的类型，因此，目前在支付宝系统较少利用Hessian进行内部系统间的远程挪用与消息通知。
目前在用的场景要紧有：
⏹支付宝CRM系统与淘宝CRM系统间是利用Hessian方式进行彼其间的远程挪用。
⏹支付宝CRM系统与论坛系统之间是利用Hessian方式进行彼其间的远程挪用。
⏹CTU系统的远程配置效劳通过Hessian方式提供。
三、HttpInvoker
这是Spring框架中为了解决Hessian对象序列化能力不足，而提供的一种与Hessian类似，但采纳标准Java序列化方式的基于HTTP的轻量级远程挪用效劳。
目前，SpringHttpInvoker在支付宝系统中要紧用于散布式Mule实例间的消息集成，较少有直接利用SpringHttpInvoker的情形。
四、MuleESB
支付宝系统的各个Farm内部与Farm之间通过Mule进行消息的转换、路由与分发，以实现位置透明与协议透明的基于消息的集成。
为了提高系统的可用性，幸免性能瓶颈与单故障点，在支付宝系统中Mule实例是散布式部署的，每一个应用效劳器实例上都内嵌了一个Mule实例。
不同的Mule实例间通过SpringHttpInvoker进行集成。
MuleESB目前在用要紧场景有：
⏹各类应用与靠得住通知效劳（部署在应用Farm内的paytask效劳器上）之间的消息通信。
⏹各类应用与沟通效劳（部署在应用Farm内的paytask效劳器上）之间的消息通信。
⏹各类应用与CTU效劳（单唯一个Farm部署）之间的消息通信。
⏹银行查询程序挪用银行网关效劳的银行意外数据自动恢复效劳。
五、XFirewebservice
XFire是Codehaus组织提供的一种高效、且较完整的webservice实现。
它的执行效率比老牌的ApacheAxis要快数倍，而且在webservice栈的实现完整性上接近Axis2。
XFire的另一个优势是与SpringRemoting框架能够方便集成。
XFire目前还未在支付宝生产环境上开始利用，但在两个正在进行的项目中（银行网关独立项目与双证书项目）已经开始运用。
2.远程挪用模式
如前所述，目前支付宝系统中利用了各类不同的远程挪用技术，在选择与运用远程挪用技术时存在着较大的麻烦与困惑，亟待有一套统一的标准作为设计与开发的指南。
但支付宝系统远程挪用标准的制定并非仅仅是在假设干候选技术当选择某一种作为系统内部的执行标准。
这是因为：
⏹与远程挪用的具体实现技术相较，架构模式产生的阻碍更大，而且切换一种架构模式带来的重构工作量远远大于切换一种远程挪用技术；
⏹任何技术都有其强项与弱点，没有任何一种技术适用于所有的业务与技术场景；这也是目前市场上存着各类远程挪用技术，没有一种能够一统江山的缘故所在。
因此，在远程挪用标准的制定进程中，咱们强调要对架构模式进行标准；在技术上不是为整个支付宝系统规定一种方式，而针对各类架构模式与业务场景尽可能统一别离标准远程挪用方式，以取得最优的系统特性，并知足业务上的约束。
远程挪用的目的是实现效劳之间的协作。
咱们在支付宝应用架构中考察效劳之间的协作。
以下图是支付宝的应用架构模型：
在支付宝的应用架构模型的指导下，咱们能够将之前归纳出来的三种散布式的应用之间的效劳协作模式与四种利用场景统一为以下图所示的四种形式。
⏹内部效劳导出/导入
⏹指从一个应用中将效劳通过某种机制导出，在另一个应用中导入该效劳。
导入/导出机制使远程效劳能够像本地效劳一样挪用，提供了使效劳位置透明化。
⏹异步效劳请求
⏹指从一个组合异步请求另一个应用提供的效劳，但不关切效劳执行的结果。
在这种情形下，咱们利用效劳总线作为异步效劳请求的代理。
⏹消息发布/定阅
⏹指一个应用中发布标准消息说明系统中发生的业务事件与系统事件，由其它感爱好的应用定阅并处置该消息。
消息的发布与定阅也是通过效劳总线进行中介的，以提供消息缓存、转换与路由能力。
⏹外部合作效劳供给
⏹为外部系统提供效劳。
外部合作效劳的形式受限于外部效劳利用者的技术平台、利用适应与产品包装上的需要。
一样说来，外部合作效劳对跨平台、简单性、松耦合性的要求更高。
与之前归纳的效劳协作模式与利用处景相较，咱们将再也不区分Farm内的远程挪用与Farm间的远程挪用，因为这二者在技术实质与业务场景上并无专门大不同，强制区分反而引发混淆，而且会由于远程挪用技术的不同给部署增加额外的约束。
在设计效劳协作时，需要依照业务与技术上的约束，在上述四种远程挪用模式选择适合的方式进行运用。
3.效劳数据标准
在支付宝应用架构中，效劳数据层（正面左侧的一纵）是整个支付宝系统的企业数据模型，它概念了跨产品线需要共享的业务概念，组成了企业业务统一语言中的大体名词，确保了业务之间在数据层面上有统一的语法与语义，是可集成的。
一样说来，在一个企业系统中会有三类数据模型，一类是存储在DB中的关系数据模型、一类是通过Java程序表示领域数据模型、一类是效劳间传递数据的XML消息数据模型。
这三类模型各有所长，各有效武之地。
关系数据模型适用于数据的存储与分析、Java领域数据模型适用于业务逻辑处置、XML消息数据模型适用于异构系统中的数据交互，因此在相当长一段时刻内，系统中这三类数据模型必然会共存。
为了保证不同数据模型之间的语义是一致的，结构是可适配的，在企业系统中，需要规定一个企业级的效劳数据模型。
能够把它看做是一个数据骨架，作为各类不同数据模型建模的统一基础。
依照效劳数据模型的角色定位，咱们要求效劳数据模型具有以下特性：
⏹与业务一致；
⏹效劳数据模型是为业务概念建模，而不是为实现细节建模。
⏹严格性：
⏹效劳数据模型的概念是严格的，最大程度幸免说明与转换中产生歧义。
⏹高度稳固；
⏹效劳数据模型必需高度稳固，它的转变会产生较大业务风险，而且也会涉及到依托它的其它数据模型与系统。
⏹有约束的结构：
⏹对效劳数据的结构存在必然约束，使得它能够转换为关系模型、对象模型与XML模型；
⏹精简：
⏹尽可能保证效劳数据层的精简，只将确实需要在全系统中共享的业务概念（比如会员、客户、交易等）放到效劳数据层中。
⏹全局可见：
⏹效劳数据由于被整个支付宝系总共享，因此需要放到一个全局可见的位置。
理想的，效劳数据的建模需要一种中立于关系模型、对象模型与XML模型的特殊建模标准，SDO（ServiceDataObject）确实是一种正在兴起的效劳数据建模标准，关于这种新技术咱们需要关注它。
但由于目前支付宝系统的开发仍以Java代码为中心，而且在过去已经积存了大量利用Java代码表示的效劳数据。
因此，现时期，效劳数据仍需要通过Java对象来建模。
为了知足以上特性，关于Java对象建模的效劳模型必需成立一些约束。
这些约束具体如下：
（1）效劳数据放在beyond-common-domain那个项目中，分产品成立package。
比如会员相关的效劳数据放在中。
（2）效劳数据代表业务概念，而不是操作参数/返回值。
比如UserInfo，是一个代表用户信息的业务概念，它能够作为效劳数据；而QueryAccountBalanceVO是针对账户查询效劳的一个操作参数，而不是一个业务概念，它就不该该作为效劳数据。
（3）只包括数据，不包括业务操作（俗称的“瘦”领域模型），这是因为不是所有的数据模型都支持操作这一概念。
（4）效劳数据的Java类知足以下要求：
⏹有“空构造器”；
⏹所有可读的属性都对应可写的属性；
举个例子：
以下类是不符合效劳数据的要求的：
packageclassUser{
privateStringname;
publicUser（Stringname）{
1.2.31.0.12.1.02.0.11.5.1/DTDWebApplication/EN"
"">
--概念XFireServlet-->
XFireServlet
--将匹配/services/xfire/*的URL请求映射到XFireServlet来处置-->
XFireServlet
/services/xfire/*
以上两个文件的位置如以下图所示：
五、通过Jboss部署XFirewebservice
本节中，咱们将通过以上步骤构建的XFirewebservice部署到一个应用效劳器容器中，选用的应用效劳器容器是jboss-4.0.4GA。
第一，为了幸免部署的应用阻碍日常的开发与部署，咱们成立一个单独的部署server环境，该环境从defaultserver复制取得，如以下图所示：
接下来，咱们编辑test目录下的conf/，找到MBean“:
type=DeploymentScanner,flavor=URL”的配置中的段，进行如下修改，红色加粗部份为新加的部署URL：
原：
deploy/
修改成：
deploy/,file:
/d:
/work/study/alipay-remoting/target/
接下来，执行以下命令即可启动jboss。
cdd:
\work\study\alipay-remoting
/DTDWebApplication/EN"
"">
--Springwebapplicationcontext的配置参数-->
contextConfigLocation
classpath:
/
classpath:
org/codehaus/xfire/spring/
--加载Springwebapplicationcontext的Listener-->
--概念XFireServlet-->
XFireServlet
--概念SpringDispatcherServlet，将那个Servlet命名为SpringRemotingServlet，以后能够通过它进一步测试其它各类类型的Spring远程挪用机制-->
SpringRemotingServlet
--将匹配/services/xfire/*的URL请求映射到XFireServlet来处置-->
XFireServlet
/services/xfire/*
--将匹配/services/spring/xfire/*的URL请求映射到SpringRemotingServlet来处置-->
SpringRemotingServlet
/se
升级会员 