背景

Ingress 是 Kubernetes 中一个值得关注的模块，作为外部访问 Kubernetes 集群服务的入口，市面上已经有了多种 Ingress controller 的实现。国产实时、高性能的 API 网关 Apache APISIX 推出的 Apache/apisix-ingress-controller 就是其中一员，作为功能更加强大的 ingress 对外提供服务。笔者准备在阿里云 ACK 集群上部署测试。

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

为什么需要 API 网关

在微服务架构之下，服务被拆的非常零散，降低了耦合度的同时也给服务的统一管理增加了难度。如上图左所示，在旧的服务治理体系之下，鉴权，限流，日志，监控等通用功能需要在每个服务中单独实现，这使得系统维护者没有一个全局的视图来统一管理这些功能。API 网关致力于解决的问题便是为微服务纳管这些通用的功能，在此基础上提高系统的可扩展性。如右图所示，微服务搭配上 API 网关，可以使得服务本身更专注于自己的领域，很好地对服务调用者和服务提供者做了隔离。

上一篇文章使用 Kong 完成了负载均衡的配置，本文介绍下在此基础上如何集成 jwt 插件来保护内部服务的安全。前置知识点：Jwt 基础概念。推荐阅读：

通俗易懂地介绍 Jwt https://blog.leapoahead.com/2015/09/06/understanding-jwt/

Jwt 的官网 https://jwt.io/

使用 Kong Community Edition（社区版 v1.3.0）来搭建一个负载均衡器，由于 Kong 是基于 Openresty 的，而 Openresty 又是 Nginx 的二次封装，所有很多配置项和 Nginx 类似。

来看一个较为典型的 Nginx 负载均衡配置

环境准备

采用三台阿里云服务器作为测试
10.19.52.8 部署网关应用 -gateway
10.19.52.9, 10.19.52.10 部署用于测试的业务系统

压测工具准备

选用 ab 作为压力测试的工具，为了方便起见，直接将 ab 工具安装在 10.19.52.8 这台机
测试命令如下：

1

ab -n 10000 -c 100 http://10.19.52.8:8080/hello/testOK?access_token=e0345712-c30d-4bf8-ae61-8cae1ec38c52

其中－n 表示请求数，－c 表示并发数, 上面一条命令也就意味着，100 个用户并发对 http://10.19.52.8/hello/testOK 累计发送了 10000 次请求。

服务器, 网关配置

由于我们使用的 tomcat 容器，关于 tomcat 的一点知识总结如下：

前言

Zuul 是 Netflix 提供的一个开源组件, 致力于在云平台上提供动态路由，监控，弹性，安全等边缘服务的框架。也有很多公司使用它来作为网关的重要组成部分，碰巧今年公司的架构组决定自研一个网关产品，集动态路由，动态权限，限流配额等功能为一体，为其他部门的项目提供统一的外网调用管理，最终形成产品 (这方面阿里其实已经有成熟的网关产品了，但是不太适用于个性化的配置，也没有集成权限和限流降级)。

不过这里并不想介绍整个网关的架构，而是想着重于讨论其中的一个关键点，并且也是经常在交流群中听人说起的：动态路由怎么做？

再阐释什么是动态路由之前，需要介绍一下架构的设计。

传统互联网架构图

上图是没有网关参与的一个最典型的互联网架构 (本文中统一使用 book 代表应用实例，即真正提供服务的一个业务系统)

加入 eureka 的架构图

book 注册到 eureka 注册中心中，zuul 本身也连接着同一个 eureka，可以拉取 book 众多实例的列表。服务中心的注册发现一直是值得推崇的一种方式，但是不适用与网关产品。因为我们的网关是面向众多的 ** 其他部门 ** 的 ** 已有 ** 或是 ** 异构架构 ** 的系统，不应该强求其他系统都使用 eureka，这样是有侵入性的设计。

最终架构图

要强调的一点是，gateway 最终也会部署多个实例，达到分布式的效果，在架构图中没有画出，请大家自行脑补。

本博客的示例使用最后一章架构图为例，带来动态路由的实现方式，会有具体的代码。