一、分享主题：

这次主分享的是百度钱包超级网关从0到1的过程。因为已经很久没做支付相关的内容，这次没神马干货，主要是讲故事哈哈。

背景

先说下当时的团队成员，百度钱包上海的核心人员绝对是支付业内的黄金战队，大老板是里志仁（支付宝的高经），架构师是丁雪丰（业内知名技术著作译者，来自支付宝），网关团队的负责人是熊总（支付宝网关团队核心成员），以及其他两个团队的teamleader 也统统是支付宝过来的。

不夸张的说，因为这些大牛，百度的网关体系从一穷二白直接飞跃至业内超一流的水准。

举个栗子：

14年、15年双11活动的时候，我们发现根本没有加班的必要，因为整个百度体系以及外部商户（聚美等等）加起来的交易量根本无法对我们网关造成任何冲击，哪怕是一点点涟漪都没有。

btw.不过出现过银行自己hold不住的情况。没做支付之前，我以为银行的系统应该是中国最安全的系统，做了支付之后觉得银行系统真是够稀烂的。

我先是作为RD参与前期支付渠道的接入工作，后来作为渠道接入总负责人（其实就是个干杂活的项目经理哈哈），负责银行渠道、第三方支付渠道接入工作；协调公司内外部资源，推进北京上海超过10个团队跨地域紧密合作，1年左右的时间完成了国内TOP15银行的接入及老网关迁移工作。

Rework 关于老网关

1. 【维护成本】 现在的网关工程结构相对比较乱，每新建一个渠道都会写一个工程， 这样管理起来相当的麻烦，维护成本相当的高，不易人工管理和定位问题。

2. 【运营部署】部署上基本上是一个渠道打一个包，发布到应用容器中，这个需要知道熟悉的人对这个部署结构了解才知道哪个渠道在哪里，人力上解决起来有相当大的困难。

3. 【统一化】工程不同导致渠道提供给上层的访问地址什么的都是不同的，这样上层php维护这套地址池的时候不够统一，并不能形成一套抽象平台化的服务，服务量级出来后。

4. 【代码质量】基本是没有写单元测试的，代码质量上不能保证。

5. 【扩展性】主要是从渠道扩展方面来讲，没有通用的模式，基本上是来一家开发一家，业务模式无法复用，导致大量的人力成本。

虽然已经是13年，但当时百度的支付网关还处于“有啊”时代,后来太子李明远回归执掌MSG，百度钱包又归在他名下。 关于新网关（也就是超级网关）发下以前组里的PPT

此ppt为组内材料，原作者熊照

关于路由

关于通讯

关于报文

推进路线

重0搭建新的网关体系==>基于业务需要扩充支付渠道==>见缝插针的进行老网关渠道的迁移工作

血泪史

1. 在接入支付渠道的过程中踩了无数的坑，后来也因此要求PM必须提供产品/清算的checklist。（顺便推荐下《清单革命》这本书，内核很不错，但老外书的毛病就是废话炒鸡多）

2. 因为对接银行，国企的效率实在低下，有的银行的测试账号竟然要配制一个月才能给出，最惨的一次是开测试环境被银行拖了2个月。而我们的项目往往是倒排项目。因此，我们搭建了自己的AnyMock系统，用于模仿银行or支付公司的返回报文，提前通过anymock开发测试，紧急情况下用预发环境对接银行测试环境回归。

另外前置，通过checklist保障资源全部到位后（文档、专线、测试卡号、对接研发等等），再启动开发。

这次准备比较匆忙，~时隔多年，很多细节已经不是很清楚了，如有谬误，请多谅解。[坏笑]这次分享就这些湿货了~~

二、Q&A

Q1:问个比较低级的问题，你们新增一个接口服务和渠道需要多久，新增接口需要进行重启吗？

A1: 百度的超级网关其实就是支付宝那套体系，如果报文加解密不复杂，一般一个渠道（鉴权、支付、退款、接绑卡的4、5个接口）快的话一周就能做完，主要是百度的测试还是蛮细致的，所以一个项目是两周左右，如果银行不掉链子的情况下哈，很少有单独接一个接口的

A2: 我们这边做的是在需要验证的字段加验证注解

A3: 不需要重启，用的是groovy动态加载spring容器，我们后期上一个项目，只要写一些SQL就可以支持一家渠道了，可以在线刷新缓存，不需要重启服务

A4: 类似这样，把代码写在SQL里，上线只需要数据库跑下脚本，刷新下缓存就可以了~

Q2: 请问一下，统一门面之后，前台传进来的字段是按业务的必要要素，还是将所有渠道的所需要的字段做一个并集，比如鉴权有些是四要素，有些是六要素，有些是三要素

A1: 网关前置会有另一套系统，可以根据后端的支付渠道，动态显示前端需要用户填写的要素，要素的个数，具体要看银行端的要求哈。

来源丨凤凰牌老熊