CN109981748A - 一种基于Kong网关实现的正向代理方法 - Google Patents

Abstract

本发明公开了一种基于Kong网关实现的正向代理方法，第三方数据API接口Consumer以及Kong API网关位于无公网访问权限的内网网段，Kong API网关上运行Forward_Proxy插件，Forward_Proxy插件通过标准Proxy代理服务器连接运行在公网的第三方数据API接口Upstream，所述kong网关上配置Service和Route路由策略，该功能由Kong原生提供，对Service启用Forward_Proxy插件，该插件执行正向代理转发逻辑，由LUA语言实现。本发明能对数量众多的第三方API进行统一地址规划管理，以网关服务的形式向后台应用输出。

Description

一种基于Kong网关实现的正向代理方法

技术领域

本发明涉及计算机技术领域，尤其涉及一种基于Kong网关实现的正向代理方法。

背景技术

在运营APP产品后台技术中，需要与众多第三方供应商的数据API接口对接，以便在自建的数据仓库无法满足用户的查询请求时，便将请求分发至合作方的API接口，以最终为用户提供服务。

最初的技术实现是将第三方的数据接口地址，直接硬编码在各类后台应用代码中，生产环境应用服务器直接与公网的第三方API接口进行通讯，生产环境的所有机器全部能够与外网进行通讯。但现有技术存在以下缺点：

一、维护成本高：

随着公司业务规模的扩大，对接的第三方数据API越来越多，第三方数据源采用的协议、域名、地址各家各样，汇集在一起杂乱无章，毫无规律性可言，对识别、记忆、沟通造成诸多不便。再加上商务合作的变更，也需要频繁修订所有涉及应用的配置文件，维护难度大的缺点逐渐凸显。

二、网络结构：

1、后台应用直接与位于公网环境的第三方API交互，要求所有的后台服务器必须要有公网带宽，能够与公网节点进行通讯。造成生产环境的内外网隔离、网段容量规划不受运维人员主控，需要对应用代码的实现逻辑将就。

2、后台应用与第三方API的交互，跟正常的业务请求处理占用一个网络通道，无法进行流量区分，也无法针对性升级。

三、运维管理:

1、后台应用与第三方API的交互发生在众多应用服务器，网络带宽消耗、连接数、延时、交互结果等数据分布扩散，很难进行统一监控和管理。

2、后台应用在公有云部署时，因需要与公网通讯，无法使用更便宜的内网云主机，必须使用有外网带宽的云主机，经济成本高。

四、性能问题

1、DNS解析造成的响应延迟大。第三方API的接口地址只有少部分是直接使用IP地址，大部分是域名。在与第三方API交互时，操作系统层需要完成大量的第三方域名的域名解析，且因第三方API的CDN、安防策略的缘故，也无法通过建立内部DNS服务器减少公网域名解析代价。

2、防火墙资源消耗增加。数量众多的应用后台服务器，各自频繁主动发起对外的TCP连接请求，造成防火墙NAT地址转换、安全规则匹配、包过滤、日志记录开销增大，防火墙CPU资源消耗居高不下。

发明内容

有鉴于现有技术的上述缺陷，本发明所要解决的技术问题是提供一种基于Kong网关实现的正向代理方法，以解决背景技术中提出的问题。

为实现上述目的，本发明提供了一种基于Kong网关实现的正向代理方法，第三方数据API接口Consumer以及Kong API网关位于无公网访问权限的内网网段，Kong API网关上运行Forward_Proxy插件，Forward_Proxy插件通过标准Proxy代理服务器连接运行在公网的第三方数据API接口Upstream，所述kong网关上配置Service和Route路由策略，该功能由Kong原生提供，对Service启用Forward_Proxy插件，该插件执行正向代理转发逻辑，由LUA语言实现，具体的流程为：

Consumer发起一个对Route地址的Post请求，当匹配Route地址的请求对象到达Kong网关，Forward_Proxy从Kong的数据库缓存对象中，查询到与该Route地址匹配的Service对象，从Service对象解析出Upsream节点的API接口地址；

