平台公共API服务网关方案选型

技术研究报告

Contents

1. 需求分析 2

3. 现有技术分析 6

3.1. 主流API服务网关简介 6

3.2. 常见方案比较 7

4. 选型及可行性研究 9

4.1. 选型 9

4.2. 可行性研究 11

5. 总结 21

需求分析

宏观上，平台须实现多用户、高可用、高并发、高负载、微服务化、容器化的应用目标。微观上，采用基于服务化的技术架构，体系中包括基于原生微服务架构实现的子服务和粒度较粗的子服务，对于各类服务一方面需要对服务解耦以提高其可复用率、可伸缩性和高可用性，另一方面整个系统需要依照不同类别、不同层次组织、集成和管理不同粒度的服务。

在传统架构中尤其单体应用中认证和监控需要深入到服务内部，常常要在模块执行前认证用户并校验权限，在模块执行过程中输出状态信息以便收集监控数据，这样加大了与认证和监控模块的耦合度也拖慢了业务模块运行效能。而对于新型服务化架构，尤其是微服务和云原生架构，通常会将认证、监控、限流、熔断、缓存等工作交由微服务网关或云原生Sidecar Proxy完成。

基于下平台的总体规划可看出，由Java开发的微服务系统采用Dubbo实现微服务治理，但是还其它一些不同类型不同粒度的各类也需要相应的服务治理，最终还需集成和标准化各种不同类型的服务接口以对外提供完整划一的API服务。

参考Figure2-1，在不同的服务和应用区域边界上需要API服务网关作为关键枢纽实现服务集成、接口映射、动态路由、安全、监控、负载均衡、高可用、热数据缓存、流量控制、熔断保护等重要作用。现代化API服务网关是将云平台中各类服务和应用安全、高效、可伸缩、高可用、标准化、系统化地集成为一个有机整体的最关键部件之一。

Figure 2‑1公共API网关内外接口映射与服务集成示意图

公共API网关

用户管理服务内部API

订单管理服务内部API

支付管理服务内部API

编目查询服务内部API

在线工具服务内部API

在线浏览服务内部API

用户注册公共API

用户登录公共API

用户注销公共API

订单查询公共API

订单更新公共API

编目检索公共API

切片服务公共API

其它公共API

其它内部API

Application Services

GIS Services

Other

下面逐条分析公共API网关的功能需求。

服务集成：所有面向服务架构（SOA）包括当今最热门的微服务架构以及云原生架构都必须解决服务集成问题，即便是将企业内部遗留系统和各类新型系统整合的任务，都可以或需要由服务网关来实现。接口映射与动态路由：对于非单体应用的服务和应用系统，在不同服务区域通常都有不同的服务协议，跨越不同区域获取服务时需要相应边界上服务网关实现对来自不同区域的请求和响应进行变换和映射并实现动态路由功能，使得不同区域服务能够跨区域请求并获得有效响应结果，由此真正实现多元系统的有机整合。安全与监控：网关是不同服务区域间的堡垒，尤其是公共API服务网关工作在公共区域（非可信区域）和私有区域（可信区域）之间，它是直接面对来自非可信区域无效请求、错误请求、非法攻击、或超高负载有效请求的“前沿阵地”。云平台系统需要网关对各种请求第1时间进行用户认证、权限鉴别并采取一定安全措施在第1时间控制并记录用户行为以便事后审计。网关系统第1时间拦截无效请求也可以使用后台服务模块可以专注于其自身业务功能，功能更专一，与其它模块如认证模块等尽量解耦，为整个系统实现高性能、高复用、高伸缩打下坚实基础。负载均衡与高可用：在用户量不断增大和某些系统不稳定时，大型服务和应用系统要求整体系统具有高性能和高可用能力，这需要现代化网关可以赋予系统负载均衡和高可用能力。热数据缓存：作为跨域系统的前沿网关可以第1时间感知和区分冷热数据，适当地将热数据就近缓存在网关可及的高速设备上，对于重复请求第1时间就近从高速设备上直接“复用”以前的结果是提高整个系统能力最佳手段。例如无缓存的地图切片服务能力通常严重受限于磁盘IO和网络存储的带宽瓶颈，而对于多次请求的热点切片如果利用内存缓存结果直接提供服务则可提速近1000倍，当然并非所有情况都如此理想，具体情况仍需依具体场景决定。流量控制与熔断保护：流量控制可分为1）商业模式驱动的对不同级别用户的主动流量控制和2）系统性能优化驱动的流量控制2类。这些都可以由网关实现。过高的请求量可能直接导致某些后台服务吞吐能力急剧下降甚至崩溃，然后导致连锁反应使得整个平台所有服务崩溃。尽管好的服务限流和削峰处理可以尽量避免此类事件发生，但无论多么完美的系统也不能保证绝对地“万无一失”，例如近期的Google云宕机事件就是由于内部消息队列系统溢出所导致。因而云系统在设计时就需要考虑到熔断保护机制，使得在海量请求和高并发冲击或甚至内部系统不稳定导致某个子服务失效时及时切断前端仍在不断端涌来的海量请求，避免连锁反应确保其它功能正常工作并尽快恢复故障服务，把故障缩小到最小范围。对于高度数据密集和计算型的遥感大数据系统这些显得尤为重要。

