原文地址:https://mp.weixin.qq.com/s/XtcqFNg1X8SLErfjByHjpw

一、分享主题:

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

背景

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

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

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

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

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

Rework 关于老网关

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

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

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

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

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

虽然已经是13年,但当时百度的支付网关还处于“有啊”时代,后来太子李明远回归执掌MSG,百度钱包又归在他名下。 关于新网关(也就是超级网关)发下以前组里的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: 网关前置会有另一套系统,可以根据后端的支付渠道,动态显示前端需要用户填写的要素,要素的个数,具体要看银行端的要求哈。

 

posted on 2018-03-26 10:28  一天不进步,就是退步  阅读(346)  评论(0编辑  收藏  举报