手哥架构宝典系列：支付系统1.0架构演进

本文主要是介绍手哥架构宝典系列：支付系统1.0架构演进，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

手哥架构宝典系列：支付系统1.0架构演进

陈宗 中生代技术

概述

在过去 4 年的时间里，作为面向亿级用户的大型时尚消费平台，美丽联合集团(简称 美联)历经高速的业务增长和快速的业务演进，其中最重要的基础业务平台——美联支付 稳扎稳打、平滑演进，快速适应并高效支持着业务的复杂变化。我们从单一功能到完整体系，从臃肿的单体 PHP 应用演变为高性能、高可靠、可伸缩的分布式服务架构，于 2016年快速融合美丽说和淘世界支付系统，并在历年大促中保持无故障的出色表现，逐渐摸索出适应全集团复杂业务形态和变化的支付平台架构。

支付系统 1.0

2013 年下半年，蘑菇街从导购平台转为电商平台。为了支撑电商业务，我们快速实现了第一代支付系统。当时，蘑菇街的业务简单、玩法单一。

在这期间，我们实现了面向业务的收银台模块、支付模块，面向资金端的账务模块， 以及与第三方支付对接的渠道网关。如图14.1所示，第一代支付系统只包含了支付最核心的功能:收银台模块、支付模块、渠道网关、账务模块，以便尽快支撑业务。随后几年，美联的业务进入超高速的发展期，电商交易及支付业务的复杂度剧增，玩法多变。同时，在经历数次大促之后，我们发现支付核心链路大促 TPS 峰值达到了日常的百倍以上。在这种情况下，我们其实遇到了很多问题，以下分为 3 部分来说一下我们当时碰到的问题。

当构建支付系统 1.0 时，便设定了支付交易表(比如担保交易、提现等)。但是随着业务越来越复杂，我们添加了越来越多的支付交易表，整个系统的架构是如图 14.2 所示的烟囱型架构。当时，增加一个业务便增加 1~N 张表。

截止到 2015 年年底，整个支付系统存在着数十个支付交易表。这么多表，侧面反映了我们对支付业务并没有做模型的抽象，只是在业务的野蛮生长下不断地应对和接入。同时，在这种情况下，业务的边界很模糊，经常有业务出现这种情况: 一半的业务逻辑实现在业务方，一半的业务逻辑实现在支付系统。

当时，整个支付系统都在一个巨大无比的单体 PHP 应用里。虽然系统在演进，也分出了不少模块，但是大家知道，在一个巨大的单体应用里比较容易出现各模块耦合的情况， 比如支付模块调用了渠道网关模块的一个内部方法等。另外，支付团队的几十位同事每天都在一个应用里做着开发-发布的工作。任何一个地方出问题都有可能让支付系统崩溃，稳定性非常低。最后，电商平台的特性决定了我们必须要不断提升支付系统的性能。在2015年的时候，我们对支付系统的数据库进行了基于模块的垂直拆分，以用于提升系统容量， 如图14.3所示。

但在这种情况下，我们还是遇到了性能瓶颈。例如，2015 年的双 11，当时的目标是系统能够支持 2000TPS 的峰值支付，但在数轮链路压力测试之后，即使我们对数据库进行了 垂直拆分，并使用了最好的硬件 Fushion-io，系统也仅能支持大概 1800TPS 的支付。当时其实是比较绝望的。我记得在 2015 年 10 月底到 11 月初的这段时间里，大家没日没夜地紧急对支付系统的担保交易下单进行了改造，添加了一系列的缓存，最终使性能勉强能够达标。

在第一代支付系统中，我们对各个业务方的支付接入并未提供任何授权和鉴权。也就是说，任何系统、任何团队都有可能调用支付系统接口进行资金操作。当时，支付有一个万能的转账接口，对业务方接入来说确实很方便，但其实埋下了很多潜在的问题。虽然当 时对支付业务做了日志记录，但是在数据库里并未能区分业务来源和操作类型，导致我们 对各项业务的流水、收入、支出难以统计和核算。
另外，我们也遇到了数据一致性挑战。当时，支付系统仅有内外部渠道对账，而对内部的业务数据没有做好对账事宜，经常是在用户反馈异常问题后我们才能知晓。

• 预知后事如何，且听下回分解 -

这篇关于手哥架构宝典系列：支付系统1.0架构演进的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！