现代化服务网关对于云平台至关重要，目前已经可以找到较多成熟解决方案作为借鉴，下一节介绍开发团队对现有技术的调研和分析。

现有技术分析主流API服务网关简介

经过调研目前主流API服务网关技术可以分为如下几类：

基于Nginx的方案：Nginx是被市场充分证明的高性能多功能反向代理软件，具有一定服务网关功能。当今在Nginx基础上衍生出了一些功能更全面的网关软件，如Openresty，Kong，APISIX等。基于Envoy的方案：Envoy适用于大型现代化面向服务架构，对HTTP/2和gRPC支持良好，具备储多先进功能，在云原生系统中性能优异，主要运用在云原生架构系统之中。基于Envoy的API网关有Ambassador，gloo等。基于特定语言实现的一些方案：针对Java平台的有Dubbo，Zuul和Spring Cloud等但使用范围较小。基于Go语言实现的通用API网关有Traefik, Tyk , GoKu等，其中Traefik。基于NodeJS语言实现的API网关有apiaxle等。基于Ruby语言实现的API网关有api-umbrella等。基于Python语言，针对单景卫星地图浏览任务21AT已经在21ATExplorer系统中实现了一个自有API网关。

HAProxy则是比较出名的能够工作在L4和L7上的高性能负载均衡器软件，它也具有一些服务网关需要的能力，但功能比较单一，主要应用于负载均衡和系统连接数控制方面。

常见方案比较

功能和特性方面，主要参考《COMPARISON OF FIVE OPEN SOURCE API Gateways FOR MICROSERVICE IMPLEMENTATION》一文并整理后得到下表。

Table 3-1 五种常见API网关比较

Kong

Traefik

Ambassador

Tyk

Zuul

主要用途

API网关

微服务网关

微服务网关

微服务网关

微服务网关

核心技术

Nginx+Lua

Golang

Envoy

Golang

Java

学习曲线

适中

简单

简单

适中

简单

成本

开源/企业版

开源

开源/pro

开源/企业版

开源

开源协议

Apache 2.0

MIT

Apache 2.0

MPL

Apache 2.0

社区星级

很高

最高

低

中

高

配置方式

REST API / 配置文件

TOML

YAML

REST API

REST API /

YAML

管理模式

可配置

去中心化 / 自服务

去中心化 / 自服务

去中心化 / 自服务

去中心化 / 自服务

K8S

适中

容易

容易

适中

适中

扩展功能

插件

自己实现

插件

插件

自己实现

扩展方法

水平

水平

水平

水平

水平

服务发现

动态

动态

动态

动态

动态

支持协议

HTTP HTTPS Websocket

HTTP HTTPS gRPC Websocket

HTTP

HTTPS

gRPC Websocket

HTTP

HTTPS

gRPC Websocket

HTTP

HTTPS

路由

Host Path Method

Host Path

Host Path Header

Host Path

限流

有

无

有

有

自行开发

熔断

有

有

无

有

需要组件

重试

有

有

无

有

有

健康检查

有

无

无

有

有

仪表盘

有

有

Grafana, Prometheus

有

无

值得注意的是Ambassador立项时间短虽然社区星级最低，但发展速度很。

性能方面，由于各类服务网关在不同场景下各有特色，所以不同的文献中比较结果可能有一定的不同。例如在《Benchmarking 5 Popular Load Balancers: Nginx, HAProxy, Envoy, Traefik, and ALB》一文中总结道，从总体角度Envoy有更好的吞吐量，但实际比较中也有少指标中HAProxy和Nginx表现更好。而在Github的“Proxy-Benchmarks”项目中也列出了一些实测结果和源代码。如Figure 3-1显示吞吐量最高的是HAProxy > Nginx > Envoy > Traefik。

Figure ‑“Proxy-Benchmarks”中吞吐量性能评测结果

