业务网关思考

前言

相信现在在微服务思想盛行的互联网行业中，网关这个名词已经是家喻户晓了，很多一线互联网公司都有自研的网关，其主要还是分为两大类 流量网关和业务网关。

流量网关类似于 基于OpenResty的APISIX,基于K8S的 Envoy,Ingress 都是比较好的选择,Kong从理论上讲也算是流量网关,但是性能没有前面的高。 而业务网关 主要以 Zuul,Spring Cloud Gateway以及异步Servelt等方式实现的较多。比如 美团自研的 Shepherd 就是基于Java语言实现的。我也认为基于JAVA实现业务网关是比较容易也比较容易扩展，更容易让其他团队理解和使用。

基于业务需求梳理业务网关功能

如上面提到的 美团自研的 Shepherd ，业务网关的基础功能我就不描述了。那么如何整合公司现现有业务需求，去深入挖掘，将业务需求抽象为一个组件整合进业务网关，也是作为一个资深基础组件开发做需要做的。我这里就是基于现有公司的业务需求去抽象出了一个组件，来满足未来更多类似场景的接口请求需求。

业务描述

基本业务

目前我就职于 一家 国际保险科技公司，为其他国家提供数字化保险金融解决方案。公司有自己的一套保险解决方案产品,但是众所周知,保险的售卖不光靠自己公司，还要寻找其他 销售渠道，比如 支付宝的保险售卖渠道，微信的保险售卖渠道以及手机银行APP等保险售卖渠道等等。因此光有自己的一套产品，不足以满足所有的渠道售卖需求，我们需要根据不同的渠道以及该渠道能满足的售卖保险方式来做定制开发。比如很简单的保险理赔业务，基础架构图如下:

基础struct.png

抛开自营的C端和B端服务不谈,由上方第三方渠理赔可以看出,如果多个渠道商有不同的理赔逻辑或者方式，比如渠道A 只能提供报案人以及保险持有人信息，无法提供赔付人信息，渠道B 能提供报案人，保险持有人以及赔付人信息。那么按照正常来说，渠道理赔服务分别需要给渠道A和渠道B提供两个理赔接口，渠道A则不提供赔付人信息传参，渠道B则提供赔付人信息传参以及校验。如图所示:

理赔基础API.png

业务升级

现在由于保险产品深受大家喜爱，又接入了渠道C，渠道C是大厂商，可以提供所有理赔数据，包括 报案人、保险持有人、被保险人人以及赔付人。可以看到又多了一个入参信息。按照正常的逻辑 那么肯定会针对渠道C单独开发一个API。如下图所示

理赔基础API-C.png

现在来看 是不是还可以 因为最多也就三个API，不足为惧。那么问题来了，由于渠道A系统升级，可以提供被保险人信息，但是！ 只能提供几个基本信息，可能信息给的不是很全。那么很明显 API-C的接口也无法满足，只能升级接口API-A。 那么由于渠道商也在不断更新迭代系统，我们就是不断地适配适配再适配。

是不是很无奈。

组件解决方案

相信多年的老兵看到这里，就想到了解决方案。不错,提供一个统一的接口，包括所有的入参逻辑。让大家都统一调这一个接口不就好了。设计一个统一的接口并不难，难点是在于 各个参数的校验上。有的渠道厂商能提供参数，就需要校验，有的不能提供参数就不能去校验，否则API就过不了。

根据这种需求，我想业务网关的作用就体现了淋漓尽致。我们只需要在业务网关上进行可配置参数校验以及可配置入参。将一个统一的API打散成不同的API，当有某个API需要新增参数时，只需要在业务网关层进行参数设置，将对应的参数 映射到 统一的理赔API就可以了。如下图所示:

升级理赔.png

小结

本文主要是讲解了 某业务的场景以及对应需求变更时所带来的 人力成本和时间成本。针对某业务场景，将基础需求抽象出来，同时设计一个业务网关通用组件来满足当前的需求的思想。下一篇文章将主要针对技术上的预研以及实践进行探讨。