以大众点评的支付渠道网关系统为核心,分享支付系统构建经验。

1、在可用阶段，早期业务流量不是很大，渠道网关系统的业务逻辑也很简单。总之，用户可以在交易过程中顺利支付资金。做的事情可以简单概括为三个:发起支付请求，收到成功的支付通知，并在用户要求退款时原路退还给用户的支付账户。现阶段系统实践比较简单，主要是“短、平、快”如图1所示，系统架构。2、在系统演变初期的快速迭代过程中，接入的第三方支付渠道不多，系统运行相对稳定，开发人员可以手动快速解决一些简单问题。然而，随着第三方支付渠道的增加，一些新的问题逐渐暴露出来：（1）所有的业务逻辑都在同一个物理部署单元中，不同的业务相互影响（如退款业务问题，但同时拖累支付业务）；(2)随着业务流量的增加，数据库的压力逐渐增大，数据库的偶尔波动导致系统不稳定，对用户的支付体验有很大的影响；（3）支付和退款的同步在很大程度上取决于第三方支付渠道的异步通知。一旦第三方支付渠道出现问题，就会引起大量的客户投诉，用户体验差，开发和运营非常被动。针对(1)业务之间的相互影响，我们首先考虑拆分服务，将以前的大型物理部署单元拆分为多个物理部署单元。有两种明显的拆分策略可供选择：根据渠道拆分，不同的第三方支付渠道有独立的物理部署单元，如微信部署单元、支付宝部署单元等；根据业务类型，不同业务有独立的物理部署单元，如支付业务部署单元、退款业务部署单元等。考虑到在当时的流量规模下，支付业务优先级最高，退款等业务优先级较低；有些渠道的流量比例很小，作为一个独立的部署单元，会造成一定的资源浪费，增加系统维护的复杂性。考虑到在当时的流量规模下，支付业务优先级最高，退款等业务优先级较低；有些渠道的流量比例很小。作为一个独立的部署单元，它会造成一定的资源浪费，增加系统维护的复杂性。在此基础上，我们制作了一个符合当时系统规模的标题-off：根据业务类型选择第二种拆分策略——拆分。针对(2)中的DB压力问题，我们与DBA一起分析了原因，最终选择了Master-Slave方案。通过增加Slave来缓解查询压力；通过强迫Master确保业务场景的强烈一致性；通过公司DB中间件Zebra进行负载平衡和灾难准备切换，以确保DB的高可用性。针对（3）中的状态同步问题，我们梳理了不同的渠道。在现有第三方支付渠道异步通知的基础上，通过积极查询定期批量同步状态，解决了大多数状态同步问题。对于少量未同步的Case，系统开放API供内部使用，方便后台接入和开发人员手动补充订单。渠道网关系统完成上述实践后，已达到基本可用阶段。从内部监控平台可以看出，核心服务接口的可用性可以达到99.9%以上。进化后的系统架构如图2所示。在解决了业务隔离、DB压力、状态同步等问题后，通道网关系统经历了一段稳定可用的时期。然而，它无法承受业务快速增长的压力。在业务流量规模下，一些小系统波动、流量冲击等异常情况在遇到流量高峰时急剧放大，最终可能成为压垮系统的最后一根稻草。在新的业务流量规模下，我们面临着新的挑战:(1)随着团队的成长，新生在接入新渠道或增加新逻辑时，往往会优先考虑熟悉的方式完成任务。但熟悉不一定是合理的，可能会引入新的风险。特别是在与第三方渠道对接时，系统目前使用的HTTP交互框架包括JDKHTPURLConection/HttpsURLConnection、Httpclient3.x、Httpclient4.x（4.X版本内部还有不同的小版本)。就在这个上面，我踩了好几次痛苦的坑。(2)按业务类型拆分服务后，不同业务不再相互影响。然而，在同一业务中，当流量规模较小时，偶尔波动影响不大。现在流量增加后，不同的渠道开始相互影响。例如，支付业务提供分布式支付API，所有渠道共享同一服务RPC连接池。一旦某一渠道的支付接口性能恶化，服务RPC连接占用量大，其他正常渠道的要求无法进入；故障渠道性能恶化直接导致用户无法通过该渠道成功支付，连锁反应导致用户多次重试，进一步恶化，最终导致系统雪崩，拒绝服务，重启后的服务可能会再次被大量的故障渠道重试请求击败。（3）目前接入的第三方支付渠道，无论是第三方支付公司、银行还是其他外部支付机构，基本上都是引导用户通过重定向或SDK完成最终支付行动。在这个支付链接中，渠道网关系统只能在后端与第三方支付渠道交互（生成重定向URL或预付款凭证），最终用户的支付结果只能通过第三方支付渠道的异步通知或主动进行支付查询。在这个支付链路中，渠道网关系统只在后端与第三方支付渠道（生成重定向URL或预付款凭证）进行交互，最终用户的支付结果只能通过第三方支付渠道的异步通知或主动进行支付查询来了解。一旦第三方支付渠道内部出现故障，渠道网关系统就无法知道支付链路已经损坏，从而损害用户的支付体验。(4)一些非渠道网关服务仍然可以直接访问现有渠道网关的DB，这给渠道网关系统的DB稳定性和DB容量规划带来了风险，进而影响了渠道网关系统的可用性。内部戏称戴“绿帽子”。(5)对于退款链接，系统没有统一收集、整理和分类异常退款case，缺乏明确的退款链接监控。这导致用户申请退款后，少数用户的退款请求最终未能成功处理，用户发起客户诉讼。同时，由于缺乏监控，这种异常退款缺乏后续的推广措施。在极端情况下，会导致用户的二次客户投诉，极大地损害用户体验和公司信誉。为了最大限度地解决问题（1）中描述的风险，在吸取了踩坑的痛苦教训后，我们收集并整理了不同的应用程序场景，并抽象了一套访问框架。访问框架定义了一套完整的网关交互流程，包括请求组装、请求执行、响应分析和错误重试，屏蔽了HTTP或Socket的底部交互细节，并提供了相应的扩展点。针对特殊的应用场景，如银行渠道访问前置机器，也基于Netty抽象连接池（ConnPool）与简单的负载平衡机制相结合（LB,提供RoundRobin路由策略)。自定义的组装策略可以插入不同的渠道(扩展现有的HTTPReq)、Httpsreq或NettyReq），实施策略[扩展现有（Http、Https或Netty）Sender/Receiver]，分析策略(扩展现有的HTTPResp、Httpsresp或NettyResp），并复用框架提供的内容分析（binary/xml/jsonparser）、证书加载（keystore/truststoreloader）加解密签名（encrypt/decrypt/sign/verifysign）在提高渠道接入效率的同时，组件可以尽可能降低新渠道接入的风险。访问框架的流程结构如图3所示。访问框架的过程结构如图3所示。为了解决问题（2）中渠道之间的相互影响，一个简单而直观的想法是渠道隔离。如何隔离，隔离到什么程度？这是两个主要问题:如何隔离考虑进一步按照渠道拆分支付服务，继续做小系统。但拆分后，支付API的调用端需要区分不同的渠道，调用不同的支付API接口，相当于将渠道隔离问题抛给调用端；同时，拆分后服务增加，调用端需要维护同一渠道的多个不同RPC支付业务-API，复杂度提高，在目前的业务流量规模下，增加了开发人员的维护负担，这是不可取的。因此，我们选择在同一支付服务API内进行渠道隔离。因此，我们选择在同一支付服务API内进行渠道隔离。由于共用同一支付服务API连接池，渠道隔离的主要目标是避免故障渠道占用大量AP连接池，影响其他正常渠道。如果故障通道可以自动检测，故障通道的要求在故障发生初期迅速失败，故障通道的隔离可以从业务逻辑上自动完成。在一个支付渠道下，有不同的支付方式（信用卡支付、借记卡支付、余额支付等），有些支付方式（如信用卡支付）仍有多家银行。因此，我们直接将渠道隔离的最小粒度定义为支付渠道->支付方式->银行。基于以上思路，我们设计并实现了故障通道的快速失败（fail-fast）机制:将每个支付请求附带的支付信息抽象成特定的fail-fast路径，请求抽象成fail-fast事务。成功的请求意味着事务成功。相反，事务失败了。在fail-fast事务执行过程中，级联有两个fail-fast断路开关：静态开关，根据人工配置（on/off），确定一个付款请求是否需要快速失败。动态开关，根据历史统计，确定当前的健康状况，然后确定当前的支付请求是否迅速失败。动态断路开关抽象了三种健康状态（closed-放行所有请求；half_open-请求放行部分比例；open-根据历史统计信息(总请求量/请求失败量/请求异常量/请求加时量)，快速失败所有请求)，在其内部维护一台健康状态变化的状态机。状态变化如图4所示。状态机器的每一次状态变化都会产生一个健康状态事件，收银员服务可以监控这个健康状态事件，实现支付渠道的上下联动切换。历史统计信息将在每个付款请求结束后动态更新。*流量模拟压测观察后，fail-fast机制增加了系统支付请求1~5ms的额外耗时，比第三方渠道的支付接口耗时1%~2%，属于可控范围。fail-fast机制启动后，结合压测配置，经过几次微调，稳定了*环境中的fail-fast配置参数。前不久某渠道支付故障时，通过公司内部监控平台，明显观察到fail-fast机制具有良好的故障隔离效果，如下图5所示。为了解决问题（3）中支付链路的可用性监控，依靠公司内部监控平台的报告，实时监控支付成功通知趋势曲线；同时，渠道网关系统从业务层面实现了对支付链路端到端的监控。基于这两个指标的历史统计信息，二级监控支付链路端到端支付总成功率和支付成功率，并提供实时支付链路邮件或短信报警。在流量高峰期，监控也可以手动降级(异步化或关闭)。这大大提高了开发人员核心支付链路故障响应速度。为了解决问题（4）中的“绿帽子”，渠道网关系统配合DBA回收所有外部系统的DB直接访问权限，为外部系统访问提供替代API，为提高DB稳定性、DB容量规划和后续可能的异步多机房部署奠定基础。针对问题(5)中的退款case，渠道网关系统配合退款链路上的其他交易支付系统，从源头上统一收集、整理、分类第三方渠道异常退款case，形成退款链路核心指标(退款当日成功率/次日成功率/7日成功率)监控。随着上述实践的逐步完成，渠道网关系统的可用性显著提高，核心链路API接口的可用性达到99.99%。在公司917推广中，渠道网关系统顺利度过流量高峰，迎来了新的记录：提交第三方渠道支付请求的TPS达到历史新高。当部分渠道接口出现故障时，可以保证核心支付API接口的稳定性，实现故障渠道的自动检测和恢复，实现收银员相应渠道的上下联动切换。此外，当部分渠道接口出现故障时，可以保证核心支付API接口的稳定性，实现故障渠道的自动检测和恢复，实现收银员相应渠道的上下联动切换。同时，当第三方渠道内部故障通过核心支付链路支付成功率监控实现时，渠道上下手动切换。到目前为止，渠道网关系统的灵活性在一些第三方渠道受损的情况下基本得到了保证。本阶段系统架构演化如图6所示。4、在逐步完善渠道网关系统的过程中，经验和总结踩了很多坑，吸取了很多教训，收获了一些小东西：1.坚持核心思想，拆分解耦，大系统小而简单；2.当系统出现问题时，重要的是如何快速定位、恢复和解决问题，这是一项长期而艰巨的任务；3.高可用性的最大敌人不仅是技术，还有那些使用技术来实现系统的人，在业务和系统快速迭代的过程中，如何保证自我驱动，不落后；4.高流量和大并发不仅是每个工程师的挑战，也是机遇。