一、分享主题：
这次主分享的是百度钱包超级网关从0到1的过程。因为已经很久没做支付相关的内容，这次没神马干货，主要是讲故事哈哈。
背景
先说下当时的团队成员，百度钱包上海的核心人员绝对是支付业内的黄金战队，大老板是里志仁（支付宝的高经），架构师是丁雪丰（业内知名技术著作译者，来自支付宝），网关团队的负责人是熊总（支付宝网关团队核心成员），以及其他两个团队的teamleader 也统统是支付宝过来的。
不夸张的说，因为这些大牛，百度的网关体系从一穷二白直接飞跃至业内超一流的水准。
举个栗子：
14年、15年双11活动的时候，我们发现根本没有加班的必要，因为整个百度体系以及外部商户（聚美等等）加起来的交易量根本无法对我们网关造成任何冲击，哪怕是一点点涟漪都没有。
btw.不过出现过银行自己hold不住的情况。没做支付之前，我以为银行的系统应该是中国最安全的系统，做了支付之后觉得银行系统真是够稀烂的。
我先是作为RD参与前期支付渠道的接入工作，后来作为渠道接入总负责人（其实就是个干杂活的项目经理哈哈），负责银行渠道、第三方支付渠道接入工作；协调公司内外部资源，推进北京上海超过10个团队跨地域紧密合作，1年左右的时间完成了国内TOP15银行的接入及老网关迁移工作。
Rework 关于老网关
-
【维护成本】 现在的网关工程结构相对比较乱，每新建一个渠道都会写一个工程， 这样管理起来相当的麻烦，维护成本相当的高，不易人工管理和定位问题。
-
【运营部署】部署上基本上是一个渠道打一个包，发布到应用容器中，这个需要知道熟悉的人对这个部署结构了解才知道哪个渠道在哪里，人力上解决起来有相当大的困难。
-
【统一化】工程不同导致渠道提供给上层的访问地址什么的都是不同的，这样上层php维护这套地址池的时候不够统一，并不能形成一套抽象平台化的服务，服务量级出来后。
-
【代码质量】基本是没有写单元测试的，代码质量上不能保证。
-
【扩展性】主要是从渠道扩展方面来讲，没有通用的模式，基本上是来一家开发一家，业务模式无法复用，导致大量的人力成本。
虽然已经是13年，但当时百度的支付网关还处于“有啊”时代,后来太子李明远回归执掌MSG，百度钱包又归在他名下。 关于新网关（也就是超级网关）
发下以前组里的PPT
此ppt为组内材料，原作者熊照
关于路由
关于通讯
关于报文
推进路线
重0搭建新的网关体系==>基于业务需要扩充支付渠道==>见缝插针的进行老网关渠道的迁移工作
血泪史
-
在接入支付渠道的过程中踩了无数的坑，后来也因此要求PM必须提供产品/清算的checklist。（顺便推荐下《清单革命》这本书，内核很不错，但老外书的毛病就是废话炒鸡多）
-
因为对接银行，国企的效率实在低下，有的银行的测试账号竟然要配制一个月才能给出，最惨的一次是开测试环境被银行拖了2个月。而我们的项目往往是倒排项目。因此，我们搭建了自己的AnyMock系统，用于模仿银行or支付公司的返回报文，提前通过anymock开发测试，紧急情况下用预发环境对接银行测试环境回归。
另外前置，通过checklist保障资源全部到位后（文档、专线、测试卡号、对接研发等等），再启动开发。
这次准备比较匆忙，~时隔多年，很多细节已经不是很清楚了，如有谬误，请多谅解。[坏笑]这次分享就这些湿货了~~
二、Q&A
Q1:问个比较低级的问题，你们新增一个接口服务和渠道需要多久，新增接口需要进行重启吗？
