首先是总体业务架构设计，主要包括4个部分：第1部分是我们服务的渠道和场景，包括SDK,WAP,PC各端，线上线下门店；以及电商体系的应用，金融APP的应用等；第2是我们的合作方银行：包括中农工建交等以前的直连银行，以后后来的网联，银联等；第3是贯穿整个全流程的风险控制体系与运营支撑体系，包括欺诈风险，信用风险，以及配置产品，运营的各种支撑系统；第4是云支付平台本身。在云支付平台中包含三大子架构域：一是开放平台，把我们内部的服务统一开放出去给各个渠道、各个服务去使用；二是对这个平台进行层层抽象，将c端业务平台当中线上线下的公用逻辑抽取到c端业务平台，b端业务平台当中各个行业支付的公用逻辑，我们会抽取到b端公用平台。第3作为支付核心，会统一整合内外部支付工具以及账户核心操作指令统一提供给上层使用。
业务架构决定了系统架构，从纵向来看，我们分为应用层、数据层、技术服务层、基础设施层，以及贯穿整个全流程的决策支持与运营支撑层。
从横向来看，分成面向用户和商户的服务交付层（通过开放平台交付给我们的合作伙伴，通过这个平台前置服务于苏宁易购生态圈的各个应用场景）；应用服务层（包括业务处理类、管理类、数据类）；通用服务层（即平时常见的支付收银台、风控、合同计费等）；核心服务层（包括会员、账务核心、清结算等）；网关服务层（因为我们需要集成外部的一些服务，包括金融服务，通过金融交换服务去做；沟通网关，面向运营商的；业务网关，面向和我们合作的商户的）；
整体架构的设计，我们采用了插件式的架构设计思想，比如服务交付层，我们基于标准的平台业务进行服务交付，这样可以使各应用域独立并行的研发；对网关服务层，我们基于标准的外部服务引入，使平台具有快速可扩展性。
业务架构和系统架构决定了我们的技术架构，技术架构包括三大部分：
持续交付层，以及支撑我们持续交付的中间件层以及基础设施部分：持续交付重点有两个，第一是快：开发快，所以我们有开发的插件、模板生成工具；测试快，从自动化测试到持续集成，到一键建站的统一拉起；发布快，有现成的发布流程支持；业务验收快，这个是我们支付平台独有的一项，上线之后要做业务匹配分析和还原，这个有两点好处：（1）对业务来说，可以快速地知道需求有没有按照业务预期的开发；（2）对研发人员来说，可以快速地知道研发的需求是否获得了业务收益。这样，业务和研发人员有了统一的视图。
第二是稳：开发的过程会做这一些非功能性的设计，如：伸缩型设计，监控设计，资损防控设计；资损防控设计有三层：第1层是开发与测试，第2次是监控与核对，第3层是止损与追款。平稳，发布时支持灰度发布和预案回滚。比如做升级，收单要从单库切到多库，不能一刀切，需要按业务场景、用户、访问链路灰度，可以保证整个系统的平稳；如果一个系统上线后，如果出问题能马上实现回滚，对用户没有影响；
接下来讲关键子域架构设计，从收银台到交易，从支付服务到支付引擎，我们如何实现标准化和插件化。首先收银台分为三层：第1层是业务产品层；第2层是业务接入层，会做一些异常的适配，如不同的errorCode可以展示不同的异常界面，对用户体验比较好。第3是核心层，用户偏好与习惯、额度控制等。收银台是从一个简单的收银门面，千人一面，逐渐发展到千人千面，再到一人千面；就是不同的用户在不同场景下看到的收银台是不一样的，到同一个用户在不同场景下也可以进行个性化的适配；
这个是收单系统和交易系统的介绍：分成两部分，一个是公用的部分，就是我通用的上下层的依赖，比如支付引擎、会员、收银台、收费计费等，中间的收单服务层可以通过设计模式去封装，根据不同的业务请求，然后统一做收单路由到不同的插件去处理。这样即使有几十条产品线同时请求，我们也能同时响应，因为只需要改动一个插件即可；
基于这种插件式架构的设计思想，接下来的支付服务也是这样设计的。
支付引擎会整合银行相关的外部支付工具，以及零钱宝、任性付、信用支付、现金贷等内部支付工具，同时进行账户操作指令的封装（主账务核心和各个业务的微账务核心）。对我们来说，账务核心、支付工具群和支付外转接中心都是一个个插件，开发速度快；在具体的一个支付工具内部，也是插件式的；这样就完全可以实现大规模的并行研发；
