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

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

本文的主要内容：

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

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

什么是云原生网关

什么是云原生

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

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

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

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

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

因此，云原生网关很重要的特性之一，就是能够快速集成到持续发布的云原生环境中。

为什么需要 API 网关？

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

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

• 客户端需求和每个微服务暴露的细粒度 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开发者提供了每月数十亿的请求支持。

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

   面对以上问题，API GATEWAY是一个不错的解决方案，其所提供的访问限制、安全、流量控制、分析监控、日志、请求转发、合成和协议转换功能，可以解放开发者去把精力集中在具体逻辑的代码，而不是把时间花费在考虑如何解决应用和其他微服务链接的问题上。

2. 为什么使用Kong
   在众多 API GATEWAY 框架中，Mashape 开源的高性能高可用API网关和AP