Forward_Proxy修改原请求对象的Host头部，将Route地址替换成Upsream节点API接口的域名，同时将请求转发至Proxy标准代理服务器；

Proxy收到请求后，从请求对象的Host地址获知请求最终去向，将请求转发至Upstream节点API地址；

Upstream节点收到请求，处理请求，回复响应至Proxy，proxy转发响应至Kong网关，Kong网关增加一些自定义头部，再转发响应至Consumer。

进一步地，所述标准Proxy代理服务器为一个或者多个。

进一步地，所述Upstream节点使用HTTP和HTTPS两种协议。

本发明的有益效果是：

1、引进Kong网关之后，外部第三方的API的维护可以在Kong网关中统一管理维护，对后台代码侵入较少；

2、通过Kong的正向代理转发(Forward_Proxy)插件，后台应用发送至Kong网关Upstream节点的请求，最终被Kong转发给了正向代理服务器，由代理服务器转发给Upsream节点。因此Kong网关和后台应用均可以部署在内网，只需要保证Kong网关跟正向代理服务器和后台应用之间的内网通讯正常即可，方便了生产网络结构和容量规划；

3、在业务层，正向代理服务器可以部署在专门的网络节点，为此实现了正常业务流量跟与第三方API交互带来的流量进行区分，避免在出口带宽和出口设备资源上的竞争；

4、借助Kong网关开源的Prometheus插件进行日志采集，与Grafana配合实现了数据监控可视化，让后台应用与第三方的API交互过程，变得透明可控，方便运维管理。

以下将结合附图对本发明的构思、具体结构及产生的技术效果作进一步说明，以充分地了解本发明的目的、特征和效果。

附图说明

图1是本发明的架构示意图。

具体实施方式

如图1所示，一种基于Kong网关实现的正向代理方法，第三方数据API接口Consumer以及Kong API网关位于无公网访问权限的内网网段，Kong API网关上运行Forward_Proxy插件，Forward_Proxy插件通过标准Proxy代理服务器连接运行在公网的第三方数据API接口Upstream，所述kong网关上配置Service和Route路由策略，该功能由Kong原生提供，对Service启用Forward_Proxy插件，该插件执行正向代理转发逻辑，由LUA语言实现，具体的流程为：

Consumer发起一个对Route地址的Post请求到达Kong网关，Forward_Proxy从Kong的数据库缓存对象中，查询到与该Route地址匹配的Service对象，从Service对象解析出Upsream节点的API接口地址；

Forward_Proxy修改原请求对象的Host头部，将Route地址替换成Upsream节点API接口的域名，同时将请求转发至Proxy标准代理；

Proxy收到请求后，从请求对象的Host地址获知请求最终去向，将请求转发至Upstream节点API地址；

Upstream节点收到请求，处理请求，回复响应至Proxy，proxy转发响应至Kong网关，Kong网关增加一些自定义头部，再转发响应至Consumer。

其中，上述英文释义为：

Consumer：在公司的应用场景，是指各类后台应用，调用托管在Kong网关上的第三方数据API接口；

Kong：Mashape公司开源的API网关；

Forward_Proxy:运行在Kong网关上的一个正向代理转发插件；

标准Proxy:http/https代理服务器；

Upstream:在公司的应用场景，是指运行在公网的第三方数据API接口；

部署时,consumer、kong、标准proxy、upstream所处的网络位置如图1所示，从部署架构图上可以看出，Consumer不是直接向Upstream节点接口发送请求的，而是会经过kong网关和Proxy代理，将请求转发至Upstream节点接口。因此，只需要将Proxy部署在有公网访问权限的网段，consumer和kong都可以隐藏在无公网访问权限的网域内。

配置方法：

1、需要在kong网关上配置Service和Route路由策略，该功能由Kong原生提供。假定：

Route地址为:http://api.example.com/api/v1/poetry

Service地址为：https://api.apiopen.top/recommendPoetry

2、对Service启用Forward_Proxy插件，该插件执行正向代理转发逻辑，由LUA语言实现。

请求流程如下：

