网联架构设计的四个关键选择

非银行支付机构网络支付清算平台（以下简称“网联平台”）自2016年8月启动筹备工作，一开始就面临几大技术挑战：为支持高速发展的网络支付业务，平台并发交易处理能力要达到12万笔/秒，极值处理能力18万笔/秒；为了保证用户的良好体验，平均交易响应时间要低于1秒（包括银行的处理时间）；为了保证业务持续平稳运行，系统在线可用率要达到99.99%，并能够承受城市级的灾难。同时投产时间窗口计划在2017年3月31日启动试运行。如何在这么短的时间里，从无到有地建设一个高质量的金融市场基础设施，成为网联建设者们必须要解决的一个问题。打仗时，兵马未动，粮草先行，反映在平台建设上就是架构先行。以下就网联平台总体架构中的四个关键选择（分布式架构、多点多活的三地六中心、机构多线多活接入以及平台/机构协同路由）进行说明。

集中式VS分布式

        第一个关键选择就是使用分布式还是集中式架构。集中式架构是目前金融系统广泛使用的架构，大多使用大型机和小型机组成集群。目前已知最优秀系统（如Visa、MasterCard）的极值处理能力达到了6万笔/秒，远远达不到网联平台18万笔/秒的要求。相对于集中式架构，分布式架构普遍使用PC服务器组成集群，集群内节点数量远远大于集中式架构下的集群。服务器单点故障时，隔离故障所带来的影响大大降低，容错容灾能力大幅提升，扩展性好而成本却大幅降低。同时，分布式架构已经在市场上被充分验证可以支撑极大交易流量，例如支付宝2015年“双十一”交易峰值达到8.59万笔/秒，财付通2016年春节交易峰值达到15.8万笔/秒。两相对比，分布式架构成为网联的必然选项。

网联的数据中心如何合理布局

        统计表明，支付机构和银行的数据中心体现出较强的聚集性，即大多分布在北京、上海、深圳3个城市。为了减轻机构、银行接入成本，降低平台与各参与方之间的通讯时延，进而提升交易响应速度，这三个城市也就成了网联数据中心落地的优先选择。同时，由于工期紧，自建数据中心不可行，租用市场上成熟的IDC服务也就成为必然选择。

        选定城市后，项目组深入研究了“两地三中心”和“三地三中心”两种经典成熟的方案。“两地三中心”是传统的一主一备一灾备架构，要求每个数据中心能够处理全量交易；“三地三中心”则是两个处理中心+一个控制中心的架构，由处理中心负责交易的实时转接，交易实时处理完成后上送控制中心进行清分汇总轧差，这就要求控制中心具备全量交易处理能力。这两个方案对单中心的性能要求很高，即使是支付宝、财付通其时也没有在一个中心处理18万笔交易/秒的经验，其可实施性和可扩展性难以保证，因而未被采纳。

        从分散处理压力、提高系统冗余、保障业务持续可用等方面考虑，网联决定采用多活的架构模式，即网联在各地的数据中心同时处理支付机构发送的交易请求。那么，这些多活数据中心到底部署在几个地方合适呢？一地多个中心因为不能承受城市级的灾难而不被考虑。“两地多活”方案与“三地多活”方案对比，为了承受城市级灾难，“两地多活”需要提供一倍的冗余处理能力，而“三地多活”方案只需要提供50%的冗余。从节省成本考虑，“三地多活”方案胜出。“三地”以上的方案因为工期、资源原因，暂时无力考虑，后续扩容时再行定夺。

        选定三地多活方案之后，为了增加城市内的冗余，参照同城双活模式，决定在一个城市建设两个数据中心。同城两个数据中心相距20~30公里，既有效隔离市电故障，又保证两中心之间的光纤传输速率得到保障。最终网联初期建设选择了在北京、上海、深圳三地租用6个数据中心来承接网络支付转接清算业务，每个数据中心需要提供3万笔/秒的处理能力，现有技术完全可以实现。