而Figure 3-2和Figure3-3则都显示，HAProxy和Nginx显著优于Envoy和Traefik。

Figure ‑“Proxy-Benchmarks”中延迟时间测试结果

Figure ‑“Proxy-Benchmarks”中CPU占用率结果

造成不同结论的原因很多，其实有些测试的方法本身就过于理论话从而导致某种不公平的场景出现。但从另一个侧面恰恰反应出这几类API服务网关在不同应用场景下可能各有特色的。

也必须注意的是，选择解决方案绝不是只基于性能高或功能多某一个方面的，我们需要从可行性、经济成本、时间成本、人力成本、功能、性能、可靠性、可维护性等储多方面综合考虑。

选型及可行性研究

依需求，平台需要一个或多个公共API服务网关，如果有需求还应当对其它服务系统分类分层管理以优化整体结构，由此可能还需要多个内部API或RPC/gRPC服务网关。基于当前最高优先极任务我们首先需要确定公共API服务网关解决方案。

选型

如果只针对单景卫星地图浏览任务的地图服务系统，可以继续使用自主开发的21ATExplorer应用网关系统，它是为21ATExplorer专门订制开发的专有网关，经过实践证明目前它仍然可以胜任现有需求。但是对于整个平台而言，我们需要选择一个具有如下特点的解决方案：

通用且功能较全：可以在较复杂的大型系统中广泛使用，可以直接使用已经经过市场验证的各种已经有功能，避免重复造轮子，大大减少开发成本。性能较强大：作为平台的公共API服务网关必须具有足够高的服务性。成熟可靠：必须具有已验证过的高的软件质量，确保可用性，尽可能少的故障率和维护成本。代码开源：降低开发成本，有较高的可扩展性和灵活性，有开源社区的广泛支持。较高的认知度：相关资料丰富，易于找到开发人员和维护人员，学习成本、开发成本、维护成本低。

按照21AT自身需求进行需求比对，列表如下：

Table 4-1 备选API网关与当前需求匹配度分析结果

Kong

Traefik

Envoy

自主开发

现有功能

全面且可制定开发

较全面且可制定开发

较全面且可制定开发

不全面但可较容易地制定开发

功能扩展

较难

较易

较易

容易

性能

优异

较优

在K8S中优异

取决于语言和框架

成熟度

高

高

较高

中

学习曲线

适中

简单

适中

较高

成本

低

低

中

较高

如果从云原生架构、云原生性能、流行趋势和研究探索的角度上讲，Envoy及其衍生的服务网关应当是不错的选择。但是鉴于平台尚未计划采用云原生架构，且Envoy系列的服务网关系统尚比较年轻还有储多不确定因素难以预料，因此本期开发任务暂不考虑Envoy及其相关解决方案。

选择Kong解决方案。如前文所述Kong系属于Nginx和Openresty系列衍生产品，它扩充和强化了Nginx和Openresty的功能，它既有开源社区产品又有企业化商业产品。可以看出Kong能够满足通用且功能较全、性能较强大、成熟可靠、代码开源和较高的认知度等基本选型需求。

可行性研究

为了验证基于Kong开发平台公共API服务网关的可行性。主要包括：

构建共享数据库搭建了3节点Kong实验集群搭建了基于Konga 的KONG图形化管理系统完成实验将Explorer全部服务，包括map, ums, payment, 等，由Kong无缝对外转发完成实验开放Kong自带file-log插件对指定服务输出访问日志完成实验创建consumer并开放Kong自带Key-Auth插件对指定服务apikey进行校验实现简单权限控制，并在日志中跟踪用户标识。完成实验验证基于Basic-Auth插件的用户认证功能。调研了基于Jwt插件的token认证功能和使用方法。搭建演示用OAuth2认证服务器，实验验证整个OAuth2认证流程，包括获取授权码、获取access token、使用token和日志校验等工作。

下面逐条展开。

环境搭建

团队在1台主机上首先搭建了一个Postgresql数据库系统，照Kong的设计要求初始化数据库内容，以该数据库为中心配置管理数据库搭建了一个由3个Kong实例构成的服务网关实验集群。更进一步，基于一个开源Kong图形管理工具Konga搭建了该集群的图形化管理服务。

s

Figure ‑Kong图形管理工具Konga的DashBaord界面

如图Figure4-2是Kong的节点信息。

Figure ‑Kong图形管理工具Konga的Connections界面

对于熟手而言，整个搭建过程步骤并不多，相对比较容易。

图形化管理工具简介

Konga是目前比较流行的开源的Kong图形化管理工具，如Figure4-3所示用户可以直接管理consumers。

