一、主题分享

    我就简单谈一下网关吧，经验还不是很丰富，大家多多批评指正。
    网关起的是入口分发的作用，支付网关也是。类似一般的银行的前置系统。这个分发就理解路由，不管是消息驱动的各种业务类型的路由，还是在具体的业务类型（比如交易类型）中的交易渠道路由。现在有的公司已经把路由系统分出来独立的服务，当然我们现在在向这个目标在改。
    第二个，我觉得是报文的转换，一般看服务暴露出去的接口需求是怎样的。一般涉及线上的业务基本就是http的rest或者webservice接口。如果线下的比如pos收单的就是tcp类型二进制交易报文。这些报文都是暴露给客户端的，到网关一般需要转换成内部报文，内部报文再转换发送银行或者银联等渠道端，最后返回给客户端还需要再转换报文。
    第三个就是一些参数的校验，包括客户端上送的各个业务字段的初始校验。还有就是硬加密或者软加密的签名验证。这个可以在网关做或者独立加解密服务。还有就是风控阻截，调风控服务，或者后台管理系统配置风控参数入表，然后网关读取判断。还有通知，对客户端也包括内部系统的各种通知，比如短信、邮件、http回调，异步消息通知。当然还有各种业务类型服务的监控，比如zabbix，cat什么的。
    大概我理解的网关就是包括这些吧，我是从开发的角度来说的，不是很深度，各位轻拍。

二、Q&A

Q:我有个问题，我之前做过api网关，你们这个后置的渠道网管是怎么做到水平扩展的？你们http的话走的是专线吗？
A:基本是网关rpc调渠道端，扩展的话，就是多部署几台暴露虚拟IP出来。只有银行的8583走专线，Http不需要
S:我可能没问清楚，我的意思是，假如你们这个时候又接入了一个渠道，后置渠道网管怎么扩展？是再写一套代码还是通过配置就可以添加新的渠道
A:直接后台管理系统配置
A1:正常配置渠道应该不需要再写代码了
S:嗯嗯，这样挺好的，不需要重复撸代码写新的渠道配置。我之前想过通过xml文件来配置，做到渠道网关自由插拔。简单的来说就是通过key去差value，value就是你要跑的代码，key暴露给调用者的

Q:用的容器吗
A:容器是开发时候docker

Q:请问您是怎么根据路由决定跑哪块代码的呢 ？
A:是paychannel paytype等几个字段然后对应的渠道url
A1:我们用接口号判断的

Q:用反射去找到对应的类？
A:渠道有报文的转换
A1:也不用，你访问csdn首页怎么访问？
S:那咋整？这样能做到代码零开发？
A1:是不是有个url？网关也是这样的
S:那用的啥框架
A1:之前做的APi网关和渠道网关可能有区别 的，我之前用过kong，Beego。这个不是java的，java的话用过一个wso2的网关。那个比较重
A2:我猜测，新增加0代码开发的前提是新的渠道和旧有的渠道代码完全一致。既然项目本身是支付网关，它本身是封装所有渠道供客户使用的，我觉得对于客户来说应该是只需要调整参数就可以，但对于它本身，必定要针对新的渠道进行具体的开发，至于开发代码工作量，要取决于项目本身的现状和逻辑了。
A:基本上目前就是的，解析网关报文和渠道端请求回网关的都是sdk给到渠道端了。就像银行的esb通信方式差不多的
A3:配代码我也见过，常规模板变量配置，配制sql，配置代码都见过
A1:这个就看渠道网关设计的弹性了。通常，根据渠道的不同设置不同的规则，然后容器加载这些规则。进行校验。传入的就是需要校验的数据
A2:对，有些产品历史悠久，又没有足够的人手去重构，所以现状真是一言难尽的
A1:所以我就想能不能够通过编写一系列规则集来解决不同渠道的差异问题，尽量少写代码
A3:你干脆eval 下
A1:目前在脑子里想着架构方案，看看能不能搞个通用的平台。应该说是设计方案
A2:通用平台我觉得在技术上肯定是可以实现的，但敏感性、压力和负载还有政策等等都不太好办吧
A1:这个我都不知道了，哈哈

本文档来自支付产品技术交流群的聊天记录整理，由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验（2年以上）的产品经理、软件工程师、架构师等，提供交流平台。如想加入本群，请在本文评论中留言（不公开），说明所在的公司、负责的工作、入群分享的主题和时间。