API网关介绍及选型(kong)

柔光的暖阳◎ 2021-12-10 13:17 710阅读 0赞

API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。  
API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。

## 为什么需要 API 网关 ##

在微服务架构之下，服务被拆的非常零散，降低了耦合度的同时也给服务的统一管理增加了难度。在旧的服务治理体系之下，鉴权，限流，日志，监控等通用功能需要在每个服务中单独实现，这使得系统维护者没有一个全局的视图来统一管理这些功能。

不需要网关的情况，是由客户端直接访问服务提供方，由注册中心向客户端返回服务方的地址

![xdtsdgj][]

### API网关的功能 ###

*  路由：根据上下文或消息内容将请求发送到不同的目标。
 *  转换：负责转换或屏蔽数据的组件。
 *  入站和出站流量监控。
 *  为API添加身份验证，授权和加密的安全策略。
 *  使用策略：它们可以创建消耗，性能和失败策略以保护SLA。

![在这里插入图片描述][aHR0cHM6Ly91c2VyLWltYWdlcy5naXRodWJ1c2VyY29udGVudC5jb20vMTMwNTg5NzcvNjA2MzQ3MTEtODNlZWI0ODAtOWU0Mi0xMWU5LTllMDktZjkzOTQ0N2I0MmI4LnBuZw]

单节点网关  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3B1c2hpcWlhbmc_size_16_color_FFFFFF_t_70]  
针对不同的客户端的多节点网关  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3B1c2hpcWlhbmc_size_16_color_FFFFFF_t_70 1]

### API网关选型 ###

