支付系统架构.docxVIP

领取系统架构 区分两个概念:领取和买卖。领取是买卖的一部分。一个简约的买卖过程包括:客户下订单，客户完成领取，商家接收订单，商家出货。这里仅考虑下订单的流程。从软件工程的角度， 我们首先需要明确下几个参与者。 电商系统，指供应在线购物服务的系统。用户在这个系统中完成买卖。 领取系统，可以是电商系统的一个模块，或者是个独立的系统。这是本文的配角，用来完成领取过程。 用户，在电商系统中败家的那位。假如使用银行卡做买卖，那也被称为持卡人。 用户使用银行卡买卖时，发行这个银行卡的机构称为发卡行，或者发卡机构。 商家也需要一张卡，就是大家在淘宝开网店的时候要登记的银行卡，最终需要把用户给的钱打到这张卡上。 和发卡机构相对应的，大家听到最多的是收单机构。如领取宝，微信等第三方领取公司，引见业务的时候总少不了互联网收单的工作。它们把用户订单收起来，找发卡行要钱，就有了收单业务。 主演都有了，下面就是如何演出领取这场大戏了。正常的流程应当是这样： 用户提交订单到电商系统，电商系统对订单进行检验，无问题则调起领取接口执行领取。留意这里领取接口是在服务器端调起的。一般领取接口很少从客户端直接调起。为了平安，领取接口一般要求用HTTPS来访问，并对接口做签名。关于领取接口的设计，我将另起博文引见。 2.领取系统检查参数有效性，特殊是签名的有效性。 4.依据用户选择的领取方式，以及系统领取路由设置，选择合适的收单机构。这里涉及三个概念，领取方式，领取路由。这又是一个槽点。简约说，用户可以选择各种银行卡领取，比如宁波银行卡，但是你的领取系统没有对接宁波银行，那对这种卡，可以选择你接入的，支持这个卡的收单机构来执行领取，如用微信或者领取宝等等第三方领取，或者银联领取等系统支持的方式来执行。这就是领取路由，依据用户供应的银行卡来选择合适的收单机构去执行领取。常用领取方式还包括第三方领取，如微信领取宝等，这种情况下就不需要领取路由了。 5.调用收单接口执行领取。这是领取系统的核心。每个公司的收单接口都不一样，接入一两个收单机构还好，接入的多了，如何统一这些接口，就是一个设计难点。 6.领取成功，收单机构把钱打到商户的账户上了。 商家就预备发货了。 怎样发货，不是本文的重点。 这里关注的要点是， 商家能收到多少钱？ 比如100块钱的商品，用户领取了100块钱（运费、打折等另算），这100块钱，还要刨去电商系统的佣金、领取通道的手续费，才能最终落到商家手里。 这是个Happy流程，一切看起来都很奇特，但实际上步步都是坑，一旦有地方考虑不周全，轻者掉单频发，重者接口被盗刷，损失惨重。 如何避开攻击者修改领取接口参数， 比如100块钱的东西，改成10块钱？ 调用收单接口来执行最终实际领取时，假如领取失败了，比如卡上没钱了，怎样办？ 收单接口把账户上的钱扣走了，但是通知领取系统的时候出错了（比如网络闪断，或者领取系统重启了），领取系统不晓得这笔买卖已经达成了，怎样处理？ 还有好多问题…. 和钱打交道，在任何公司，都跑不掉财务部门。 那财务部门会关注哪些内容？ 当然，最重要的是账务信息。 全部的买卖都要记账，按要求公司都需要定期做审计，每一笔帐都不能出错。这当然不能等到审计的时候再去核对，而是每天都需要对账，确保全部的买卖收入相抵，也就是所说的把账给平了。 这就有三种情况： 电商系统和商家对账；电商系统和领取系统对账；领取系统和收单机构对账。最为领取系统，我们仅关注后两者的情况。 从软件开发角度， 还有一些非功能性需求需要实现： 功能： 特殊是秒宰的时候，如何满足高频率的领取需求？ 牢靠性：不用说，系统能达到几个9，是衡量软件设计功力的重要目标。 99%是基础， 99.999%是目标，更多的9哪就是神了。 易用性：领取中多一个步骤，就会流失至少2%的用户。 产品经理都在削尖脑袋想想怎样让用户抓紧掏钱。 可扩展性： 近年来领取业务创新产品多，一元购、红包、打赏等，还有各种的领取场景。 怎样能够快速满足产品经理的需求，尽快上线来抢占市场，可扩展性对领取系统设计也是一个挑战。 可伸缩性：为了支持公司业务，搞一些促销活动是必需的。 那促销带来的迸发流量，最佳应对方法就是加机器了。 平常流量低，用不了那么多机器，该释放的就释放掉了， 给公司省点钱。 领取的典型架构 所以领取的坑还不少，我们先看看互联网的头牌们是如何设计领取系统的？ 先看看某团的： 再看某Q旅游公司的的： 对比下某东金融的： 最终看看业界最强的某金服金融的： 全体上来说， 从分层的角度，领取系统和一般的业务系统并没有本质的区分，也是应用、服务、接口、引擎、存储等分层。 在应用层，领取系统一般会供应如下子系统： 领取应用和产品.(应用层)： 这是针对各端（PC Web端、android、IOS)的应用和产品。 为各个