云原生架构下的 API 网关实践： Kong （二）

时间 2019-11-06

标签原生架构 api 网关实践 kong 栏目系统架构繁體版

原文原文链接

Kong 是 Mashape 开源的一款云原生架构下的分布式 API 网关，其性能和可扩展性在同类组件中，表现都很优异。Kong 官方提供了不少直接可用的插件，此外，Kong 还能够经过插件扩展已有功能。nginx

本文的主要内容：git

什么是云原生网关？
Kong 介绍
Kong 的基本架构
使用 Kong 构建服务网关
几种经常使用插件应用
自定义插件的实践

文章篇幅较长，后半部份内容将会在下一篇文章介绍，敬请关注。sql

什么是云原生网关

什么是云原生

本文的标题是：云原生架构下的 API 网关实践。首先谈谈关于云原生的具体定义，仁者见仁智者见智。docker

Pivotal 是云原生应用的提出者，并推出了 Pivotal Cloud Foundry 云原生应用平台和 Spring 开源 Java 开发框架，成为云原生应用架构中先驱者和探路者。Pivotal 公司的 Matt Stine 关于云原生应用架构的定义，提出来几个主要特征：数据库

符合12因素应用
面向微服务架构
自服务敏捷架构
基于API的协做
抗脆弱性

随着技术的发展，云原生的概念也在不断的完善。云原生的定义将来还会变，本文参考 CNCF V1.0 的定义：编程

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的表明技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。json

所以，云原生网关很重要的特性之一，就是可以快速集成到持续发布的云原生环境中。bootstrap

为何须要 API 网关？

当使用单体应用程序架构时，客户端（Web 或移动端）经过向后端应用程序发起一次 REST 调用来获取数据。负载均衡器将请求路由给 N 个相同的应用程序实例中的一个。而后应用程序会查询各类数据库表，并将响应返回给客户端。微服务架构下，单体应用被切割成多个微服务，若是将全部的微服务直接对外暴露，势必会出现安全方面的各类问题。后端

客户端能够直接向每一个微服务发送请求，其问题主要以下：api

客户端需求和每一个微服务暴露的细粒度 API 不匹配。
部分服务使用的协议不是Web友好协议。可能使用 Thrift 二进制 RPC，也可能使用 AMQP 消息传递协议。
微服务难以重构。若是合并两个服务，或者将一个服务拆分红两个或更多服务，这类重构就很是困难了。

服务端的各个服务直接暴露给客户端调用势必会引发各类问题。同时，服务端的各个服务可扩展和伸缩性不好。API 网关是微服务架构中的基础组件，位于接入层之下和业务服务层之上，如前所述的这些功能适合在 API 网关实现。

关于服务网关的开源组件，有 Netflix Zuul、Spring Cloud Gateway、Kong、Traefik、NGINX 和服务网关类型的 Envoy 等。在以前的文章已经介绍过可编程的新型网关：Spring Cloud Gateway，须要了解的读者能够查看 Spring Cloud Gateway。本文主要介绍现代微服务网关 Kong，在 Kong 的官网介绍中，第一条特性即是 Kong 的云原生属性：与平台无关，Kong 能够从裸机运行到 Kubernetes。本文基于 Kong 1.2.1，自定义插件部分会涉及部分 Lua 编码，适合服务端开发和运维人员。

Kong 介绍

Mashape 开源的高性能高可用 API 网关和 API 服务管理层——KONG（基于NGINX）特色尤其突出，它能够经过插件扩展已有功能，这些插件（使用 lua 编写）在 API 请求响应循环的生命周期中被执行。与此同时，KONG 自己提供包括HTTP基本认证、密钥认证、CORS、TCP、UDP、文件日志、API请求限流、请求转发及NGINX监控等基本功能。目前，Kong 在 Mashape 管理了超过 15,000 个 API，为200,000开发者提供了每个月数十亿的请求支持。

什么是 Kong
当咱们决定对应用进行微服务改造时，应用客户端如何与微服务交互的问题也随之而来，毕竟服务数量的增长会直接致使部署受权、负载均衡、通讯管理、分析和改变的难度增长。

面对以上问题，API GATEWAY是一个不错的解决方案，其所提供的访问限制、安全、流量控制、分析监控、日志、请求转发、合成和协议转换功能，能够解放开发者去把精力集中在具体逻辑的代码，而不是把时间花费在考虑如何解决应用和其余微服务连接的问题上。
为何使用Kong
在众多 API GATEWAY 框架中，Mashape 开源的高性能高可用API网关和API服务管理层——KONG（基于 NGINX）特色尤其突出，它能够经过插件扩展已有功能，这些插件（使用 lua 编写）在API请求响应循环的生命周期中被执行。于此同时，KONG自己提供包括 HTTP 基本认证、密钥认证、CORS、TCP、UDP、文件日志、API请求限流、请求转发及 NGINX 监控等基本功能。目前，Kong 在 Mashape 管理了超过 15,000 个 API，为 200,000 开发者提供了每个月数十亿的请求支持。