参与机构如何接入网联平台

        在居间转接清算模式下，网联平台前接支付机构发送的支付请求，后转各家银行完成资金结算，上连清算总中心大额支付系统完成银行间资金清算。大额系统有其特定的接入模式，网联平台遵章执行即可。机构和银行如何接入还需费心考量。

        先来看看支付机构的接入。目前，115家机构具备网络支付、移动支付牌照，在市场份额上体现出极为明显的寡头效应，支付宝和财付通（“两大”）两家占据了90%的市场份额，其后7家机构占据了9%左右的市场份额，剩下的1%市场份额由其余100多家机构瓜分。因为规模巨大，两大的接入是网联平台必须要直面的技术挑战。而类似规模、不同机构的系统间对接，业界尚无可参考的案例。因此必须考虑周全如何破局。

        首先，一地一中心和一地两中心接入因不能承受城市级灾难而勿需考虑。机构必须要接入网联平台的多地多中心才能留有足够的冗余。其次，因为两大的交易流量占据平台流量的绝大部分（特别是在流量峰值时），为了最大化地利用网联平台各个数据中心的处理能力，两大的流量必须平均分配到三地六中心，否则就不能充分利用网联平台的处理能力。而其他机构因为交易量有限，可以通过机构间的统筹安排来达到均衡交易流量的目的。最后，从线路利用率、容灾能力、成本几个角度来看，多活线路天然具备优势，缺点是对机构的技术和运维能力要求较高。

        最终平台确立了基于平台分配、跨地域和跨运营商三大接入原则，根据支付机构的业务规模以及能力水平，要求大型支付机构采用6线接入网联三地六中心，中型支付机构至少采用4线接入网联三地四中心，小型支付机构至少采用2线接入网联异地两个数据中心。各家机构在所有线路上要做到流量平均分布，以最大化地利用网联三地六中心的处理能力。

        过程中也有人提出一点接入、平台内部分发的方案。实现这个方案需要满足以下几个条件：线路带宽要能支持机构的业务峰值；至少需要一条同带宽的备份线路；每个中心需要和其他5个中心保有足够高的带宽；平台要确保每笔交易分发目的地的一致性。

        满足前两个条件会给支付机构带来更高的成本。因为从一个接入点分发交易时大部分流量需要跨城跨省，满足第3个条件平台需付出很大线路成本。满足第4个条件平台需要实现复杂的分发逻辑并要能在接入点支持18万笔/秒的流量分发，需要较大的带宽投入、设备投入和研发投入。从节约成本、保证工期、科学合理的角度出发，该方案最终未被采纳。最重要的是，多活线路接入方案是在互信规则安排下，从为股东负责、为结果负责、为最大程度降低社会成本的角度出发，既不影响处理效率，又能最大程度集约成本，这个方案兼顾效率、性能、成本三者的最大公约数。

        再来说说银行的接入。相对于支付机构，虽然银行在市场份额上仍然体现出头部效应，但是并没有形成寡头，五大国有商业银行占据了70%的市场份额，12家全国性商业银行占据了20%的市场份额，其他银行的市场份额为10%。目前，大部分银行具备了两地三中心的能力，有些具备了双活的能力，极少数具备了多点多活的能力。和支付机构的接入原则一致，网联要求国有商业银行和全国性商业银行采用6线接入网联三地六中心，其他商业银行至少采用2线接入网联异地两个数据中心。