Consumer发起对Route地址http://api.example.com/api/v1/poetry的Post请求，当匹配Route地址【http://api.example.com/api/v1/poetry】的请求对象到达Kong网关时，Forward_Proxy从Kong的数据库缓存对象中，查询到与该Route地址匹配的Service对象，从Service对象解析出Upsream节点的API接口地址。

Forward_Proxy修改原请求对象的Host头部，将地址从api.example.com替换成Upsream节点API接口的域名api.apiopen.top，同时将请求转发至Proxy标准代理。

Proxy收到请求后，从请求对象的Host地址，获知请求最终去向，将请求转发至Upstream节点API地址https://api.apiopen.top/recommendPoetry。

Upstream节点收到请求，处理请求，回复响应至Proxy，proxy转发响应至Kong网关，Kong网关增加一些自定义头部，再转发响应至Consumer。

本发明解决的技术问题是：

1、为了解决API管理问题，技术团队引入了Kong网关。并且通过自行研发运行在Kong API网关的Forward_Proxy插件，使得Kong API网关在API管理的基础上，增加具备正向代理转发的功能，以便Kong API网关部署在公网隔离的内网环境时，也能通过与标准代理结合，处理Consumer对Upstream节点的请求，且支持Upstream节点使用HTTP和HTTPS两种协议。

2、Kong并未开源正向代理转发的功能，在Kong的收费Enterprise版本中包含了正向代理转发功能，但当前仍不能支持HTTPS协议。

本发明具有以下优势：

1、引进Kong网关之后，外部第三方的API的维护可以在Kong网关中统一管理维护，对后台代码侵入较少；

2、通过Kong的正向代理转发(Forward_Proxy)插件，后台应用发送至Kong网关Upstream节点的请求，最终被Kong转发给了正向代理服务器，由代理服务器转发给Upsream节点。因此Kong网关和后台应用均可以部署在内网，只需要保证Kong网关跟正向代理服务器和后台应用之间的内网通讯正常即可，方便了生产网络结构和容量规划；

3、在业务层，正向代理服务器可以部署在专门的网络节点，为此实现了正常业务流量跟与第三方API交互带来的流量进行区分，避免在出口带宽和出口设备资源上的竞争；

4、借助Kong网关开源的Prometheus插件进行日志采集，与Grafana配合实现了数据监控可视化，让后台应用与第三方的API交互过程，变得透明可控，方便运维管理。

以上详细描述了本发明的较佳具体实施例。应当理解，本领域的普通技术人员无需创造性劳动就可以根据本发明的构思做出诸多修改和变化。因此，凡本技术领域中技术人员依本发明的构思在现有技术的基础上通过逻辑分析、推理或者有限的实验可以得到的技术方案，皆应在由权利要求书所确定的保护范围内。

Claims (3)

1.一种基于Kong网关实现的正向代理方法，其特征在于：第三方数据API接口Consumer以及Kong API网关位于无公网访问权限的内网网段，Kong API网关上运行Forward_Proxy插件，Forward_Proxy插件通过标准Proxy代理服务器连接运行在公网的第三方数据API接口Upstream，所述kong网关上配置Service和Route路由策略，该功能由Kong原生提供，对Service启用Forward_Proxy插件，该插件执行正向代理转发逻辑，由LUA语言实现，具体的流程为：

Consumer发起一个对Route地址的Post请求到达Kong网关，Forward_Proxy从Kong的数据库缓存对象中，查询到与该Route地址匹配的Service对象，从Service对象解析出Upsream节点的API接口地址；

Forward_Proxy修改原请求对象的Host头部，将Route地址替换成Upsream节点API接口的域名，同时将请求转发至Proxy标准代理；

Proxy收到请求后，从请求对象的Host地址获知请求最终去向，将请求转发至Upstream节点API地址；

Upstream节点收到请求，处理请求，回复响应至Proxy，proxy转发响应至Kong网关，Kong网关增加一些自定义头部，再转发响应至Consumer。

2.如权利要求1所述的一种基于Kong网关实现的正向代理方法，其特征在于：所述标准Proxy代理服务器为一个或者多个。

3.如权利要求1所述的一种基于Kong网关实现的正向代理方法，其特征在于：所述Upstream节点使用HTTP和HTTPS两种协议。