*  私有云开源解决方案：  
    Netflix Zuul，zuul是spring cloud的一个推荐组件，[https://github.com/Netflix/zuul][https_github.com_Netflix_zuul]  
    Kong kong是基于Nginx+Lua进行二次开发的方案， [https://konghq.com/][https_konghq.com]  
    Tyk是2014年创建的开源API网关，甚至比AWS的API网关即服务功能还要早。Tyk用Golang编写并使用Golang自己的HTTP服务器。
 *  公有云解决方案：  
    Amazon API Gateway，[https://aws.amazon.com/cn/api-gateway/][https_aws.amazon.com_cn_api-gateway]  
    阿里云API网关，[https://www.aliyun.com/product/apigateway/][https_www.aliyun.com_product_apigateway]  
    腾讯云API网关， [https://cloud.tencent.com/product/apigateway][https_cloud.tencent.com_product_apigateway]
 *  自开发解决方案  
    基于Nginx+Lua+ OpenResty的方案，可以看到Kong,orange都是基于这个方案  
    基于Netty、非阻塞IO模型。 通过网上搜索可以看到国内的宜人贷等一些公司是基于这种方案，是一种成熟的方案。  
    基于Node.js的方案。 这种方案是应用了Node.js天生的非阻塞的特性。  
    基于java Servlet的方案。 zuul基于的就是这种方案，这种方案的效率不高，这也是zuul总是被诟病的原因。

如果没有开源项目的支撑前提下，自己来做这样一套东西，是非常大的一个工作量，而且还要做 API 网关本身的高可用等，如果一旦做不好，有可能最先挂掉的不是你的其他服务，而就是这个API网关。

国外目前比较成型的是kong和tyk

kong是基于ngnix+lua的，它借助于Nginx的事件驱动模型和非阻塞IO，性能方面是非常棒的，但是从公司的角度比较难于找到能去维护这种架构产品的人。 需求评估当前公司是否有这个能力去维护这个产品。

SpringCloud-Zuul 社区活跃,基于 SrpingCloud 完整生态，但因为架构的原因（zull基于 Servlet 框架构建，采用的是阻塞和多线程方式，即一个线程处理一次连接请求，当出现问题时，如后端延迟或设备错误重试，活跃的连接和线程数量会增加，这会加大服务器负载并可能使集群无法承受）在高并发的情况下性能不高，同时需要去基于研究整合开源的适配zuul的监控和管理系统。较新的Spring cloud Gateway和zuul2倒是不错

Tyk用Golang编写，并发性能较好，但一切均导向收费版本,免费版本第一次申请有一年的使用授权.没找到明确表示是否可以免费继续使用的说明.

扩展Tyk需要会Go语言，扩展Kong需要会写lua脚本，使用 zuul 还得会Java

#### API 网关实现对比 ####

![20190709140836][]

### kong vs tyk ###

![test1][]  
禁用基本身份验证的结果。纵轴表示每秒请求数（Req / Sec），水平轴表示运行的微服务实例数。

![test2][]  
启用基本身份验证的结果。纵轴表示每秒请求数（Req / Sec），水平轴表示运行的微服务实例数。

## kong ##

ref：[https://www.pocketdigi.com/book/kong/][https_www.pocketdigi.com_book_kong]

Kong（[https://github.com/Kong/kong）][https_github.com_Kong_kong] 是一个云原生，高效，可扩展的分布式 API 网关。 自 2015 年在 github 开源后，广泛受到关注，最新版本1.2.1，目前已收获 2.23w+ 的 star，其核心价值在于高性能和可扩展性。

准确地说，Kong是一个使用了lua-nginx-module运行在Nginx之上的Lua应用。Kong没有作为一个module和Nginx一起编译，而是与OpenResty（一个已经包含lua-nginx-module的应用)一起分发。OpenResty不是Nginx的分支，而是一些继承它能力的module的合集。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3B1c2hpcWlhbmc_size_16_color_FFFFFF_t_70 2]

## Kong 支持功能 ##

*  云原生: 与平台无关，Kong可以从裸机运行到Kubernetes
 *  动态路由：Kong 的背后是 OpenResty+Lua，所以从 OpenResty 继承了动态路由的特性
 *  熔断: 追踪不健康的upstream services，当某服务出现不可用或响应超时的情况时熔断
 *  健康检查: 对upstream services进行主动或者被动地监控
 *  日志: 可以记录通过 Kong 的 HTTP，TCP，UDP 请求和响应。
 *  鉴权: 权限控制，IP 黑白名单
 *  SSL: Setup a Specific SSL Certificate for an underlying service or API.
 *  监控: Kong 提供了实时监控插件
 *  认证: 如数支持 HMAC, JWT, Basic, OAuth2.0 等常用协议
 *  限流: 基于多变量对请求进行阻塞或者限制
 *  REST API: 通过 Rest API 进行配置管理，从繁琐的配置文件中解放
 *  可用性: 天然支持分布式
 *  高性能: 背靠非阻塞通信的 nginx，性能自不用说
 *  插件机制: 提供众多开箱即用的插件，且有易于扩展的自定义插件接口，用户可以使用 Lua 自行开发插件

使用 Kong 之后，Nginx 可以完全摒弃，Kong 的功能是 Nginx 的父集

## Kong 的管理方式 ##

所有的管理操作都是基于 HTTP Restful API 来进行的，使用Postgres 或者 Cassandra 来存储路由配置，服务配置，upstream 配置等信息。

### kong端点 ###

其中 8000/8443 分别是 Http 和 Https 的转发端口，等价于 Nginx 默认的 80 端口，而 8001 端口便是默认的管理端口，我们可以通过 HTTP Restful API 来动态管理 Kong 的配置。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3B1c2hpcWlhbmc_size_16_color_FFFFFF_t_70 3]

### kong策略模式 ###

为了便于理解，将Kong目前能实现模式简单分为两种，以便于理解：Request host 和 Request path。

**Request host**

- www.domain1.com/api1  → s1.domain1.com/api1
    - www.domain1.com/api2  → s1.domain1.com/api2
    - ...
    - www.domain1.com/*     → s1.domain1.com/*
    - www.domain2.com/api1  → s2.domain1.com/api1
    - www.domain2.com/api2  → s2.domain1.com/api2
    - ...
    - www.domain2.com/*     → s2.domain1.com/*

要在Kong服务器上绑定多个域名。（提供api服务的服务器可以没有域名绑定，只要有IP即可）

**Request path**

- www.domain1.com/s1/api1   → s1.domain1.com/s1/api1
    - www.domain1.com/s1/api2   → s1.domain1.com/s1/api2
    - ...
    - www.domain1.com/s1/*      → s1.domain1.com/s1/*
     
    - www.domain1.com/s2/api1   → s2.domain1.com/s2/api1
    - www.domain1.com/s2/api2   → s2.domain1.com/s2/api2
    - ...
    - www.domain1.com/s2/* → s2.domain1.com/s2/*

Kong服务器上只需要绑定一个域名，不同的API集合依靠不同的请求路径实现。（同上，提供api服务的服务器可以没有域名绑定，只要有IP即可）

Request host 和 Request path 可组合使用，但比较复杂，不建议使用。

## docker启动kong ##

# 启动kong使用的数据库postgres/cassandra
    docker run -d --name kong-database \
            -p 5432:5432 \
            -e "POSTGRES_USER=kong" \
            -e "POSTGRES_DB=kong" \
            postgres:9.6
    
    # kong配置数据初始化
    docker run --rm \
      --link kong-database:kong-database \
      -e "KONG_DATABASE=postgres" \
      -e "KONG_PG_HOST=kong-database" \
      kong:0.14.0 kong migrations up
    
    # 启动kong容器
    docker run -d --name kong \
      --link kong-database:kong-database \
      -e "KONG_DATABASE=postgres" \
      -e "KONG_PG_HOST=kong-database" \
      -e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \
      -e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \
      -e "KONG_PROXY_ERROR_LOG=/dev/stderr" \
      -e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \
      -e "KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl" \
      -p 8000:8000 \
      -p 8443:8443 \
      -p 8001:8001 \
      -p 8444:8444 \
      kong:0.14.0

## 基于kong + oauth2 + acl的用户接入权限管理 ##

ref：[https://docs.konghq.com/hub/kong-inc/oauth2/][https_docs.konghq.com_hub_kong-inc_oauth2]

ref：[https://docs.konghq.com/hub/kong-inc/acl/][https_docs.konghq.com_hub_kong-inc_acl]

OAuth2密码模式： 用户认证  
![z3dfq4736j][]

acl白名单： 用户分组权限

在网关层做接入权限管控，而非后端应用的业务权限

### 整体流程 ###

![z3dfq4736j][z3dfq4736j 1]

用户认证服务器在Kong的内侧，我们需要通过Kong进行访问

*  用户发送账号密码到 Kong服务器的用户验证API；
 *  Kong服务器将请求1转发给用户验证服务器；
 *  用户认证服务器验证用户账号密码是否正确，如果不正确直接返回错误结果并完成用户认证；如果正确则将：用户账号密码、client\_id和client\_secret、scope、provision\_key、用户ID 发送给 Kong 的OAuth2 接口
 *  Kong生成access\_token并返回给用户认证服务器，并缓存与过期时间相同的 scope，用户ID
 *  认证服务器将4中收到的access\_token返回请求2给Kong，Kong再返回请求1给用户。
 *  用户得到access\_token之后，就可以访问有OAuth2验证的接口了。access\_token中已隐含了用户ID和scope。

#### 需求 ####

对用户进行分组管理，不同的用户有访问不同api（服务）的权限，类似django admin的用户组功能

由于认证系统是完全可信的内部系统，简单起见使用密码授权方式

#### 实现 ####

服务和权限一对一关系，每一个服务（或者api）拥有唯一的权限名，不同的服务不同的权限， 通过对用户赋予不同的权限，从而限制用户访问指定的api或服务

具体参见： [基于kong + oauth2 + acl的用户接入权限管理][kong _ oauth2 _ acl]

[xdtsdgj]: /images/20211210/303e790ba3d34f18bc46cd03b798987a.png
[aHR0cHM6Ly91c2VyLWltYWdlcy5naXRodWJ1c2VyY29udGVudC5jb20vMTMwNTg5NzcvNjA2MzQ3MTEtODNlZWI0ODAtOWU0Mi0xMWU5LTllMDktZjkzOTQ0N2I0MmI4LnBuZw]: /images/20211210/3f3615de7458487c9377aae73707d3e7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3B1c2hpcWlhbmc_size_16_color_FFFFFF_t_70]: /images/20211210/74986502157e43d09d2a1ebd43af6bf8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3B1c2hpcWlhbmc_size_16_color_FFFFFF_t_70 1]: /images/20211210/77620cd8eba8469db1b15549da64fcb3.png
[https_github.com_Netflix_zuul]: https://github.com/Netflix/zuul
[https_konghq.com]: https://konghq.com/
[https_aws.amazon.com_cn_api-gateway]: https://aws.amazon.com/cn/api-gateway/
[https_www.aliyun.com_product_apigateway]: https://www.aliyun.com/product/apigateway/
[https_cloud.tencent.com_product_apigateway]: https://cloud.tencent.com/product/apigateway
[20190709140836]: /images/20211210/50f1d159812f4dabb423ef7676e65726.png
[test1]: /images/20211210/07433428ef4f4efe823ce9fac816abac.png
[test2]: /images/20211210/c385cc361713438e855b193d2cabd2c5.png
[https_www.pocketdigi.com_book_kong]: https://www.pocketdigi.com/book/kong/
[https_github.com_Kong_kong]: https://github.com/Kong/kong%EF%BC%89
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3B1c2hpcWlhbmc_size_16_color_FFFFFF_t_70 2]: /images/20211210/f43484dae63647e4a2fb8e19d381788f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3B1c2hpcWlhbmc_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20190713113952253.jpeg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3B1c2hpcWlhbmc=,size_16,color_FFFFFF,t_70
[https_docs.konghq.com_hub_kong-inc_oauth2]: https://docs.konghq.com/hub/kong-inc/oauth2/
[https_docs.konghq.com_hub_kong-inc_acl]: https://docs.konghq.com/hub/kong-inc/acl/
[z3dfq4736j]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9kb2NzLmtvbmdocS5jb20vYXNzZXRzL2ltYWdlcy9kb2NzL29hdXRoMi9vYXV0aDItZmxvdzIucG5n
[z3dfq4736j 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly96ZW5waG90bzEuY2F0c2NhcmxldC5jb20vYWxidW1zL3dvcmRwcmVzcy8yMDE2MTIyMDI2NzFfa29uZ19hbmRfb2F1dGgyL0E1U2xmLmpwZw
[kong _ oauth2 _ acl]: https://blog.csdn.net/pushiqiang/article/details/95726741