使用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
我们可以通过 HTTPAPI 来动态管理 Kong 的配置,8001是默认的管理端口,8000/8443则分别是 Http 和 Https 的转发端口,我们可以通过 HTTP来动态管理Kong配置 。
# 配置一个上游服务curl -X POST http://localhost:8001/upstreams --data "name=helloUpstream"
Kong插件机制
Kong具有极高的可扩展性,而它的高扩展性便来源于他的插件机制 。
首先,先介绍如何在Kong中添加插件 。
插件的作用范围非常灵活 , 可作用于一个服务或者路由之上,也可作用于整个Kong服务 。我们可以为一个服务添加50次/秒的官方限流插件,通过如下所示的 API方式:
【使用Kong作为微服务网关】