Kong 的基本架构

Kong 是 Mashape 开源的高性能高可用 API 网关和 API 服务管理层，一款基于 Nginx_Lua 模块写的高可用服务网关，因为 Kong 是基于 Nginx 的，因此能够水平扩展多个 Kong 服务器。经过前置的负载均衡配置把请求均匀地分发到各个 Server，来应对大批量的网络请求。

Kong 主要有三个组件：

Kong Server ：基于nginx的服务器，用来接收 API 请求。
Apache Cassandra/PostgreSQL：用来存储操做数据。
Kong dashboard：官方推荐 UI 管理工具，固然，也可使用 restfull 方式管理 admin api。

Kong 采用插件机制进行功能定制，插件集（能够是 0 或 N 个）在 API 请求响应循环的生命周期中被执行。插件使用 Lua 编写，基础功能包括：HTTP 基本认证、密钥认证、CORS（Cross-Origin Resource Sharing，跨域资源共享）、TCP、UDP、文件日志、API 请求限流、请求转发以及 Nginx 监控等。

Kong 网关具备如下的特性：

可扩展性: 经过简单地添加更多的服务器，能够轻松地进行横向扩展，这意味着您的平台能够在一个较低负载的状况下处理任何请求；
模块化: 能够经过添加新的插件进行扩展，这些插件能够经过RESTful Admin API轻松配置；
在任何基础架构上运行: Kong 网关能够在任何地方都能运行。能够在云或内部网络环境中部署 Kong，包括单个或多个数据中心设置，以及 public，private 或 invite-only APIs。

术语

Kong 中经常使用的术语介绍，这些术语会在下面的实践中常常用到。

Route：请求的转发规则，按照 Hostname 和 PATH，将请求转发给 Service；
Services：多个 Upstream 的集合，是 Route 的转发目标；
Consumer：API 的用户，记录用户信息；
Plugin：插件，能够是全局的，也能够绑定到 Service、Router 或者 Consumer；
Certificate：https 配置的证书；
Sni：域名与 Certificate 的绑定，指定了一个域名对应的 https 证书；
Upstream：上游对象用来表示虚拟主机名，拥有多个服务（目标）时，会对请求进行负载均衡；
Target：最终处理请求的 Backend 服务。

使用 Kong 构建服务网关

客户端的请求将会首先经由微服务网关处理，一些通用的功能切面将会在网关生效，即 Kong 中的插件，以后才会将请求进行转发到对应的 Backend 服务，以下图所示。

图片来源 https://konghq.com/blog/kong-1-0-ga/

在介绍了为何须要微服务网关和 Kong 的相关概念以后，咱们将会进行实战，使用 Kong 构建网关。

安装实践

目前 Kong 的最新版本 1.2，Kong 的安装支持多种方式。官方支持以下列出方式的安装：

除了官方提供的安装方式，还有社区提供的安装方式，详细了解参见：konghq.com/install/。

笔者为了方便，基于 docker 的方式安装。docker-compose.yml 中定义的镜像、依赖和参数以下所示：

version: "3.7"
services:
 kong:
 image: kong:1.1.2
 environment:
 - "KONG_DATABASE=postgres"
 - "KONG_PG_HOST=kong-database"
 - "KONG_CASSANDRA_CONTACT_POINTS=kong-database"
 - "KONG_PROXY_ACCESS_LOG=/dev/stdout"
 - "KONG_ADMIN_ACCESS_LOG=/dev/stdout"
 - "KONG_PROXY_ERROR_LOG=/dev/stderr"
 - "KONG_ADMIN_ERROR_LOG=/dev/stderr"
 - "KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl"
 ports:
 - 8000:8000
 - 8443:8443
 - 8001:8001
 - 8444:8444
 networks:
 - kong-net
 depends_on:
 - kong-database
 konga:
 image: pantsel/konga
 environment:
 - "TOKEN_SECRET=blueskykong.com"
 - "NODE_ENV=production"
 ports:
 - 8080:1337
 networks:
 - kong-net

 depends_on:
 - kong-database
 kong-database:
 image: postgres:9.6
 ports:
 - "5432:5432"
 environment:
 - POSTGRES_USER=kong
 - POSTGRES_DB=kong
 networks:
 - kong-net
 volumes:
 - /etc/localtime:/etc/localtime:ro
 - /data/data/postgresql:/var/lib/postgresql/data

