编辑｜小智
从单一功能到完全体系、从臃肿单体 Php 演化为高性能高可靠可伸缩的分布式做事架构，于 16 年快速领悟俏丽说和淘天下支付体系，并在历年大匆匆中保持无端障的出色表现，逐渐摸索出适应全集团繁芜业务形态和变革的支付平台架构。详细是怎么做的？
注：本文整理自俏丽联合集团资深工程师陈宗在 ArchSummit 深圳 2017 上的演讲，原题为：《支付体系架构与实践》。
上篇：支付体系架构演进
在过去 4 年的韶光里，作为面向亿级用户的大型时尚消费平台，美联集团历经着高速的业务增长和快速的业务演进。而个中最主要的根本业务平台，美联支付如何稳打稳扎、平滑演进，快速适应并高效支持着业务的繁芜变革。我们从单一功能到完全体系、从臃肿单体 Php 演化为高性能高可靠可伸缩的分布式做事架构，于 16 年快速领悟俏丽说和淘天下支付体系，并在历年大匆匆中保持无端障的出色表现，逐渐摸索出适应全集团繁芜业务形态和变革的支付平台架构。
支付系统 1.x
13 年下半年的时候，蘑菇街从导购平台转为电商平台。为了支撑电商业务，我们快速实现了第一代的支付系统。当时蘑菇街的业务大略、玩法单一。如图 1.1 所示，第一代的支付系统只包含了支付最核心功能，从而尽快的支撑业务。在这期间，我们实现了面向业务的收银台、支付模块，面向资金真个账务模块，以及与三方支付对接的渠道网关。
1.x 支付系统架构
随后的几年，美联的业务进入超高速的发展，电商交易、以及支付的业务繁芜度剧增，玩法多变。同时，在经历数次大匆匆之后，我们创造，支付核心链路大匆匆 QPS 峰值达到了日常的百倍以上。在这种情形下，我们实在碰着了蛮多的问题，以下分为三部分来说下我们当时碰到的问题：
业务问题
1.x 支付系统构建的时候，支付系统设定了比如包管交易、提现等支付交易表。但是随着业务越来越繁芜，我们加了越来越多的支付交易表，全体系统的架构犹如图 1.2 所示的烟囱型架构。当时来一个业务，我们加 1-N 张表。
烟囱型系统机构
截止到 15 年底，全体支付系统存在这数十个支付交易表。这么多的表，侧面反响了我们对于出业务并没有做模型的抽象，只是在业务的野蛮成长下，不断的应对和接入。同时，在这种情形下，业务的边界很模糊，常常有业务，一半的业务逻辑实现在业务方，一半的业务逻辑在支付方。
系统问题
当时我们整一个支付系统都在一个巨大无比的单体 php 运用里。虽然系统在演进，也分出了不少的模块，但是大家知道。在一个巨大的单体运用里，比较随意马虎涌现各模块的耦合，比如支付模块调用了渠道网关模块的一个内部的方法等等。而其余一个，支付团队的几十号同学每天都在一个运用里面开拓 & 发布。任何一个地方跪了，都有可能让支付系统崩溃，稳定性非常低。
末了，电商平台的特性，决定了我们必须要不断的提升支付系统的性能。在 15 年的时候，我们对于出系统的 DB 进行了基于模块的垂直拆分，如下图所示。以用于提升系统容量。但这种情形下，我们还是碰到到性能瓶颈。
举个例子：15 年双十一，当时定下来系统能够支持 2kqps 的峰值支付性能。但在数轮链路压测之后，即时我们对 DB 进行了垂直拆分，并用了最好硬件 fushion IO, 但是我们创造系统仅能支撑大概 1800qps 旁边的支付。当时实在是比较绝望的，我清楚的记得在 15 年的 10 月尾，11 月初的很多白天黑夜，紧急对于出系统的包管交易下单进行了改造，添加了一系列的缓存，终极性能勉强能够达标。
支付系统 DB 垂直拆分
资金问题
第一代的支付系统中，我们对各个业务方的支付接入，并未供应任何的授权和鉴权。也便是说任何系统、任何团队都有可能调用支付系统接口进行资金操作，当时支付有一个万能的转账接口，业务方接入确实很方便，但实在埋了蛮多坑。虽然当时我们支付的业务做了日志记录，但是在数据库里面，我们并未能区分来源的业务、哪种操作，导致了我们对各项业务的流水、收入、支出难以统计和核算。
其余我们当时也碰到了数据同等性寻衅。当时支付系统仅有内外部渠道对账，而对内部的业务数据，并没有做好对账事宜，常常涌现用户反馈非常问题，然后我们才能知晓。
支付体系 2.0 架构实践
1.x 的支付系统中，实在我们碰到了很多的问题，痛定思痛，我们决心对于出体系做一次架构升级。那么，怎么去做支付体系的架构升级呢？，我们从两个方面来进行架构升级梳理：
巨大的单体运用必须得拆分，在拆分之前，我们须要确定业务、系统边界，对于出业务进行建模。
构建完全的资金核算体系，以达到能够清晰的知晓各种业务的流水、收入、支出等。
拆分系统边界
那么单体运用拆分之前，那么如何确定边界? 从三个维度对边界进行了拆分：
基于业务，拆分为面向支付业务，面向资金核算体系
基于场景，例如依据支付流程等
基于技能实现，比如出于对系统的性能考虑等
我们对于出体系里面的核心系统拆分为：收银台、交易核心、支付核心、网关、账务、司帐、清算、合规等。下图是对核心支付链路流程示意：
核心支付链路流程
支付体系 2.0 整体架构
得益于蘑菇街强大的根本平台 & 中间件系统，比如 RPC 做事框架 Tesla，数据库中间件 Raptor，可靠的中间件 Corgi，数据库事宜变更中间件 Pigeon，数据配置推送平台 metabase，分布式缓存 kvstore 等等。我们在 15 年第四季度，对于出系统做了整体的做事化拆分。大家可以看下图支付体系 2.0 的整体架构图：
支付体系 2.0 整体架构图
如图所示，我们大致先容下各系统的功能：
面向支付业务拆分为：收银台、交易核心、支付核心、渠道网关
面向资金核算拆分为：账务、司帐、清算、合规
其他根本做事，比如支付会员做事，支付风控和支付对账等。
支付体系 2.0 系统拆分
上文中呈现了支付体系 2.0 的整体架构，我们接下来对各核心系统的拆分和实现进行先容：
交易核心
从刚才的支付链路可以看出，交易核心作为支付系统入口，对接上层的业务系统。在 15 年底，支付系统有着数十张的支付交易表，如何抽取得当业务模型，是我们最主要的事情。其余，为了数据的统一性，我们对分散数十张的支付交易表进行了多表聚合，以及订单关联。同时，支付的接入管控也放在了交易核心实现，整体的架构如下图所示：
交易核心架构图
根本交易类型抽象
交易核心里面如何做根本交易类型的模型抽象？紧张还是基于对于出的理解，如图 2.4 所示的例子中，电商交易的预售 和 广告营销的购买，都是从用户购买直接到收款方。那么我们可以抽象为即时交易，即直接从 a 用户到 b 用户的支付行为。
根本交易类型抽象
基于对业务的剖析理解，我们对交易核心的业务进行了抽象，抽象为 10 多种交易类型：
大家比较熟习的：包管交易、即时交易、充值、提现、包管退款、即时退款、转账等。
以及不太常见的：提现退票、退款退单、非常退款、充值退款等。
多表聚合 & 订单关联
我们对数十张的支付交易表进行多表聚合，是基于一张主表来实现。而在这种情形下，业务订单如何保持唯一是我们须要考虑的事情。考虑到须要对上层业务的极少侵入性，在新设计的支付交易表中，有专门的字段用于做唯一键约束：
业务识别码 + 业务订单号 来进行订零丁一约束。
其余，做了一个小功能，任何订单都可以追溯到初始单，如下图为例，包管交易下的所有的单子都可以找到，同时也能追溯到初始的订单。
包管交易订单关联
支付管控
鉴于交易核心为支付平台的入口，针对 1.x 支付系统中支付接入无授权问题，我们也在交易核心里面做了支付接入的管控，授权 & 鉴权。为任何一个接入支付的业务分配唯一的业务标识码 & 授权的 token。从而使得业务在支付接入时，须带上 token & 加盐过的加密数据传入。
支付核心
我们将 1.x 支付系统里面的支付模块，切分两层，交易核心 & 支付核心。交易核心面向上游业务，支付核心面向支付系统内部。
支付核心整体架构如图 2.6，我们对于出核心同样进行了支付类型的抽象：充值、提现、退款、转账四类，任何一个交易核心订单要求，都能被四种根本支付类型组合进而完成支付行为。其余，支付核心须要基于系统、用户指令等完成各种各样的支付行为。按照大略的做法，我们可以在不同的分支上实现各式的支付行为，但是这样可能会导致支付行为的耦合，以及支付的繁芜逻辑判断。基于这种缘故原由，我们对于出工具进行组件化拆分，封装为数十种支付工具，通过支付编排来实行支付行为。
支付核心架构图
支付行为编排
支付交易订单通过支付规则天生详细的支付要求（即支付核心记录），支付要求通过支付指令编排规则，获取一组支付工具包。通过支付实行器完成对于出工具的调用实行。这样的封装，我们可以实现插件式开拓，以及可支付规则可配置化，继而让支付核心内部的支付工具互不影响 & 系统简化。全体编排过程如下图所示：
支付行为编排
非常处理机制
支付核心有一个比较主要的功能，是如何对于出非常进行处理，支付过程比如重复支付、部分支付、金额不一致、其他非常全额退款等等非常，都须要做非常的退款。
如图 2.8 以部分支付为例，我们做了一个非常管理组件来处理这种非常，在网关支付 + 红包 + 优惠券组合支付中，对每次的支付都进行上报。红包支付、优惠券支付，都成功上报，而对付网关支付非常时，也做非常上报机制。通过非常管理组件对部分支付成功的行为进行反向非常退款。
部分支付非常退款
渠道网关
我们对渠道网关系统进行拆分，渠道网关接管来自支付核心的支付要求，与三方支付进行交互。
网关系统同样抽象了根本做事类型：支付、退款、提现、签约、查询等。同时，为了性能考虑，网关系统切分为两个子系统，网关核心 & 网关前置：
网关核心卖力渠道路由、渠道订单的管理、以及渠道的分组。
网关前置卖力渠道适配、报文转换、以及外部通讯。
整体架构如下图所示
渠道网关整体架构图
资金核算体系
资金核算体系紧张由账务系统、司帐系统、清算系统 和合规系统组成，整体架构如下图所示：
支付核算体系
账务系统：由支付核心驱动，记录管理账户信息，直接反应用户的账户余额和资金变更明细。
司帐系统：对业务运转信息进行管理、核查、表露。 展现资金的来龙去脉。
清算系统：由支付核心驱动，实现机构间资金关系应收搪塞的主被动清算以及资金划拨。
合规系统：基于支付数据，向资金监管方同步交易信息流 & 资金流，从而契合央行合规监管哀求。
截止目前，我们对于出体系的面向业务的系统 & 资金核算体系进行了先容。
统一平台业务高下文
1.x 支付系统单体运用通过确定系统边界、业务建模拆分之后，全体支付平台被拆分几十个做事，而如何保障在做事间流转业务信息不被丢失，是我们须要考虑的问题。就好比如何让各个别系交互时都讲普通话，而不是讲方言。针对这个问题，我们做了平台统一高下文的要素信息（唯一业务标识码），在全体支付平台链路中全程通报，详细要素如下：
商户：诸如 mgj 交易 & mls 交易等。
订单类型：基于交易核心的业务类型，诸如包管交易、即时交易、转账、提现等
订单场景：诸如电商预售、营销广告购买等
支付机构：诸如支付宝、微信等
通过统一平台业务高下文，我们能够在任何一个别系里面清晰看出是哪种业务，在哪种场景下，利用哪个渠道做了什么事情。
直面数据同等性寻衅
在单体运用做事拆分之后，我们碰到了更加严厉的数据同等性寻衅，系统间交各别常、无分布式事务的情形下，数据不一致的情形涌现的概率还是非常大。
那么我们是如何办理数据同等性问题的？总结下来有三个方面：
CAS
在全体支付平台中，我们对可能有并发冲突的系统做了 CAS 乐不雅观锁 ，以交易核心、支付核心为例，通过状态的 CAS 乐不雅观锁防止并发，如下所示：
update PayOrder set status='complete' where id=1 and status='process'
同时，也做了基于 KVstore 的分布式缓存锁来防止多数据之间的并发问题，例如办理重复支付问题等。
接口幂等 & 非常补偿
我们哀求全体支付体系中的所有做事，涉及数据变更的接口都哀求保持接口幂等。通过全链路的幂等，使得重试成为了可能。
在诸如做事超时、网络非常的情形下，我们做了两种不同的非常补偿：基于中间件 Corgi 的准实时补偿 & 基于非常表的补偿。
以支付回调链路为例，如下图所示，渠道网关和支付核心之间的交互，利用的两者补偿的办法。交易核心 对电商交易的支付成功关照办法，我们利用非常表的补偿，在 12 小时内递衰的关照 10 次等等。
支付回调补偿机制
完全对账体系
在支付体系中，对账是数据同等性的末了一道防护。对账可分为两部分：
内外对账，是 1.x 支付系统上线之后已经实现该功能。确保俏丽联合集团支付数据与三方支付的数据保持同等。
内部业务对账，在 2.0 支付体系构建过程中，我们做了一套内部业务准实时对账系统，用于核对全体平台数据。
下面对内部准实时做大略的先容：
内部准实时对账
如下图所示，准实时对账平台支持各种数据源的接入，目前基于系统解耦的考虑，我们更多的利用数据库事宜变更中间件 Pigeon 来接入对账双方的 binlog 数据，通过配置的规则 或者自定义的转换逻辑来进行双方的模型转换，从而通过对账核心进行数据的核对。目前通过该系统，我们可以在 5-25min 之内，创造非常数据。目前支付核心链路全部接入，支付全平台 95% 以上。同时由于对账系统的普适性，目前已经推宽大公司所有业务。
准实时对账平台架构图
基于上述的这些手段，我们能够保障支付系统数据的终极同等性。
疗效？
那么通过对于出体系的升级架构，我们取得了哪些成果？
快速支撑业务。之前在接入新的业务的时候，大概率须要新增交易表以及开拓上线。目前在升级之后，我们基本上只须要进行接入配置即可。
16 年快速领悟淘天下、俏丽说支付系统。在领悟的过程中，新版的支付系统能够兼容当时的淘天下 & 俏丽说支付系统，顺利的完成了领悟。
基于业务接入授权管控 以及平台统一高下文，我们能够对业务进行细分，从而能够对各业务的资金情形进行细分和准确的核实。
通过合规系统的实现，符合央行的资金监管哀求，为用户、商户供应了强有力的资金安全保障。
总结展望
通过对业务的梳理、系统边界的拆分、业务建模等手段，我们完成了对于出体系 2.0 架构升级，进而能够对业务供应更加高效、稳定、专业的支撑。进一步的提升了资金的核算 & 管控能力。但是目前的支付平台里，每个子系统中，或多或少的都存在着自己的配置系统，虽然是基于公用的统一的平台业务高下文，但是配置还是繁琐。如何做到统一化配置也是我们后续考虑的重点。同时，目前平台业务统一高下文的四要素是基于交易核心出发，从目前的系统蜕变来看，我们须要连续改进为更优化的模型，以应对后续更加繁芜的各种业务。
下篇：容量提升
在对美联支付系统升级到支付体系 2.0 之后（支付体系架构演进）。那么我们针对电商平台特性，比如大匆匆时支付链路峰值为日常的百倍以上等等特性，又做了哪些性能和稳定的提升？
下面我们以支付核心链路为例，谈谈如何提升支付平台的性能和稳定性。
支付核心链路
性能提升
针对付电商特性，我们对于出平台的性能提升紧张是从以下几个方面优化：
核心链路分库分表：全链旅程度扩展
做事调用异步化
热点账户问题优化
事务切分
核心链路分库分表：全链旅程度扩展
目前所有的运用做事都是无状态，理论上运用做事可以做到无限扩展，目前最大的瓶颈是在 DB。性能容量的提升，关键在于 DB 的容量。基于这个缘故原由，我们对全体平台的 DB 做了水平的拆分。
在全平台水平扩展的过程中，我们以核心链路为例，从交易核心、支付核心、账务核心、渠道网关等系统全部做了数据库的水平拆分。基于交易核心、支付核心、渠道网关等系统，前面先容过，我们抽象了各种根本模型，数据都是基于一张主表存储，因此水平拆分基于该主表即可。
得益于美联自研的数据库中间件 Raptor，我们实现链路的分库分表。同时，也基于全局统一的 sequence 天生器，保持了所有分片内的主键 id 唯一性。
支付核心链路分库分表
做事调用异步化
支付体系 2.0 升级之后，单体运用拆分为数十个做事。系统的拆分和做事化，实在带来了更多的系统依赖。相对付之前的单体运用，从方法级的调用办法变更为 RPC 做事调用，网络耗时 & 同时网络的稳定性等成分也是须要考虑的问题。基于这些考虑，非强实时的做事调用，异步化是最佳的解耦办法。同样，在核心链路里，我们也做了各种各样的异步化优化，进而提升整体的链路性能，知足电商平台独占的性能特性哀求。
我们从几个点来看下如何对于出系统做异步处理：
支付报
基于数据库事宜中间件 Pigeon & 行列步队 Corgi，我们实现支付报。如图 1.2 所示，支付报基于交易核心数据，聚合支付核心的支付数据，最终生成支付报。通过这种办法，将原来须要在交易核心或者支付核心调用下贱业务方，或者下贱业务方实时查询的办法，转变为下贱业务方通过接管的推送来获取数据，从而达到了业务的解耦。同时，也简化了业务方的数据获取繁芜度。
支付报架构图
目前支付报已经接入了 10 多个业务场景，例如满返，支付成功短信关照，风控所需的支付数据等等，并在持续不断的增加中。
外部支付异步化
在外部支付中，常常会碰到这种情形，须要做事方与第三方支付交互，获取预支付凭据，如图 1.3 所示。这种同步调用的情形下，由于须要跨外部网络，相应的 RT 会非常长，可能会涌现跨秒的情形。由于是同步调用，会壅塞全体支付链路。一旦 RT 很长且 QPS 比较大的情形下，做事会整体 hold 住，乃至会涌现谢绝做事的情形。
同步调用三方支付
基于这个问题，我们对这种获取预支付凭据的办法进行了改进，详见下图：
异步调用三方支付
通过独立网关渠道前置做事，将获取的办法分为两个步骤：
针对于出链路，只是要求到渠道前置拿到内部的支付凭据就结束了。
针对外部要求，由渠道前置异步向三方支付发起要求。
那么基于这种办法，与三方支付的同步交互仅仅会壅塞渠道前置。密集型的 io & 低 cpu 系统，渠道前置的并发值可以设置的非常大。
异步并行
支付平台做事化之后，核心链路上的做事多为 IO 密集型，这里我们以收银台渲染为例，见下图。
串行模式下的收银台渲染
一次收银台渲染，串行的调用各个做事来进行用户信息查询 (RT T1)、额度查询 (RT T2)、优惠查询 (RT T3)，终极实行渠道渲染 (RT T4)，这种实现办法下
收银台的渲染 RT = sum(T1,T2,T3,T4)
但是收银台的渲染 RT 必须要这么久吗？实在对付业务的剖析，我们创造实在很多的做事调用无先后顺序。用户信息查询、额度查询、优惠查询这三个做事的调用实在无先后顺序，那么我们基于 Tesla 做事框架的异步化做事调用，见下图。
异步并行模式下的收银台渲染
基于异步并行的收银台渲染办法，将并行过程中的各做事化的耗时之和变更为耗时最长的一个做事的 RT。
收银台渲染 RT =sum(max(T1,T2,T3),T4)
资金核算体系异步化
目前支付平台里，资金核算体系各个子系统：司帐系统数据来源于账务系统，账务 、清算 、合规数据来源于支付核心。那么，须要在支付核心链路实行的时候同步调用账务 & 清算 & 合规，账务实时调用司帐吗？实在基于对资金业务的剖析，司帐、清算、合规属于非强实时业务，可以通过数据变更中间件 Pigeon 同步数据，对这三个别系进行理解耦，如图：
资金核算体系异步化架构
清算、合规通过监听支付核心 DB 数据变更来获取数据，司帐通过监听账务的流水库的数据变更来获取数据，从而对实时链路非强实时业务进行解耦。
热点账户问题优化
热点账户该当是每一个做支付的童鞋都会碰到的问题。美联的支付系统里，存在这各种各样的热点账户，我们将之分为三类：
内部户：比如渠道的待清分账号等
平台户：比如各种平台的营销的垫支户等
大商家的热点账户等。
每种热点账户的业务属性都不一样，比如商家账户，我们不能延迟记账等等。基于这些情形，我们对热点账户问题优化也基于类型：
内部户
针对付内部户，我们在账务中不做内部户这边的记账，而是由司帐通过其余一边的账务流水去补分录。
平台户
针对付平台户，在账务中做了异步记账，通过定时汇总记账即可。
大商家
比较难的是大商家的热点问题，特殊是在美联这种没有商家结算周期的情形下，每一笔的订单状态变更，都有可能涉及商家的账户资金变更。但是也有办理办法。剖析其业务场景，包管入账、包管出账 、佣金扣费等占用了绝大多数的商家账户操作。针对这块我们分为两个点来做优化：
将商家包管账户切换到平台包管户，基于流水去统计商家包管中的金额。这种情形下，包管入账和出账的商家热点问题可以办理。
第一点的优化能够办理包管出入账的账务操作，但是扣费依旧会造成大量的热点账户问题，对此我们做了一个排序的任务，将扣费做到做到单商家串行 & 多商家并行。
基于上述的两个优化方案，我们办理了大商家热点账户问题。
通过对三种类型的热点账户优化进行，能够办理目前系统碰到的热点账户问题。但是各种平台户的账务流水会非常多，以包管户为例，逐日的所有的出入包管户的流水，都会在这个账户之上，那么在分库分表情况下，会涌现平台户所在的单表巨大无比。在这里我们引入二级子账户观点，将内部户 & 平台户在账务虚化成 N 个二级子账户，从而均匀的分散在各个分表里，进而办理了该问题。
账务记账事务切分
在支付核心链路里，我们对非强实时依赖的做事做了异步化的解耦，对热点账户进行了优化的处理。在账务记账的时候，我们从下面两个问题考虑优化点：
在账务分库分表的情形下，如何担保记账是在事务里？
每次记账的出账 & 入账是否可拆分？
基于这两个问题，我们对记账流程进行了事务的拆分，如图所示：
账务记账事务拆分
出账、入账分离。出账成功，则整体成功，入账失落败可以异步补账。
出账 & 入账 ，每个里面都做单边账、异步记账等处理，全体支付核心链路唯一的一个事务就在于更新账务余额 & 新增流水。
目前系统中，经由这一系列的优化，单次的记账性能，基本上稳定在 15ms 旁边。
稳定性提升
在上文中，我们紧张针对付支付链路的性能做了各种各样的性能提升。资金无小事，如何担保支付平台的稳定性，也是我们须要考虑的重点。我们从下面几个维度来提升稳定性。
监控先行
做稳定性之前，我们须要知道我们的系统运行情形，那么必须要做线上系统的监控，对关键指标进行管控，以支付核心链路为例，如图：
核心链路监控
如图所示，我们监控了核心链路的 qps、rt、并发量等，同时也基于支付核心，我们对依赖的做事 qps、rt 进行监控。其余，也对依赖的 DB & Cache 进行监控。
通过在监控大盘中配置关键指标，能够比较清晰明了的看出目前核心链路线上运行情形。
分离核心链路
基于电商特性，我们对全体核心链路进行了剥离，如图所示：
分离核心链路
对核心链路分离的过程中，我们对链路中的各个做事中切分为核心 & 通用做事。分离的做法实在有很多，比如基于 Tesla 做事框架供应的做事分组功能；比如将一个做事切分为两个做事：核心链路做事和通用查询做事。
在核心链路分离之后，能够确保在任何时候，核心链路不会受到其他通用业务的影响而导致涌现稳定性问题。
做事依赖梳理
目前在支付系统里，有着数十个做事，如果不对做事依赖进行梳理，系统稳定性会得不到保障。我们从下面几点来梳理做事依赖：
梳理平台中的强弱依赖，剖断哪些是强依赖，哪些是弱依赖。
弱依赖做好降级和超时保护，比如收银台渲染是的白付美额度查询，这种可以埋降级开关 & 设置较短的超时时间。由于查不到额度，最多不能利用白付美支付，并不会有特殊大的影响。
如果是强依赖，这个不能降级，怎么办？须要对强依赖的做事提出做事的 SLA 管理，比如账务记账功能，我们会哀求系统不能挂、rt 不能超过 20ms，qps 须要支撑 8k qps 等等，基于这个约定，做子做事的优化。
降级、限流
限流是保护系统不挂的末了一道防线。
目前支付平台里面，存在基于 RPC 做事框架 tesla 的粗粒度限流，可掌握在做事级别和方法级别；基于 spirit 的细粒度限流降级系统，我们可以在单个方法里面做限流降级功能个，如下图所示，我们在包管交易下单过程中，区分平台来源，做到蘑菇街包管交易流量 & 俏丽说包管交易流量。
spirit 限流模式
但是不得不说，单单的 qps 或者并发限流都不能完备的做好限流保护，须要两者的相结合才能达到所需的效果。
其余一点，通过对做事的依赖梳理，我们在各种弱依赖的做事中埋了一些降级开关。通过自研的降级推送平台，一旦依赖做事涌现问题或者不可用，可以快速的对该做事进行降级操作。
压测怎么做？
在对系统扩容，链路性能优化之后，怎么检测成果呢？
我们引入线上压测系统，通过剖析业务场景，构建与线上真实场景险些同等的测试模型。以支付链路为例，模型中以日常 & 大匆匆的流量模型为基准，设计压测模型。须要把稳的是，压测模型越与真实同等，压测的效果越好，对系统把控越准确。。
通过构建线上数据影子库，压测产生的测试数据，会全量写入到影子库中。通过影子库，在复用线上正式业务同等的环境、支配、机器资源下，我们能够做到压测对正常业务无侵入，对系统做准确的把脉。
线上业务也分为两块，一块是单机性能压测，紧张是剖析单机的性能水位和各项指标。其余是链路压测，紧张验证系统的稳定性和做事短板。
通过压测的结果，我们能够对于出平台的性能 & 稳定性短板的剖析和加以改进，能够不断的提升系统的稳定性，提升系统的容量。
疗效？
那么，通过一系列的性能容量的提升，我们达到了什么效果？
平台容量方面：在 16 年双十一的大匆匆压测中，我们在链路 DB 都扩围两组的物理的机器情形下，支付稳定在 3000QPS。由于目前没有需求，我们未对 DB 的物理机器扩到极限，因此系统的极限性能不能完备确定，但是按照预估，理论上可支持 1w QPS 以上。
机器利用率上：相同的容量情形下，我们的运用减少为原有的 1/3。
链路的性能上：如图 4.1 所示，以包管交易为例，交易核心的收单 rt 险些在 10ms，而收银台渲染在 50ms，支付要求在 50ms，支付回调在 80ms 旁边。
核心链路做事性能
同时，基于性能和稳定性的提升，我们做到了支付在历次的大匆匆中，保持无端障的记录。
总结展望
在美联支付系统中，上层支付业务面向电商平台，针对电商特色做更多的业务支持。我们对平台的性能容量探求可改进的地方，比如 DB、Cache、IO、以及异步化，持续不断去优化。其余，资金无小事，如何提升支付系统的稳定性也是重点考虑的方向。
作者先容
陈宗，花名铁手，14 年加入蘑菇街。参与美联支付技能历次重大优化与演进，主导支付体系中交易和支付系统的平台化架构，并持续研讨和改进具有电商特色的支付平台。目前在支付团队卖力支付根本平台架构和研发事情。
互联网讲求唯快不破，飞速的业务发展对做事架构提出更高的哀求，业务须要强大的做事架构来支持更加繁芜、量级更大的业务。QCon 上海 2017全新开启，更多企业架构实践案例，敬请关注。
QCon 上海站目前 8 折优惠报名中，2017 年 08 月 20 日前，立减 1360 元，团购报名更多优惠～点击【阅读原文】跟技能大咖零间隔。欲购票或咨讯问题可联系购票经理 Hanna ，电话／微信：15110019061。
今日荐文
点击下方图片即可阅读
如何口试工程师？