支付交易如何高效地路由

        多活分布式系统使用方和提供方之间的交易路由方案一直是业界热门的话题，其核心问题是如何保证单笔交易的路由最终性。如果不能保证，则会造成同一笔交易被路由到不同的数据中心多次重复处理，导致资损和/或重复扣款，引发客户投诉，以及后续一系列问题。目前业界大致有如下三类解决方案。

        1.使用方自行生成交易流水号

        交易路由完全由提供方负责，使用方一概不管。提供方收到一笔交易后，为了确保该笔交易的路由最终性，需要在全平台进行防重检索。如果存在，则使用已有路由转接处理。否则，选择一个新的路由来转接处理。该模式的优点是使用方实现简单，提供方完全可控。缺点是每笔交易都要进行全平台检索，随着交易规模的不断增长以及数据中心地域上的扩展，提供方的整体稳定性难度、技术实现复杂度、运维成本以及响应时间都会逐步增长。基于以上缺点，该方案在大规模、高并发、跨地域的分布式系统中很少采用。

        2.使用方向提供方申请路由标识后生成交易流水号

        对比方案1，提供方不用做全平台防重检索，只需在路由标识指向的处理集群内检索即可防重。但使用方增加了一次和提供方的交互，同时还要保证每笔交易的路由标志一旦确定即不可更改，否则会造成交易的重复处理。在大流量、多地多中心场景下，由于取消全平台检索带来的性能节省远大于路由标识申请的性能消耗，最终结果是处理性能的提升。这是财付通目前使用的方案。

        3.使用方按照提供方制定的规则选择路由标识生成交易流水号

        对比方案2，虽然使用方还是要保证每笔交易的路由标识一旦确定即不可更改，但是节省了跨系统的路由标识申请交互。缺点是使用方需要维护路由标识列表，提供方对路由的控制力下降，需要信任使用方按照规则行事并有足够的防冲击能力。目前Amazon.com、PaymentTech以及多数双活系统采用此种方案。

        打个比方，防冲击能力是厂房，一次建设，长期使用；维护路由标识列表是生产设备，需要定期维修保养。以上两项属于固定成本。使用、申请路由标识和防重检索则是生产工序中的一环，属于变动成本。众所周知，规模达到一定程度之后，固定成本会被摊薄，变动成本的节省则会持续积累，超过临界点之后，变动成本节省将会远远大于固定成本。

        在我们的场景中，网联平台是提供方，支付机构是使用方。基于网联平台超大规模、超高并发的特点，网联决定用固定成本投入换取变动成本的持续节省，最终选择了方案3，并进行了进一步的细化、优化。具体来说，路由标识指向了一个数据中心中的一个数据库中的一个表，带来的好处就是交易防重只需要检索一张表，相比较库级和数据中心级的防重，因为需要检索的数据量级上的减少，性能得以大大提升。付出的代价就是网联平台需要在多维度上建立防冲击能力，支付机构则需要按照网联规则维护和使用路由标识列表。规则其实很简单，机构定时拉取路由标识列表，接收到特定系统返回码时停止使用当前路由标识并拉取最新路由标识列表，采取轮询或随机的方式平均使用路由标识。

        为了节省资源，最大限度地发挥平台的处理能力，平台要求支付机构在平台运营初期进行交易发送时，能够尽量平均地分配到三地六中心，以实现全平台六中心能够承接每秒18万笔极值交易流量的目标。同时，平台配套建立了限流规则，保障按照平台规则操作的支付机构的利益，最终保护广大消费者的权益。网联平台是广大支付机构按照“共建、共有、共享”原则一起建设起来的，我们相信所有参与机构都会遵从契约精神和共同认可的平台规则，共同保障平台持续、稳定运行。未来，平台将基于自身的运营情况，通过迭代优化的方式，更好满足支付机构和银行的服务体验，根据业务增长需要持续稳健地推进极值交易流量处理能力的不断攀升。

        综上所述，遵从分布式架构思想，网联建设了多点多活的三地六中心，实施了参与机构多活线路接入方案，确立了平台/机构协同路由模式。2017年3月31日平台上线了基本业务功能，顺利启动试运行，6月30日大型支付机构正式向平台启动业务切量。同时，平台系统经过了多轮的压力测试和生产压测，完全满足设计要求，为后续按照央行要求终结直连模式奠定了坚实的基础。

        展望未来，网联将持续迭代优化平台架构，进一步健全交易路由方式，逐步实现资源松耦合，解决生产运维中出现的各类问题，通过不懈地技术演进，努力将网联平台打造成国际领先的分布式金融市场基础设施，助推金融科技领域分布式架构转型，助力构建以分布式系统为核心的数字央行服务平台，为建设更加先进、强健、稳定的国家金融支撑体系做出贡献。

（文章来源：金融电子化杂志） 

扫码即可手机
阅读转发此文