本次主要介绍苏宁支付系统如何实现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次是监控与核对，第3层是止损与追款。平稳，发布时支持灰度发布和预案回滚。
接下来讲关键子域架构设计，收银台分为三层：第1层是业务产品层；第2层是业务接入层，会做一些异常的适配，如不同的errorCode可以展示不同的异常界面，对用户体验比较好。第3是核心层，用户偏好与习惯、额度控制等。收银台是从一个简单的收银门面，千人一面，逐渐发展到千人千面，再到一人千面。支付引擎会整合银行相关的外部支付工具，以及零钱宝、任性付、信用支付、现金贷等内部支付工具，同时进行账户操作指令的封装（主账务核心和各个业务的微账务核心）。对我们来说，账务核心、支付工具群和支付外转接中心都是一个个插件，开发速度快；在具体的一个支付工具内部，也是插件式的；这样就完全可以实现大规模的并行研发；最后是网关层，面向接入银行渠道和接入合作大商户：第1层是报文组装解析层，第2层是适配器层，第3层是路由引擎；由图可见，每家银行的公用逻辑相同，可以通过设计模式封装。不同的是输入参数的获取策略以及输出参数的不同阐释策略。