Figure ‑Kong图形管理工具Konga的Consumers界面

如图Figure4-4所示Konga还可在图形界面下直接管理Plugins。

Figure ‑Kong图形管理工具Konga的Plugins界面

因此，Kong具有了比Openresty等更方便操作特性。

服务与路由功能实验

研发团队也对Kong的核心功能，服务与路由，进行了一定实验。实验目标是将21ATExplorer中所有类型的API和服务转接到Kong的对外服务路由上，让Explorer应用看起来象是新主机上的一个子服务。

如截图Figure4-5所示我们建立了mystatic用于映射21ATExplorer的所有静态资源服务，myapi用于映射所有应用服务的API，myexplorer用于映射/下的内容，mypayment用于映射所有payment支付相关的API，mymap用于映射所有map相关的API包括xyz和wms服务，myatp用于映射影像预览图资源服务，myums用于映射所有ums用户管理相关的API。

Figure ‑Kong图形管理工具Konga的Services界面

如截图Figure4-6所示我们为服务mystatic建立了/static路由，为服务myapi建立了/api路由，为服务myexplorer建立了/explorer路由，为服务mymap建立了/map路由，为服务myatp建立了/atp路由，为服务mypayment建立了/payment路由，为服务myums建立了/ums路由。

Figure ‑Kong图形管理工具Konga的Routes界面

此外，如图Figure4-7所示，研发团队还对上述配置好的核心功能做了验证，实验表明一切工作正常。

Figure ‑将21AT Explorer的map API映射到Kong主机下属的路由并浏览地图

整个构建过程可以利用Konga的图形化界面完成，不过研发团队实验时均采用工具curl直接调用Kong的管理API完成，这意味着日后开发团队可以对Kong的管理API进行二次开发实现21AT自定制的对内使用的网关管理与控制接口。

现有插件简介

Kong的一优点在于它本身自带大量插件可以直接提供比Nginx或Openresty更多的功能。

Figure4-8是Kong 可选的Authentication插件，包括Basic Auth、Key Auth、Oauth2、Hmac Auth、Jwt和Ldap Auth共6种插件。相关研究请参见下一小节。

Figure ‑Kong 可选的Authentication插件

Figure4-9是Kong可选的Security插件，这里包含简单的用户分组权限控制，IP限制等插件。

Figure ‑Kong可选的Security插件

Figure4-10是Kong可选的Traffic Control插件，里面包含了请求限速、响应限速、请求尺寸限制和请求阻断共4个关键流程插件。

Figure ‑Kong可选的Traffic Control插件

Figure 4-11 是Kong可选的Serverless插件，包含Aws Lambda等相关无服务器架构插件。

Figure ‑Kong可选的Serverless插件

Figure 4-12 是Kong可选的Analytics & Monitoring插件，包含Datadog、Prometheus以及Zipkin 3个流行的分析监控插件。

Figure ‑Kong可选的Analytics & Monitoring插件

Figure 4-13 是Kong可选的Transformations插件，包含请求变形、响应变形和关联ID插件。

Figure ‑Kong可选的Transformations插件

Figure4-14是Kong可选的Logging插件，包含依靠Tcp、Udp或Http网络传输日志的插件，将日志写入文件的插件，等储多插件。

Figure ‑Kong可选的Logging插件

Figure4-15是Kong其它一些可选的插件，其中包括缓存和会话保持插件等。

Figure ‑Kong可选的Other插件

可见Kong现成的可以直接使用功能比Nginx和Openresty多很多，但是也需要要注意的是有些功能虽然有，但并不一定能完全满足我方系统的设计需求，届时就需要利用Lua语言自行开发插件得以解决。现有的大量成功案例标明自行开发插件是可行的，但是应当注意的是，Lua语言相对较生僻且性能较差（相比原生功能），再则部署自定义插件也会为开发工作带来更多工作量和不确定性，这些是需要事先有一定思想准备的。

用户认证功能实验

在网关上对各种外来请求实现用户认证是确保云管理系统辨识外来请求的身份，从而实现精准监测与控制，确保对外服务内容正确和质量可控，同时也是保障整体系统安全可靠的必要前提。

如上一小节Figure4-8所示，Kong提供了包括Basic Auth、Key Auth、Oauth2、Hmac Auth、Jwt和Ldap Auth在内的共6种认证插件。考虑到认证对整个系统的重要性，研发团队对Basic Auth、Key Auth、Oauth2、Hmac Auth和Jwt插件进行了较深入研究，其中对Key Auth和Oauth2做了日志校验，基本了解了Kong认证方式。一般情况下所有认证都需要对应于Kong系统内确定的Consumer或Consumer下的用户凭证，也就是说在Kong的配置数据库里将会存储那些Consumer及其相关用户凭证用于Kong上的认证，我们必须注意这些用户凭证和整个系统中的用户管理服务的关系。以Bastic Auth为例：