networks:
 kong-net:
 external: true
复制代码

如上的 docker-compose.yml 会启动三个容器服务：Kong、konga 和 kong-database。这三个容器之间的通讯须要增长 network 段，把容器放在同一个网段内，相关连接修改成容器名称来访问：

docker network create kong-net
复制代码

所启动的三个容器服务，除了 Kong 以外的两个服务：konga 是 Kong 的 Dashboard，基于 js 的客户端管理工具，对外暴露的端口为 8080；kong-database 是 Kong 的数据库服务，存储配置信息，这里使用的是 postgres。须要注意的是，在启动 Kong 容器以前，须要保持数据库的 Docker 容器在运行状态，并执行以下初始化数据库的操做：

docker run --rm \
     --network=kong-net \
     -e "KONG_DATABASE=postgres" \
     -e "KONG_PG_HOST=kong-database" \
     kong:latest kong migrations bootstrap
复制代码

数据库初始化成功后，再次启动 docker-compose.yml 服务就能够了。咱们看到 Kong 映射出多个端口，默认状况下，Kong 监听的端口为：

8000：此端口是 Kong 用来监听来自客户端传入的 HTTP 请求，并将此请求转发到上有服务器；（Kong 根据配置的规则转发到真实的后台服务地址）
8443：此端口是 Kong 用来监听来自客户端传入的HTTPS请求的。它跟8000端口的功能相似，转发 HTTPS 请求的。能够经过修改配置文件来禁止它；
8001：Admin API，经过此端口，管理者能够对 Kong 的监听服务进行配置，插件设置、API 的增删改查、以及负载均衡等一系列的配置都是经过 8001 端口进行管理；
8444：经过此端口，管理者能够对 HTTPS 请求进行监控。

容器都启动好以后，咱们来验证一下：

curl -i http://localhost:8001/

HTTP/1.1 200 OK
Date: Sat, 20 Jul 2019 08:39:08 GMT
Content-Type: application/json; charset=utf-8
Connection: keep-alive
Access-Control-Allow-Origin: *
Server: kong/1.1.2
Content-Length: 5785

...
复制代码

如上的结果，表示安装正确，能够正常使用 Kong。访问 http://localhost:8080 访问 Konga 的管理界面，第一次登陆使用须要建立管理员账号和密码。

更多内容参照官网的安装文档。至此，Kong 以及管理工具都已安装完成，下面将进入 API Gateway 的具体实践。

建立服务

如咱们在术语部分的介绍，服务是上游服务的抽象，能够是一个应用，或者具体某个接口。Kong 提供了管理接口，咱们能够经过请求 8001 管理接口直接建立，也能够经过安装的管理界面，实现的效果是同样的。

curl -i -X POST \
--url http://localhost:8001/services/ \
--data 'name=aoho-blog' \
--data 'url=http://blueskykong.com/'
复制代码

咱们建立一个服务名为 aoho-blog，指定转发的地址为 http://blueskykong.com。能够在管理界面中看到以下的记录：

其中的一些参数，如 Retries、Connect timeout、Write/Read timeout 等参数。

建立路由

建立好服务以后，咱们须要建立具体的 API 路由。路由是请求的转发规则，根据 Hostname 和 PATH，将请求转发。

curl -i -X POST \
--url http://localhost:8001/services/aoho-blog/routes \
--data 'hosts[]=blueskykong.com' \
--data 'paths[]=/api/blog'
复制代码

如上在 aoho-blog 中建立了一个访问 /api/blog 的路由，在管理界面能够看到相应的记录：

建立好路由以后，咱们就能够访问 /api/blog。

Kong 默认经过 8000 端口处理代理的请求。成功的响应意味着 Kong 将 http://localhost:8000 的请求转发到配置的 URL，并将响应转发给咱们。须要注意的是，若是 API 暴露的地址与前面 Host 定义的地址（blueskykong.com）不一致，就须要在请求的 Headers 里面加入 Header，Kong 根据上面请求中定义的 Header：Host，执行此操做。

小结

本文主要介绍了云原生和云原生网关的相关概念，随后具体介绍了本文的主角 Kong 的特性和基本架构。重点介绍了如何使用 Kong 构建服务网关。Kong 官方和社区提供了不少插件，关于 Kong 中的经常使用插件使用，以及如何定制本身的 Kong 插件，将会在下文讲解。