付钱拉_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
&&“付钱拉”是一款为成长型企业提供支付接入服务的产品。通过接入“付钱拉”,可在用户支付环节接入Apple Pay、支付宝、微信、百度、京东、易宝、快钱、银联等支付通道完成收款,同时配套提供订单管理、运营管理、7*24小时自动化运维、风控监测等增值服务。
阅读已结束，下载文档到电脑
想免费下载本文？
定制HR最喜欢的简历
你可能喜欢从0到1解析「付钱拉」支付系统架构丨内有福利
本文以「付钱拉」后台支付系统为背景，是「付钱拉」支付系统架构系列的第一篇文章，旨在剖析其总体架构实践。本文主要抛砖引玉，简要分析「付钱拉」的架构设计理念。
「付钱拉」支付系统每天平均处理订单量100w-200w笔，账单交易日交易量在300万笔以上、每个月处理支付交易流水在300亿左右、对接银行和三方有30多家以及接入商户几千个。从刚开始系统仅仅处于能用阶段，日交易量几千笔到现在，系统架构根据业务的不断发展迭代多个阶段。主要从以下几个方面来分享：
对于互联网应用和企业大型应用而言，多数都尽可能地要求做到7*24小时不间断运行，而要做到完全的不间断运行可以说“难于上青天”。
为此，对应用的可用性程度一般衡量标准有三个9到五个9。
可用性指标
不可用时间（分钟）
0.1%*365*24*60
0.01%*365*24*60
0.001%*365*24*60
对于一个功能和数据量不断增加的应用，要保持比较高的可用性并非易事。为了实现高可用，「付钱拉」从避免单点故障、保证应用自身的高可用、解决交易量增长等方面做了许多探索和实践。
在不考虑外部依赖系统突发故障，如网络问题、三方支付和银行的大面积不可用等情况下，「付钱拉」的服务能力可以达到99.999%。
为了提高应用的可用性，首先要做的就是尽可能避免应用出现故障，但要完全做到不出故障是不可能的。互联网是个容易产生“蝴蝶效应”的地方，任何一个看似很小的、发生概率为0的事故都可能出现，然后被无限放大。
大家都知道RabbitMQ本身是非常稳定可靠的，「付钱拉」最开始也一直在使用单点RabbitMQ，并且从未出现运行故障，所以大家在心理上都认为这个东西不太可能出问题。
直到某天，这台节点所在的物理主机硬件因为年久失修坏掉了，当时这台RabbitMQ就无法提供服务，导致系统服务瞬间不可用。
故障发生了也不可怕，最重要的是及时发现并解决故障。「付钱拉」对自身系统的要求是，秒级发现故障，快速诊断和解决故障，从而降低故障带来的负面影响。
首先我们简单的回顾一下，「付钱拉」曾经碰到的一些问题：
【以史为鉴】
新来的开发同事在处理新接入的三方通道时，由于经验不足忽视了设置超时时间的重要性。就是这样一个小小的细节，导致这个三方队列所在的交易全部堵塞，同时影响到其他通道的交易。
「付钱拉」系统是分布式部署的，并且支持灰度发布，所以环境和部署模块非常多而且复杂。某次增加了一个新模块，由于存在多个环境，且每个环境都是双节点，新模块上线后导致数据库的连接数不够用，从而影响其他模块功能。
同样是超时问题，一个三方的超时，导致耗尽了当前所配置的所有worker threads, 以至于其他交易没有可处理的线程。
A三方同时提供鉴权，支付等接口，其中一个接口因为「付钱拉」交易量突增，从而触发A三方在网络运营商那边的DDoS限制。通常机房的出口IP都是固定的，从而被网络运营商误认为是来自这个出口IP的交易是流量攻击，最终导致A三方鉴权和支付接口同时不可用。
再说一个数据库的问题，同样是因为「付钱拉」交易量突增引发的。建立序列的同事给某个序列的上限是999，999，999，但数据库存的这个字段长度是32位，当交易量小的时候，系统产生的值和字段32位是匹配的，序列不会升位。可是随着交易量的增加，序列不知不觉的升位数了，结果导致32位就不够存放。
类似这样的问题对于互联网系统非常常见，并且具有隐蔽性，所以如何避免就显得非常重要了。
下面我们从三个方面来看「付钱拉」所做的改变。
一、设计可容错的系统
比如重路由，对于用户支付来说，用户并不关心自己的钱具体是从哪个通道支付出去的，用户只关心成功与否。「付钱拉」连接30多个通道，有可能A通道支付不成功，这个时候就需要动态重路由到B或者C通道，这样就可以通过系统重路由避免用户支付失败，实现支付容错。
还有针对OOM做容错，像Tomcat一样。系统内存总有发生用尽的情况，如果一开始就对应用本身预留一些内存，当系统发生OOM的时候，就可以catch住这个异常，从而避免这次OOM。
二、某些环节快速失败“fail fast原则”
Fail fast原则是当主流程的任何一步出现问题的时候，应该快速合理地结束整个流程，而不是等到出现负面影响才处理。
举个几个例子：
「付钱拉」启动的时候需要加载一些队列信息和配置信息到缓存，如果加载失败或者队列配置不正确，会造成请求处理过程的失败，对此最佳的处理方式是加载数据失败，JVM直接退出，避免后续启动不可用；
「付钱拉」的实时类交易处理响应时间最长是40s，如果超过40s前置系统就不再等待，释放线程，告知商户正在处理中，后续有处理结果会以通知的方式或者业务线主动查询的方式得到结果；
「付钱拉」使用了redis做缓存数据库，用到的地方有实时报警埋点和验重等功能。如果连接redis超过50ms，那么这笔redis操作会自动放弃，在最坏的情况下这个操作带给支付的影响也就是50ms，控制在系统允许的范围内。
三、设计具备自我保护能力的系统
系统一般都有第三方依赖，比如数据库，三方接口等。系统开发的时候，需要对第三方保持怀疑，避免第三方出现问题时候的连锁反应，导致宕机。
（1）拆分消息队列
「付钱拉」提供各种各样的支付接口给商户，常用的就有快捷，个人网银，企业网银，退款，撤销，批量代付，批量代扣，单笔代付，单笔代扣，语音支付，余额查询，身份证鉴权，银行卡鉴权，卡密鉴权等。与其对应的支付通道有微信支付，ApplePay，支付宝等30多家支付通道，并且接入了几百家商户。
在这三个维度下，如何确保不同业务、三方、商户、以及支付类型互不影响，「付钱拉」所做的就是拆分消息队列。下图是部分业务消息队列拆分图：
（2）限制资源的使用
对于资源使用的限制设计是高可用系统最重要的一点，也是容易被忽略的一点，资源相对有限，用的过多了，自然会导致应用宕机。为此「付钱拉」做了以下功课：
限制连接数
随着分布式的横向扩展，需要考虑数据库连接数，而不是无休止的最大化。数据库的连接数是有限制的，需要全局考量所有的模块，特别是横向扩展带来的增加。
限制内存的使用
内存使用过大，会导致频繁的GC和OOM，内存的使用主要来自以下两个方面：
集合容量过大；
未释放已经不再引用的对象，比如放入ThreadLocal的对象一直会等到线程退出的时候回收。
限制线程创建
线程的无限制创建，最终导致其不可控，特别是隐藏在代码中的创建线程方法。
当系统的SY值过高时，表示linux需要花费更多的时间进行线程切换。Java造成这种现象的主要原因是创建的线程比较多，且这些线程都处于不断的阻塞（锁等待，IO等待）和执行状态的变化过程中，这就产生了大量的上下文切换。
除此之外，Java应用在创建线程时会操作JVM堆外的物理内存，太多的线程也会使用过多的物理内存。对于线程的创建，最好通过线程池来实现，避免线程过多产生上下文切换。
做过支付系统的应该清楚，部分三方支付公司是对商户的并发有要求的。三方给开放几个并发是根据实际交易量来评估的，所以如果不控制并发，所有的交易都发给三方，那么三方只会回复“请降低提交频率”。
所以在系统设计阶段和代码review阶段都需要特别注意，将并发限制在三方允许的范围内。
随着接入第三方支付通道的需求越来越多，付钱拉隆重推出开发者支付计划！
从支付到金融云，付钱拉华丽升级！推出新一季“开发者支持计划”！帮助开发者快速了解及对接支付通道，我们承诺接入过程：极速、便捷、安全、稳定。聚合支付SDK，为开发者而生！
从10月17号到12月31号，凡在付钱拉官网活动页面成功注册并通过资质审核企业，即可免费享受由付钱拉提供的开发者支持大礼包：
标准移动支付SDK。
支付技术培训服务。
支付通道代申请。
7*24小时在线运营支持。
成为付钱拉开发者技术联盟会员。
获得又拍云3000元代金券。
想要参加开发者支持计划的同学可拨400-880-1940报名
http://m.fuqian.la/?from=jkb
戳阅读原文，访问官网了解更多详情！
责任编辑：
声明：本文由入驻搜狐号的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
今日搜狐热点对于互联网应用和企业大型应用而言，多数都尽可能地要求做到7*24小时不间断运行，而要做到完全的不间断运行可以说“难于上青天”。
为此，对应用的可用性程度一般衡量标准有三个9到五个9。
对于一个功能和数据量不断增加的应用，要保持比较高的可用性并非易事。为了实现高可用，从避免单点故障、保证应用自身的高可用、解决交易量增长等方面做了许多探索和实践。
在不考虑外部依赖系统突发故障，如网络问题、三方支付和银行的大面积不可用等情况下，的服务能力可以达到99.999%。
本文重点讨论如何提高应用自身的可用性，关于如何避免单点故障和解决交易量增长问题会在其他系列讨论。
为了提高应用的可用性，首先要做的就是尽可能避免应用出现故障，但要完全做到不出故障是不可能的。互联网是个容易产生“蝴蝶效应”的地方，任何一个看似很小的、发生概率为0的事故都可能出现，然后被无限放大。
大家都知道RabbitMQ本身是非常稳定可靠的，最开始也一直在使用单点RabbitMQ，并且从未出现运行故障，所以大家在心理上都认为这个东西不太可能出问题。
直到某天，这台节点所在的物理主机硬件因为年久失修坏掉了，当时这台RabbitMQ就无法提供服务，导致系统服务瞬间不可用。
故障发生了也不可怕，最重要的是及时发现并解决故障。对自身系统的要求是，秒级发现故障，快速诊断和解决故障，从而降低故障带来的负面影响。
首先我们简单的回顾一下，曾经碰到的一些问题：
新来的开发同事在处理新接入的三方通道时，由于经验不足忽视了设置超时时间的重要性。就是这样一个小小的细节，导致这个三方队列所在的交易全部堵塞，同时影响到其他通道的交易。
系统是分布式部署的，并且支持灰度发布，所以环境和部署模块非常多而且复杂。某次增加了一个新模块，由于存在多个环境，且每个环境都是双节点，新模块上线后导致数据库的连接数不够用，从而影响其他模块功能。
同样是超时问题，一个三方的超时，导致耗尽了当前所配置的所有worker threads,&以至于其他交易没有可处理的线程。
A三方同时提供鉴权，支付等接口，其中一个接口因为交易量突增，从而触发A三方在网络运营商那边的DDoS限制。通常机房的出口IP都是固定的，从而被网络运营商误认为是来自这个出口IP的交易是流量攻击，最终导致A三方鉴权和支付接口同时不可用。
再说一个数据库的问题，同样是因为交易量突增引发的。建立序列的同事给某个序列的上限是999，999，999，但数据库存的这个字段长度是32位，当交易量小的时候，系统产生的值和字段32位是匹配的，序列不会升位。可是随着交易量的增加，序列不知不觉的升位数了，结果导致32位就不够存放。
类似这样的问题对于互联网系统非常常见，并且具有隐蔽性，所以如何避免就显得非常重要了。
下面我们从三个方面来看所做的改变。
（一）尽可能避免故障
设计可容错的系统
比如重路由，对于用户支付来说，用户并不关心自己的钱具体是从哪个通道支付出去的，用户只关心成功与否。连接30多个通道，有可能A通道支付不成功，这个时候就需要动态重路由到B或者C通道，这样就可以通过系统重路由避免用户支付失败，实现支付容错。
还有针对OOM做容错，像Tomcat一样。系统内存总有发生用尽的情况，如果一开始就对应用本身预留一些内存，当系统发生OOM的时候，就可以catch住这个异常，从而避免这次OOM。
某些环节快速失败“fail fast原则”
Fail fast原则是当主流程的任何一步出现问题的时候，应该快速合理地结束整个流程，而不是等到出现负面影响才处理。
举个几个例子：
1-启动的时候需要加载一些队列信息和配置信息到缓存，如果加载失败或者队列配置不正确，会造成请求处理过程的失败，对此最佳的处理方式是加载数据失败，JVM直接退出，避免后续启动不可用；
2-的实时类交易处理响应时间最长是40s，如果超过40s前置系统就不再等待，释放线程，告知商户正在处理中，后续有处理结果会以通知的方式或者业务线主动查询的方式得到结果；
3-使用了redis做缓存数据库，用到的地方有实时报警埋点和验重等功能。如果连接redis超过50ms，那么这笔redis操作会自动放弃，在最坏的情况下这个操作带给支付的影响也就是50ms，控制在系统允许的范围内。
设计具备自我保护能力的系统
系统一般都有第三方依赖，比如数据库，三方接口等。系统开发的时候，需要对第三方保持怀疑，避免第三方出现问题时候的连锁反应，导致宕机。
（1）拆分消息队列
提供各种各样的支付接口给商户，常用的就有快捷，个人网银，企业网银，退款，撤销，批量代付，批量代扣，单笔代付，单笔代扣，语音支付，余额查询，身份证鉴权，银行卡鉴权，卡密鉴权等。与其对应的支付通道有微信支付，ApplePay，支付宝等30多家支付通道，并且接入了几百家商户。在这三个维度下，如何确保不同业务、三方、商户、以及支付类型互不影响，所做的就是拆分消息队列。下图是部分业务消息队列拆分图：
（2）限制资源的使用
对于资源使用的限制设计是高可用系统最重要的一点，也是容易被忽略的一点，资源相对有限，用的过多了，自然会导致应用宕机。为此做了以下功课：
限制连接数
随着分布式的横向扩展，需要考虑数据库连接数，而不是无休止的最大化。数据库的连接数是有限制的，需要全局考量所有的模块，特别是横向扩展带来的增加。
限制内存的使用
内存使用过大，会导致频繁的GC和OOM，内存的使用主要来自以下两个方面：
1.集合容量过大；
2.未释放已经不再引用的对象，比如放入ThreadLocal的对象一直会等到线程退出的时候回收。
限制线程创建
线程的无限制创建，最终导致其不可控，特别是隐藏在代码中的创建线程方法。
当系统的SY值过高时，表示linux需要花费更多的时间进行线程切换。Java造成这种现象的主要原因是创建的线程比较多，且这些线程都处于不断的阻塞（锁等待，IO等待）和执行状态的变化过程中，这就产生了大量的上下文切换。
除此之外，Java应用在创建线程时会操作JVM堆外的物理内存，太多的线程也会使用过多的物理内存。对于线程的创建，最好通过线程池来实现，避免线程过多产生上下文切换。
做过支付系统的应该清楚，部分三方支付公司是对商户的并发有要求的。三方给开放几个并发是根据实际交易量来评估的，所以如果不控制并发，所有的交易都发给三方，那么三方只会回复“请降低提交频率”。
所以在系统设计阶段和代码review阶段都需要特别注意，将并发限制在三方允许的范围内。
来源拓扑社：//fuqianla/
“我们最早对标的是恒生电子，但现在做的事情，有些像蚂蚁金服，不过我们主要是为中小微企业提供基于支付的一体化金融服务解决方案。”付钱拉的创始人冯超如是说。而实际上，此前外界一直将付钱拉理解为一个聚合支付解决方案提供商，帮助中小微企业通过付钱拉的几行代码，就可以接入市面上包括支付宝、财付通等50多家支付通道——这听起来和其他做支付聚合的公司没有任何不同。
但实际上，从支付方案到金融服务的整体解决方案，是付钱拉成立之初就一直主营的业务，只不过金融服务整体解决方案初期的方向是为大公司提供。而随着双创热度变高，付钱拉决定，从中小微企业入手，以高度标准化的支付服务作为切入点，将金融服务整体解决方案提供给中小微企业。
以“支付”作为关键词，在IT桔子上搜索一下便有近80多家公司出现。这80家公司中，做聚合支付的公司大多是技术导向的，他们做了支付以后，往往将会员营销作为业务下一步的扩展方向。例如Ping++、Beecloud便采取了这样的路径。
然而冯超对支付的下一步业务有点不同的看法。冯超认为支付是金融行为产生的基础，解决的是金融价值的传递，也是金融的一部分，而中小微企业目前没有能力自己补足的便是金融能力。
“我们在解决了中小微企业基础的支付需求之外，还需要为中小微企业提供金融解决方案，帮助他们建设自己的金融能力，因此从付钱拉的业务体系来看，支付的下一步是金融。目前中小微企业的理财意识已经越来越强，当中小微企业的现金流达到一定量级时，他们必然会对如何将现金流更加合理的利用更感兴趣，这其实就已经涉及到了金融，但是企业如何利用好金融工具，怎么去实施？其实他们没有任何经验，就比如流动性管理就会涉及到企业应收账款，账期和借贷需求的处理，这些就需要有专业的人、专业的金融解决方案才能搞定。”
几乎所有的企业都希望留住用户，最有效的方式就是留住用户的钱，但是让用户充值本身非常困难，因为用户的第一希望是让钱增值，而不是放在某个账户里坐等通胀，因此企业如果希望激发用户充值的热情，申请支付牌照、开通理财服务是一条可选的捷径，这也是小米、京东、美团等公司都想做支付的原因。
“中小企业和创业公司一开始需要的是接入主流的支付渠道，这本身是非常简单和高度标准化的需求，因此付钱拉的第一步是给这些中小企业提供移动支付的SDK，然后根据企业的情况逐步建设企业的金融能力、为企业提供合适的解决方案。”冯超说。
冯超本身是一个年轻的80后创业者，做了几年金融产品，出来创业的时候，他拉上了金山私有云的技术副总裁，恒生电子的保险、基金业务架构师，团队后来还从百度等一线互联网公司招募到了一些高级人才，因此付钱拉在支付、基金和互联网金融方面的优势相对明显，给一些上市公司做了支付的整体系统解决方案，也积累了一些较好的合作关系：在支付领域已经推出了十几款支付产品，在理财、消费金融、众筹、基金保险等方面已经成功和宜人贷、Angel Ease、中德安联等公司建立了长期合作关系，在创业者和开发者支持计划中，付钱拉也已经与众多孵化器，创客空间，技术社区、科技媒体等建立了合作伙伴关系。
2015年华创资本对付钱拉进行了注资孵化。有几个企业客户接入了付钱拉，这些客户也是华创资本投资的“兄弟公司”。付钱拉接入后，能够很清楚地看到这些公司的流水情况如何。“尤其是电商类公司，遇到需要囤货的时候，对债权融资的需求是很强烈的，这个时候我们就可以把他们的流水数据给资本方，比如华创，证明他们的确需要这笔钱，也有能力还，那么资本方就很愿意借出这笔钱。”
冯超以土星教育为例，说明付钱拉是如何成功解决土星教育两端客户支付和理财的需求。“土星教育算付钱拉的大客户了，15年的时候上了新三板。当时我们帮土星教育做了支付，包括收款和付款，以及投资理财功能。一般的家庭可以直接在土星教育移动端内充值或支付学费，同时通过调用我们的代付接口，把款打给各地的幼儿园。后来我们发现，充值到真正支付发生这段时间，用户希望钱生钱，我们就帮土星对接了一些互联网金融公司。”
但现金流优秀的中小企业毕竟是少数，对此冯超的心态是这样的：“中小企业本身死亡率就很高，活下来的企业对于众筹平台和VC的需求会存在，同时众筹平台和VC也比较喜欢有存活能力的企业，因此我们希望把这一部分企业变成我们的用户，我们希望他们接入付钱拉不仅仅是希望省一些开发时间、获取更低的费率，而是因为我们能够为他们提升金融能力，长期来反哺他们的业务。”
这是一个最好的时代，但绝不是一个最坏的时代。
2015年被很多人定义为中国创业大潮的起点，平均每天新登记注册的企业就有1.16万家，意味着每分钟诞生8家公司。尽管下半年经历了所谓的资本“寒冬”，但融资案例的数量仍达到了近六年的高峰。
创业浪潮得益于（移动）互联网的发展，以及国家政策利好。哪怕残酷的数据摆在眼前，中国的创业失败率高达90%多，企业平均寿命不足3年，依旧阻挡不了一批“宁愿创业至死，不愿苟活一世”的创业者们。
因为“梦想还是要有的，万一实现了呢！”
为了更好的服务创业公司，7月21日起，付钱拉携手，帮助有支付场景需求的初创公司快速解决支付环节遇到的各种问题，打破创业壁垒。「梦想计划」从免费支付接入、到技术协助、资金支持，多维度帮助初创企业跑赢起跑线。
创业者（企业资质）只需要在付钱拉官网注册认证，并发生实际交易，就可以获得不同等级的。
「付钱拉」通过自身丰富的支付经验和强大的支付系统，为初创公司提供极速、便捷、安全、稳定的一站式支付解决方案。除此之外，「付钱拉」基于支付衍生出的金融云服务，包括分期消费、供应链金融、众筹等，更是完美的解决初创公司成长路上对资金的需求。
加入「付钱拉」，创业者获得的将不只是单一的支付服务，而是完整闭环的金融云服务。
最新活动：
快速通道，长按二维码即刻报名
根据相关报道分析，2015年中国消费信贷规模达到19.0万亿元，同比增长23.3%，预计2019年将达到41.1 万亿元。
居民投资理财及超前消费意识增强，借贷消费意愿不断加强，尤其是移动互联网的崛起，更是催生了对各种金融服务的强烈需求。
面对如此巨大的市场规模，各路资本也纷纷布局消费金融，抢占下一个风口。
日，天天投联合创业邦、勺子课堂举办消费升级「市集趴」，无论您是个人、投资者、项目创始人还是媒体，只要您对消费金融感兴趣，有想法都可以（点击“阅读原文”）报名参加。
作为此次活动的合作伙伴，已着手联合国内知名投资机构和消费金融机构，为创业公司在消费领域的用户需求提供金融服务。
届时，也欢迎小伙伴与我们在线下作进一步的交流，一起探讨消费金融领域的新玩法。
「」支付系统从最初的研发，到日交易量几十笔的能用阶段，再到日均订单处理量100w-200w笔（账单交易日达300w笔以上），每年处理支付交易流水高达2000多个亿的庞大体量。
作为对接了30多家银行和三方，以及300多家商户的「」，可以说真正的实现了支付系统从0到1的跨越。
《系列文章》建立在「」整个支付系统演进的基础上，囊括了我们自身经验的总结，以及技术与业务深度结合的思考和实践。
本文作为系列文章的第一篇，将从整体上剖析「」的支付系统，简要分析系统的架构设计理念，更加具体的技术实现和最佳实践，后续会在其他系列文章详细介绍（敬请期待）。
根据「」业务的不断发展以及支付系统迭代的多个阶段，我们将主要从以下几个方面来分享：
支付系统目标
作为一个为企业（To B）提供支付信息技术服务的平台，「」支付系统不可避免的需要应对指数级的业务增长，为此系统在设计的时候有了以下几个目标。
业务量的增长，意味着单个节点不足以满足性能需求，就要各个系统模块支持横向扩展和分布式部署。
测试是代码质量的最后一道防线，「」支付系统支持分布式部署，但是目前的框架给测试也带来许多困难，比如开发人员在本地测试的时候，不同的开发人员相互争抢MQ消息。针对开发和测试环境，区别化使用队列名称，通过打标签的方式实现。
作为和资金打交道的支付系统，绝不允许任何出错。如果突然发生了一个问题，影响的交易金额就不可控了。所以如何及时发现问题，监控系统就显得尤为重要了。
满足监控的同时，报警也必不可少。由于监控项目和场景非常多，如何判断出哪些项目为出警项，哪些为关注项就十分紧要。如果全部为出警项，对于报警接收人员，可能造成&狼来了&的效应，当出现真正需要报警的时候，重视度就会降低。
其次是报警方式，通常采用推送和拉取模式，分为监控页面，监控室，短信，邮件等。
在支付系统中有很多的参数，并且随时可能发生变化，如果每次变化都重启系统，肯定是不合理的。比如响应码状态的配置，银行维护配置，交易处理时间段等等，可配置就可以解决此类问题，保证客户端无感知。
安全性就像支付系统的心脏一样，必不可少。安全性主要有两个方面，一个是用户数据安全，要求展示层面、存储层面、内部交互层面和外部通信层面都必须是安全的；一个是系统支付安全，包括人为操作和系统bug导致的支付损失的避免。
高可用要求系统能够一直提供稳定的服务，满足SLA（Service Level Agreements，服务级别协议）的要求。「」为了提供高可用服务，所有的系统组件拒绝单点部署，从业务模块，数据库，消息中间件，定时服务和Nginx等都做了集群功能。
高性能要求支付系统提供快速的响应时间，以保证用户端支付体验的流畅性。拥有大量的互联网类型支付交易的「」，为了实现毫秒级交易实时响应时间，对整个支付环节的做法是拆分，通过分步和异步提高并发能力。
支付系统架构改变之路
针对不同阶段的业务发展和痛点，「」支付系统从架构层面都做了以下改变。
、业务量的指数增长
「付钱拉」支付系统刚上线的时候，每天交易量也就几十笔，不到两个月的时间，系统每天的交易量就飙升到了100w-200w笔。这时候系统初始的架构已无法满足业务量的需求，为此我们做了两件事：
分布式部署。系统业务模块做拆分，一个大的功能点拆分成好几个模块来实现，并且每个模块都是无状态的，这样才可以支持横向扩展。
解决数据库大表问题。支付系统有两张大表，一个是支付记录表，另外一个是支付日志轨迹表。最开始，系统支付记录只有一张表存储，当一个月的数据量达到6000w笔时，如果一个开发人员因为疏忽SQL忘记按照索引查询，对数据库来说可能就会造成蝴蝶效应，引发重大风险。为此，我们通过读写数据分离、冷数据清除和部分功能借助缓存来减少数据库压力。长期方案「付钱拉」采用分库分表的方式，来解决数据库大表问题。
、应对滚雪球效应
「付钱拉」支付系统最初消息队列是按照不同的支付类型来拆分的，但是随着后端三方和银行数量的不断接入，不同的三方网络和处理能力都不一样。这种情况导致同一种支付类型下面，一个三方宕机会堵塞其他三方的交易，产生滚雪球效应，雪球越滚越大，最后将拖垮所有交易。
针对这种情况，我们做的改变是隔离，按照商户、三方、和支付类型做彻底隔离，确保不同的业务和商户各行其道，互不影响。
、系统存在的单点故障
任何的单点都是存在风险的，不要相信任何软件或者功能是多么的无坚不摧。「」支付系统原先使用的消息中间件是单节点，并且运行的很稳定，没有出现过故障。但是有一天，它所在的物理机器网卡掉了，瞬间就不能提供服务。
单点故障也许不是自身的问题，但是依旧存在发生风险的可能。「」目前所有的节点包括中间件都是双备，避免了单点的风险。
如何避免操作风险
操作风险可以认为是人为风险。作为互联网系统，如果因为操作风险导致一个小bug，可能充其量就是用户体验不好，立即修复即可。但对于支付系统，每笔交易都是真金白银，不可以有任何一个小小的操作风险。
「」经验总结操作风险主要有以下几种：上线操作风险、代码未审核风险、生产环境变更风险、订单修改风险、测试风险。如何避免这些操作风险，我们在其他系列再详细展开讨论。
、是否具备自我保护能力
当发生不可预期的问题时，支付系统能够自我解决，也就意味着系统具备自我保护能力。通过容错，快速失败，降级和限制使用的方式，通常能够让系统达到自我保护。
容错，比如发生一笔交易，突然出现网络异常，如果明确知道这笔交易没有发往三方，那么就可以尝试再发送一次来提高成功率。「」有一个自动重路由功能，第一次路由到的通道如果交易失败，符合一定条件，会自动重路由去尝试别的通道，这就是很好的容错。还有一种容错场景，一般系统如果发生OOM（Out Of Memory ）异常就会发生假死。如果能够在设计系统的时候，预留一部分内存，然后当发生OOM的时候，去catch住处理掉，这样一个小小的容错就能够最大化地避免系统发生OOM。
快速失败原则，如果系统启动的时候，明确知道缺少哪些东西，就算启动了服务也不可用，那这时候启动的时候就让启动直接失败；还有针对实时类交易，如果超过响应时间，就快速失败响应用户，而不是无休止等待。
服务降级，是在系统达到一定访问量的时候，如果不能满足服务要求，必须要做的事情。「」在针对商户活动日的时候，就会做服务降级，保证活动日的正常交易。
限制，如果支付系统资源无限制使用，没有管控，一定会在某个时间点发生事故，比如数据库、内存等。「」主要做了以下限制：限制各个模块的连接数的个数，因为横向扩展一定会引发这个问题；限制内存的使用，内存过大会导致频繁的GC和OOM；限制woker线程的个数；限制三方的并发数量。
、外挂系统
外挂系统主要是用来支撑核心系统，但是它的引入又不可以影响核心系统。「」有两个外挂系统，一个是日志轨迹系统，一个是实时预警系统。具体的实现会在其他系列讨论。
、支付安全问题
「」的支付安全主要来自外在安全和内在安全两个方面。外在安全包括用户敏感数据展示、存储、内部交互、外部通信和人为操作；内在安全主要指系统并发导致的资金支付风险。
、促销活动
在业务线做促销的时候，交易量剧增，但是受限于指定的支付通道和并发处理能力，如果交易量超过了处理能力，为了满足其他商户不受影响，「」针对不同的商户做了服务降级处理。
现实业务场景往往比理想的业务场景复杂的多，「」在不同的支付类型上做了多种业务创新和封装来满足各种各样的业务需求，比如超级快捷，Token支付，快捷服务化，鉴权服务化，动态重路由，代扣Plus等。
改变NEVER stops
系统架构和业务的演进是不间断的，没有终点，No Silver Bullet（没有银弹）。「付钱拉」的支付系统架构还在不断改进中，比如动态路由，服务治理等，只有矢志不移的去改变，去适应，才能够满足业务需求。目前市面各家支付系统架构都有自己的特性，本文以「付钱拉」系统实践来简要剖析支付系统的架构特点，后续会在其他系列对本文中提到的点进行详细讨论。
如果我们不曾相遇
我会是在哪里
如果我们从不曾相识
不存在这首歌曲
每秒都活着&每秒都死去
每秒都问着自己
谁不曾找寻&谁不曾怀疑
茫茫人生奔向何地
那一天&那一刻&那个场景
你出现在我生命
从此后&从人生&重新定义
从我故事里苏醒
我们招人啦！
如果你想推翻过去，遇见新的自己。
在这一辈子里面，请珍惜，我们相遇的机会可能就只有一次。
在这里，你将和「」的小伙伴一起创造新世界。
以下岗位，招人
产品经理/助理/实习生
运营总监/经理/助理
IOS/Android/Java工程师
大数据工程师
工作地点：北京大望路
具体招聘要求和简历投递：点击「」查看。
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
日，由微博商业平台及产品部联合天弘基金、小米和等金融技术团队合力策划的互联网金融系统技术沙龙，在北京航空航天大学顺利举办。
沙龙分享内容主要围绕互联网金融系统的技术架构、系统安全、数据一致性、业务开发模式和开发运维经验等方面，由多位资深互联网金融领域架构师就实际工作中的金融系统设计、问题解决方案和技术积累等经验进行分享。
作为特邀嘉宾，CTO史晓慕向来自不同领域的300多名精英，讲述了打造的支付平台所使用的技术架构，以及与之相匹配的系统运营方案。
创立于2015年，对外提供都是金融级别的服务，CTO史晓慕将其定义为互联网化的金融云平台。传统金融在理念和系统上与互联网时代人们的认知有很大的出入，例如相比现在流行的互联网分布式系统，银行核心系统多使用的是大型机。我们想要接银行的接口，使用它们的服务，就要对接它们的专线，不同银行要求还不一样。这样做银行的优势在于系统很稳定，但劣势也比较明显就是效率较低。
CTO史晓慕谈到，作为一个“居中系统”，一边对接互联化的创业者、企业家，一边对接提供金融（信息）服务的金融（非金融）机构，包括银行、基金公司、保险公司，P2P，众筹等。
目前主要做的工作有两块，一块就是给创业公司提供聚合支付服务，对三方和银行接口做互联网化的改造，实现支付的易用性；一块是依托自身资源，为企业提供金融级别的服务，包括账户、资金托管、理财、风险管理等。
作为一个居中系统，以支付为核心的，通过互联网的方式收单，接收用户请求，对其进行隔离、保护，再转化成金融系统能识别和接收的数据。付钱拉提供的秒杀系统和动态路由，在考虑成功率，网络质量，流量并发以及平台费率情况下，通过对接的30多家三方支付公司，能很大程度的提高企业订单交易成功率和用户体验度。
随着市场上支付牌照朝着越来越少，越来越贵且支付基础服务越来越普及的趋势发展。小公司和非金融机构一方面无力购买牌照，没有中间账户，一方面又需要有自己的支付系统（模块）。这个时候，就可以充当一个支付系统，CTO史晓慕将其称作“影子系统”。作为“影子系统”，需要接受最终一致性，也就是状态的一致性。银行把支付状态同步给第三方，第三方再把状态同步给企业的支付系统，企业拿到的这个状态并不意味着是最终结果或者说正确的。
怎么保证状态一致性，CTO史晓慕从自身经验讲道：“第一做好防重，一笔订单只能有一个状态，从初始化状态到正在支付状态，再到成功/失败最终状态之间的转换，来实现防重；第二做好核对查询，核对查询是为了最大程度的保证交易的正确性，通常需要调三方的查询接口，支付交易一旦落库，查询也就可以实现；第三做好状态查询，不同的接口和三方，状态不一致且查询有时滞，必须确认订单的状态是什么，避免资金的损失。”
市场上众多的三方支付公司和银行，都有一套自己核心的系统，系统的运行不可能一帆风顺，难免会出现各种各样的问题。对于一个支付非核心业务的企业而言，要建立一个支付系统是一件出力不讨好的事情。而且为了维护支付系统还需要培养一批专业的支付结算人员，专门处理用户在支付结算过程中遇到的，譬如掉单、调单、结算周期、客户投诉等问题。
通过自己的整体技术架构包括对外服务接入体系、聚合服务系统、综合监控系统、服务监控系统、数据分析与报表系统、运营管理系统等基本可以避免企业在此类事件中损耗过多精力。基于这样的技术架构，可以为企业提供多通道、动态路由、统一的支付接口。对于企业最关心的安全问题，CTO史晓慕表示，从HTTPS、金融系统加密机、强一致性、多机房备份等方面做足了功夫，能够实现金融级别的安全性。
据美国商业内参研究机构（BIIntelligence）指出，很多人倾向于在手机或者平板电脑上浏览自己想要购买的东西，但是却不会在这些设备上最终购买，因为对于他们来说在移动设备上输入付款信息和订单信息等比较麻烦。
移动设备上输入信息的各种复杂流程和步骤是导致用户在电商网站上放弃结账的原因之一。
之前传言苹果将推出网页版&的消息，在6月14日WWDC大会也得到了证实。这意味着以后在移动和桌面Safari上购物时，用户将可以直接进行支付了。
视频&|&支持网页使用一键切换手机付款
通过部署简单的解决方案包，IT专业人员可向他们的业务用户提供服务。这样，用户能够通过窗体小部件轻松地将这种能力添加到商务网站中。一旦该服务上线后，用户在能够接受网页版的网站上进行在线购物，然后选择&付款，网页就可以将支付信息一键传到 iPhone 或者Apple Watch 上进行确认付款操作，用户直接通过 Touch ID 认证即可付款。
整个过程只需通过TouchID用手指触摸即可轻松完成，而无需手动填写冗长的账户表格，或者重复输入发货和账单信息。
网页版允许在iPhone、iPad和Mac上的Safari中以安全和私密的方式完成支付。当消费者用网页版ApplePay使用信用卡或借记卡时，实际卡号并不在设备上存储，也不在Apple服务器中存储。相反，系统将指定一个唯一的设备账号，经过加密后安全地存储在设备的安全元素中。每个交易都通过一次性的唯一动态安全码而授权。
通过网页版，零售商就不用购买 NFC读卡器及终端这类的新设备。苹果将于今年秋季正式发布该版本，并在所有已经推出的国家/地区开放使用。
2016年苹果全球开发者大会（WWDC2016）将于太平洋时间6月13日上午十点（北京时间6月14日凌晨一点）在旧金山拉开帷幕。
此次大会主要面对开发者，所以大会的重点将是对操作系统和软件服务进行更新，包括OS X、iOS、watch OS、tv OS及Siri、Apple Music等。按照惯例，苹果公司应该不会在WWDC上发布新的硬件产品。
所以，那些想等iPhone7的小伙伴估计要失望了。
就在近日，来自Digital Trends的消息，苹果或将在全球开发者大会（WWDC）上正式宣布Apple Pay支付服务与网站整合的新功能，即「网页版Apple Pay」。
Apple Pay是苹果在2014年推出的一种基于NFC的手机支付功能，用户可以利用苹果手机在实体店进行结账支付，也可以在APP中进行支付。
相关的研究表明，消费者通过移动设备来购物已经形成了一种趋势，使用移动设备的时间也比较长，但是花钱购物的时候大多数都是在桌面设备上完成的。
原因在于：在手机上不管是移动网页还是APP应用里，输入卡号和商品细节等，便捷性较差。而在大屏幕的桌面设备上完成这些操作就更容易一些。而像 Apple Pay 等支付服务在合作应用中，可以帮用户省略很多步骤，自动帮助用户填满这些信息。「网页版Apple Pay」就能够缩小用户在桌面和移动设备上花钱购物的比例了。
「网页版Apple Pay」具体操作流程未知，但我们不难猜到，苹果会将网站交易限制在公司能够完全控制的产品上，即配备了Touch ID的iPhone和iPad上的Safari浏览器。网站页面上将会增加一个支付选项：Apple Pay，用户选择了它，就会被提示在手机上用Touch ID验证身份，保证交易安全进行。
某种程度上，网页版Apple Pay用Touch ID验证身份的流程应该与在手机上苹果应用商店用专门的支付App进行交易是类似的。这不仅有助于提供安全性，还将有助于许多通过访问零售商网站进行购物的消费者。
「网页版Apple Pay」是否真的会到来，让我们一起期待即将到来的WWDC吧！}