万亿级交易量下的支付平台设计.docx

? ? ? ? ? ? ? ? 万亿级交易量下的支付平台设计 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 本文主要是根据作者在2018QCon演讲内容整理而成： 苏宁金融交易量3年内从1000亿增长到万亿+，服务用户3亿+，服务场景从服务于苏宁易购内部生态，扩展到服务全渠道，全场景，多业态的线上线下智慧零售的开放生态圈，一方面要满足公司业务发展要求，快速研发新产品，另一方面要满足818大促，双11等大促设计要求； 本次主要介绍苏宁支付系统如何实现500天性能提升2000倍，从100笔/秒提升到20万笔/秒，给飞行中的飞机换引擎，将包括三大章节六个部分： 苏宁支付平台发展历程，以及现在运行的总体架构设计，以及配套的可视化作战指挥系统，以及在业务急速变化，万亿级交易量的状态下，如何对全局架构进行优雅地重构，以及重构过程中的实战案例，最后介绍一下我们目前规划的、对未来的展望； 具体技术包括高可用设计技巧，高伸缩性设计思路，弹性的流量和资源控制，异地多活，全链路压测，消除数据瓶颈与单点，热点追踪与防护，故障自愈，账务系统之大账户瓶颈解决方案，以及未来怎么实现机器人自动巡检和自动修复等实战经验分享。 第一部分，我们介绍苏宁支付平台的演进路线， 架构演进的驱动与目标； 苏宁支付平台演进经历了四个阶段：从传统的架构，到SOA架构，到云计算架构以及目前的智能支付引擎；服务场景也从单一的服务苏宁易购，到服务苏宁内外部生态圈，再到提供行业解决方案。TPS从100到20w+的支付处理能力；交付周期也从最初的按月交付到现在的准实时交付。 那是什么驱动我们进行一次次的架构演进呢？驱动力和目标是什么呢？支付平台是整个金融的基础设施，也是公共设施，服务于几十个事业部的几百条产品线，如果每一条产品线提一个需求，那就要同时响应几百个需求，同时还要面对业务的大促，因为苏宁是O2O的模式，业务场景会更加复杂，线上线下都有：线下的五一、国庆；线上的418、618、818、双11、双12，基本上每两个月就有一个S级大促；一方面要保证业务需求的快速响应，另一方面也需要保证大促的安全稳定，对来说业务需要快，对系统来讲需要稳，那就需要我们的系统，是一个高可用、可伸缩、低成本、快速交付的系统。 第二部分介绍现在正在运行的总体架构设计，包括总体业务架构设计，总体系统架构设计，总体技术架构设计，关键子域的架构设计； 首先是总体业务架构设计，主要包括4个部分：第1部分是我们服务的渠道和场景，包括SDK,WAP,PC各端，线上线下门店；以及电商体系的应用，金融APP的应用等；第2是我们的合作方银行：包括中农工建交等以前的直连银行，以后后来的网联，银联等；第3是贯穿整个全流程的风险控制体系与运营支撑体系，包括欺诈风险，信用风险，以及配置产品，运营的各种支撑系统；第4是云支付平台本身。在云支付平台中包含三大子架构域：一是开放平台，把我们内部的服务统一开放出去给各个渠道、各个服务去使用；二是对这个平台进行层层抽象，将c端业务平台当中线上线下的公用逻辑抽取到c端业务平台，b端业务平台当中各个行业支付的公用逻辑，我们会抽取到b端公用平台。第3作为支付核心，会统一整合内外部支付工具以及账户核心操作指令统一提供给上层使用。 业务架构决定了系统架构，从纵向来看，我们分为应用层、数据层、技术服务层、基础设施层，以及贯穿整个全流程的决策支持与运营支撑层。 从横向来看，分成面向用户和商户的服务交付层（通过开放平台交付给我们的合作伙伴，通过这个平台前置服务于苏宁易购生态圈的各个应用场景）；应用服务层（包括业务处理类、管理类、数据类）；通用服务层（即平时常见的支付收银台、风控、合同计费等）；核心服务层（包括会员、账务核心、清结算等）；网关服务层（因为我们需要集成外部的一些服务，包括金融服务，通过金融交换服务去做；沟通网关，面向运营商的；业务网关，面向和我们合作的商户的）； 整体架构的设计，我们采用了插件式的架构设计思想，比如服务交付层，我们基于标准的平台业务进行服务交付，这样可以使各应用域独立并行的研发；对网关服务层，我们基于标准的外部服务引入，使平台具有快速可扩展性。 业务架构和系统架构决定了我们的技术架构，技术架构包括三大部分： 持续交付层，以及支撑我们持续交付的中间件层以及基础设施部分：持续交付重点有两个，第一是快：开发快，所以我们有开发的插件、模板生成工具；测试快，从自动化测试到持续集成，到一键建站的统一拉起；发布快，有现成的发布流程支持；业务验收快，这个是我们支付平台独有的一项，上线之后要做业务匹配分析和还原，这个有两点好处：（1）对业务来说，可以快速地知道需求有没有按照业务预期的开发；（2）对研发人员来说，可以快速地知道研发的需求是否获得了业务收益。这样