调用Kong管理API为服务myexplorer配置相应认证插件：

curl -X POST \

--data "name=basic-auth" \

--data "config.hide_credentials=true"

调用Kong管理API为服务myexplorer的路由explorer配置相应认证插件：

curl -X POST \

--data "name=basic-auth" \

--data "config.hide_credentials=true"

这时再想使/explorer下的服务就报401错误。

调用Kong管理API建立一个Kong认可的用户凭证：

curl -X POST {consumer}/basic-auth \

--data "username=tester01" \

--data "password=demo123!"

此处{consumer}表示Kong已有的Consumer。

验证认证功能：

curl {path matching a configured Route} \

-H 'Authorization: Basic dGVzdGVyMDE6ZGVtbzEyMyE='

其中dGVzdGVyMDE6ZGVtbzEyMyE=是用户凭证tester01:demo123!的Base64编码。如果一切正确Kong将接受并转发这一请求，而且在日志中可以清楚地分辨出是哪个consumer下的用户发出了该请求。

需要注意的是，用户凭证tester01:demo123!记录在Kong的配置库中，我们需要考虑这些凭证如何与云系统的认证服务数据库同步，或是直接把Kong的认证服务作为整个云系统的唯一认证服务？不同的选择会导致不同的系统组成结构，需要在未来的工作中明确下。

除了Basic Auth外，我们还研究了其它一些认证插件，包括Oauth2的全套认证流程，由于相对比较复杂这里不再罗列，可以参考相应脚本代码，但可以确定的是Kong是，除了不能直接提供密码输入与校验页面服务外，Kong可以直接提供几乎整套Oauth2认证服务流程，并直接在Kong上对用户请求进行认证处理。

初步结论

现有实验表明，Kong除了具有Nginx和Openresty高性能、可开发自有插件灵活扩展等各项优点外，还具有储多优点如：

有多种开源的图形化管理工具可以基于共享数据库实现多个节点完全同步地控制网关，并利用HAProxy、LVS、F5现实高性能、高可用Kong网关集群可以利用REST API或图形界面方便实现网关常用各项功能可以利用REST API或图形界面直接利用现有插件完成大多数高级网关功能可以基于Kong直接实现多种常见的用户认证服务功能可以利用日志插件以多种方式灵活地保存或发送系统日志和请求与响应日志可以利用现有插件完成一定的限流和阻断功能如果需要更多功能可以用Lua脚本开发自有插件

不过需要注意的是Kong社区版现成插件功能相对比较简单，如果某些插件无法满足后期需求则需要使用Lua脚本开发自定制插件，因为Lua脚本语言相对生僻开发成本会略高，另外，更高级的系统优化仍然需要涉及Nginx低层配置优化，并且需要深度订制Kong系统，在某些阶段这些有可能会给开发团队带来较多工作量。但Kong已经有了相当高的成熟度，我们相信开发团队有能力一一克服那些问题。

总结

综前述，经过较深入地调研和实验研究开发团队确认Kong的各项功能和运行指标满足系统设计要求，相关方案切实可行，目前总部开发团队和研发开发团队达成共识，建议选择基于Kong的方案逐步推进开发自有公共API服务网关。

更进一步，正如搭建数据库服务然后在其数据库上开发管理系统那样的模式，届时开发团队将搭建一套产品级Kong网关集群系统，依照系统需求配合全局管理策略，逐步推进，利用Kong的管理接口开发自有网关集群管理系统并对内提供相应API以便配合全局行为管理系统及时、灵活、动态地调整网关控制策略，实现自动化的服务集成、接口映射、动态路由、安全、监控、负载均衡、高可用、热数据缓存、流量控制、熔断保护等功能。最终成果将表现为整套系统安装配置脚本、自有网关管理平台软件以及相关技术文档，经过测试无误后可以整套提交并转交给总部开发团队。

接下来开发团队计划重点研究的方向为：

研究用户组权限控制方法和Kong API用法研究请求变换和响应变换方法和Kong API 用法确定日志采集方案并研究日志采用方法和Kong API用法研究流控方法及相关Kong API用法研究数据缓存方法及相关Kong API用法逐一对关键功能的Kong API进行二次开发，逐步构建自有网关管理平台开发插件，深入订制和优化Kong集群系统