使用Kong作为微服务网关

在团队规模尚小，业务尚较为简单的前提条件下，我们常常将多个功能集中在一个应用中，进行统一化的部署和测试。随着业务的发展，功能模块日益增多。如需更新单一模块，都会需要对整个程序进行更新，如此下来，长期以往系统维护将会变得愈发费时费力。

针对以上问题，我们将单体应用进行拆分，变成多个自成一体的模块，每个模块有各自自成体系的发布和运维等功能，由此解决了单体应用的弊端，将应用微服务化。当我们拆分出多个模块之后，各个模块需要统一的出入口，这里我们需要使用网关解决统一调用和接入问题。

在这样的背景之下，我们通过利用Kong这一开源API网关，将请求转发到上游服务之前，进行一系列的管理。

本文针对其核心应用，首先简要阐明Nginx、与Kong三者只间的关系，然后实际介绍如何使用Kong的插件机制来添加一个自定义插件。

1. 基本概念

Kong是一个开源的API网关，它是一个针对API的一个管理工具。你可以在那些上游服务之前，额外地实现一些功能。

Kong本身是一款基于（Nginx + Lua模块）编写的高可用、易扩展的，由公司开源的API 项目。Kong是基于NGINX和 或构建的，能提供易于使用的 API来操作和配置API管理系统，所以它可以水平扩展多个Kong服务器，通过前置的负载均衡配置把请求均匀地分发到各个，来应对大批量的网络请求。

1.1 Nginx

Nginx是模块化设计的反向代理软件，由C语言开发，是多进程（单线程） & 多路IO复用模型（高并发）。

多进程

Nginx 在启动后，会有一个 进程和多个相互独立的 进程。接收来自外界的信号，向各进程发送信号，每个进程都有可能来处理这个连接。

进程能监控 进程的运行状态，当 进程退出后(异常情况下)，会自动启动新的 进程。一个请求，完全由 进程来处理，而且只能在一个 进程中处理请求。

多路复用模型

epoll通过在Linux内核中申请一个简易的文件系统，只要有 fd 上事件发生，() 就能检测到并返回给用户，用户就能”非阻塞“地进行 I/O 了。

在内核，中采用轮训的方法来查看是由有fd文件描述符准备好。在内核，epoll根据每个上面与设备趋同程序建立站起来的回调函数，当某个上的时间发生，与之对应的回调函数就会被调用。

1.2

是一个基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。中的 使得开发人员能够使用 Lua 脚本调动 Nginx 支持的各种模块，让 web 服务直接跑在 Nginx 内部。

把 Lua5.1 的解释器 或 2.0/2.1 的解释器嵌入到 nginx 中，将强大的 Lua 线程（Lua ）与 nginx 事务模型（Nginx event model）相结合，就可以更改变子请求（）的处理过程。

在 nginx 的一个 里，所有请求共享一个Lua 解释器或 实例，即一个 nginx ，一个 Lua 解释器或 实例。每个请求的上下文（）是通过轻量级的 Lua 协程（）相互隔离的。

1.3 Kong

Kong 可以认为是一个 应用程序，而 运行在 Nginx 之上，使用 Lua 扩展了 Nginx。Kong = + Nginx + Lua

我们可以通过 HTTP API 来动态管理 Kong 的配置，8001是默认的管理端口，8000/8443则分别是 Http 和 Https 的转发端口，我们可以通过 HTTP 来动态管理Kong配置。

# 配置一个上游服务
curl -X POST http://localhost:8001/upstreams --data "name=helloUpstream"

Kong插件机制

Kong具有极高的可扩展性，而它的高扩展性便来源于他的插件机制。

首先，先介绍如何在Kong中添加插件。

插件的作用范围非常灵活，可作用于一个服务或者路由之上，也可作用于整个Kong服务。我们可以为一个服务添加50次/秒的官方限流插件，通过如下所示的 API方式: