金融网络：渠道（支付通道）接入

我曾在内部宣讲中提问，支付业务最核心的是什么？注意，是业务。

回答的有说是风控安全的，有说支付交易的，有说账务的。其实一个支付业务，能玩的转，能运行的起来，核心基座是机构。拥有核心的通道，就拥有的支付的能力项。有了更多的业务备用通道，

意味着有更好的支付体验和稳定性手段，才有了更大的支付产品竞争力，所以站在我的角度看，支付的核心是通道，是业务起源的基座，这没毛病吧。

什么是渠道网关？

说人话就是将对某个机构的请求交互都放在一个地方，或单独服务，或单独应用包、客户端：

1、与外部交互，以http、webservice、https、tcp等请求方式进行交互的，需要一个对外请求网关。

2、承载外部的账号密码秘钥，请求地址，1v1定制或1v多定制

 

这种多个对外部交互的客户端代码，纯协议对接就完事了呗，那有啥难点需要单独说的？

其实对小公司来说，确实强行干就可以了，相信任何一个刚毕业的选手接起来也没问题。主要问题还是渠道多了之后的管理，与将这些无聊的接入方法抽象出来或者低代码出来，前者是解决稳定性，后者

就是提高接入效率。这其实就是金融网络技术团队要解决的两个kpi了。

 

1、渠道的管理

渠道或者叫通道（改了一年多也没习惯，后面都叫通道），一个三方支付公司，对必要的业务，比如充值、转账、提现，这些都要具备通道能力，需要接一些直连通道与四方聚合通道，一个发展的创业公司

可能会狂接几十个通道，稍大一些的也有数百，拥有这样强大的通道集群，才是稳健的支付基座。当然使用这些通道的通道路由更重要，后面文章会写通道路由。

以我在的团队来说，有几百个支付通道，分别服务给场景业务充值、转账、提现、卡入金、充话费、流量、电力、教育、水、煤气等各类业务，基本就是支付的90业务。

这些通道来自不同机构，拥有不同属性，不同能力，拥有各自的特点，来自多个国家，不同租户，不同主体。

 

主要的挑战是什么？

1、非洲的基础设施差，多个机构容易请求超时，容易不可用，所有网关集中在一起，某个主网关大量超时，哪怕超时时间设为1s，仍会不可避免的将整个网关拖垮，导致其他网关也无线程可用

2、非洲各国计算机水平不一，有的还比较落后，接口协议原始还好，乱改造其实也遇到很多，这也是我之前对外接入时一大困扰，乱改协议又不写明白，交流又说不清楚。需要将这个国家的

协议风格、这个机构的特点能沉淀出来，当遇到这种协议接入时，不求能复用，但求能少踩坑，这是当时的一大出发点

 

网关代码

我觉得这里，大家写代码应该都差不多，懂得分包分层，能够对一些可复用的代码提取出来，做到这些是网关接入的基础。

任何架构想一蹴而就，安享万年，我觉得都不可能。优秀的架构必然是在应用探索中锤炼出来的

 

我们团队也经历了分包挨个机构接入，抽象模版方法，对http/webservice部分请求抽象，然后把对外部分需要写的代码部分尽量减少，如这种：

 定义抽象类

 做前置后置处理器，抽象get/post请求，抽象http/webservice等公共请求方式

 

 

参数这里定义公共抽象：

 如webservice还可以直接转化成结果目标：

 

 

这样在接入网关只需要写：

 

 很不错的抽象写代码的方式吧，像spring一样吧~

 

我们也需要将一些请求量大，又不太稳定的机构通道独立出来，或服务独立，或线程隔离。这里我的做法比较直接，直接服务独立部署（公司业务快速发展，接入效率直接关系抢占市场时间，用小的

服务部署成本换取最稳定可控的解决方案，我认为是值得），之所以这些不用单独线程隔离，可能也跟这几年做架构设计，做业务目的倾向型有关（通过好的技术手段可以做到有效的线程隔离，但能

不能一步做到位，会不会有其他系统稳定性风险这些也需要一些时间来验证，当时创业关键期，团队精力有限）。所以写出了这种代码：

公共spi：

 

 各个网关独立分包，可以独立部署，也可以混合部署。

 

具体写法涉及公司内容，这里不再展示。

 

 

我认为没有十全十美的解决方案，上述这套方案，确实很好的解决了我们业务快速膨胀期的通道隔离。

我们定义了各个业务的spi，我们甚至可以学dubbo一样，将各个接口在启动时通过自定义任务（扫描自定义注解）将接口的属性（接口提供的能力、协议、需要的参数）直接注册给注册中心，注册中心根据能力项提供给通道路由使用。

这样，各个系统的耦合解开，团队分工解开，接入网关的开发，只需要按照抽象出来的spi实现接口并按照约定的响应返回结果，就完成了网关接入。为此，我们还将接入网关这一块，交给了非洲本地的技术进行开

发（之所以用本地技术人员，上文中有说，需要本地与本地人沟通提效）。

 

这样看，是不是一套很不错的接入网关，国内的同学维护通道路由与中间件，前线的同学来按照协议写各种实现，路由可以自主熔断与可用性检测，像dubbo与zk的配合使用一样，可以达到平衡中的完美架构（各团

队有活干，分工明确，各网关可独立和组合，网关与人员都进行了解耦）。

 

 

但是作为技术同学，其实应该都有一些技术追求。我们可以将接入网关这些再优化一下，将这些需要挨个实现的代码再抽象一下，对这些参数以编辑映射的方式注入。通过组件编程式将需要的比如加解密组件、鉴权组件等通过编辑流的方式

快速组建一个网关出来，这样效率会更高一点（但这里可能会让本地的技术人员失去部分写代码的机会），只需要一些人来维护组件的升级与差异性处理。比如我们的方式，通过liteflow（规则引擎+工作流）的方式，将部分接入中的步骤拆解

一下，抽几个组件出来，再将组件挨个编排出来，组建一个快速网关：

 

我认为，网关这一块，只要搞清楚我们的目标点，比如我们想要本地的技术同学参与进去，还是想要彻底的最快的方式来接，还是完全不想单独写代码（要写就写公共的组件）。清楚最后想要的结果是什么，中间的做法，其实都很简单。

最后引用士兵突击里，七连长和自己和解的一句话：有容乃大，无欲则刚。容是别人，欲是自己，这样的天地才跑得欢敞。

我们做技术，应该最大限度的容忍业务发展，没有业务的发展，我们技术工具做的再好再完美，没人用，也不会千古留名，后人奉若至宝，高强的武功秘籍尚需要有人练成无敌证明，我们做技术也是一样！