API网关Kong

概念

微服务网关 Kong 科普 - 掘金 (juejin.cn)

Kong是由Mashape开发的并于2015年开园的一款API网关，它是基于OpenResy（Nginx+Lua模块）和Apache Cassandra、PostgreSQL构建的，能够提供易于使用的RestfulApi来操作和配置API管理系统。Kong可以水平扩展多个KongServer，通过前置的负载均衡把请求均匀分发到各个Server来对应大批量的网络请求。

Kong的扩展是通过插件机制进行的，并且也提供了插件的定制示例方法。插件定义了一个请求从进入到最后反馈到客户端的整个生命周期，可以满足大部分的定制需求，本身Kong也集成了相当多的插件，包括秘钥认证、CORS、文件日志、API请求限流、请求转发、健康检查、熔断器等。官网地址konghq.com/ ，代码托管地址：github.com/Kong/kong 。

Nginx，Openresty和Kong三者紧密相连：

Nginx=Http Server+Reversed Proxy+Load Balancer

Openresty=Nginx+Lua-nginx-module，Openresty是寄生在Nginx上，暴露Nginx处理的各个阶段的钩子，使用Lua扩展Nginx

Kong=Openresty+Customized Framework，Kong作为OpenResty的一个应用程序。

Kong网关具有以下特性：

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

Kong的整体架构如下所示

• Kong Restful管理API提供了API、API消费者、插件、upstreams、证书等管理。
• Kong插件拦截请求、响应，相当于Servlet中的拦截器，实现请求的AOP处理。
• 数据中心用于存储Kong集群节点信息、API、消费者、插件等信息，目前提供了PostgreSQL和Cassandra支持，如果需要高可用建议使用Cassandra
• Kong集群中的节点通过Gossip协议自动发现其他节点，当通过一个Kong节点的管理API进行一些变更时也会通知其他节点。每个Kong节点配置信息是回缓存的，如插件，那么当在某一个Kong节点修改了插件配置时，需要通知其他节点配置的变更。
• Kong核心基于OpenResty，实现了请求响应的Lua处理化。

Kong网关的API接口典型请求工作流程如下图所示：

当Kong运行时，每个对API的请将先被Kong命中，然后这个请求将会被dialing转发到最终的API接口。在请求（Request）和响应（Responses）之间，Kong将会执行已经实现安装和配置好的任何插件，授权API的访问操作。Kong是每个API请求的入口点（EndPoint）

OpenResty

OpenResty原理剖析及应用 - 知乎 (zhihu.com)

简介

OpenResty是一个基于Nginx与Lua的高性能Web平台，内部集成了大量精良的Lua库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理高并发、扩展性极高的动态Web一样、Web服务和动态网关。

OpenResty通过汇聚各种精良的Nginx模块，从而将Nginx有效地变成一个强大的通用Web应用平台。这样，Web开发人员和系统工程师可以使用Lua脚本语言调Nginx支持的各种C以及Lua模块，快速构造出足以胜任10K乃至10000K以上单机并发连接的高性能Web应用系统。

从官网描述信息中，可以看出OpenResty主要包含俩方面技术

• Nginx：一款轻量级、高性能、高并发的Web服务器。
• Lua：一种轻量、小巧、可移植、快速的脚本语言；LuaJIT即时编译器会将频繁执行的Lua代码编译成本地机器码交给CPU直接执行，执行效率更高，OpenResty会默认启用LuaJIT。

工作原理如下图所示：

Nginx使用了管理进程+工作进程的设计。管理进程为工作进程的父进程，负责外部指令的接收，工作进程状态的监管，负载均衡等。工作进程负责客户端请求的处理和响应，工作进程一般是按照CPU的核数配置的，并且可以和处理器一一绑定，降低进程间切换的开销。OpenResty本质是是将LuaJIT的虚拟机嵌入到Nginx的管理进程和工作进程中，同一个进程内的所有协程都会贡献这个虚拟机，并在虚拟机中执行Lua代码。

再性能上，OpenResty接近或超过Nginx的C模块，而且开发效率更高。下面介绍一下OpenResty的原理

OpenResty原理

OpenResty的原理可以从三方面进行剖析：Lua协程、cosocke、多阶段处理。

Lua脚本语言用标准的C语言编写并以源代码的形式开放，其设计目的是嵌入应用程序中，从而为应用程序提供灵活的扩展和定制服务。目前Lua大量应用于Nginx、嵌入式设备、游戏开发等方面。

协程又称为微线程，是这一种比线程更加轻量级的存在，正如一个进程可以拥有多个线程一样，一个线程也可以拥有多个协程。Lua协程与线程类似，拥有独立的堆栈、独立的局部变量、独立的指令指针，同时又与其他协同程序共享全局变量和其他大部分东西。

线程和协程的主要区别在于，一个具有多个线程的程序可以同时运行几个线程，而协程却需要彼此协作的运行。在任一时刻只有一个协程在运行，并且这个正在运行的协程只有明确的被要求挂起的时候才会被挂起。

从这里我们可以看出，协程是不被操作系统内核所管理的，而完全由程序控制（也就是用户态执行），这样带来的好处就是性能得到了极大地提升。进程和线程切换要经过用户态到内核态再到用户态的过程，而协程的切换可以直接在用户态完成，不需要陷入内核态，切换效率高，降低资源消耗。

cosocketOpenResty中的核心 技术

cosocket将Lua协程和Nginx的事件机制结合在一起，最终实现了非阻塞网络IO。不仅和HTTP客户端之间的网络通信是非阻塞的，与Mysql、Memcached以及Redis等众多后端之间的网络通信也是非阻塞的。

在OpenResty中调用一个cosocket相关的网络函数，

内部关键实现如图所示：

从图中可以看出，用户的Lua脚本每出发一个网络操作，都会有协程的yield和resume。当遇到忘了IO时，Lua协议会交出控制器（yield）把网络时间注册到Nginx的监听列表中，把运行权限交给Nginx。当有Nginx注册网络时间到达出发条件时，便唤醒（resume）对应的协程继续处理。这样就可以实现全异步的Nginx机制，不会影响Nginx的并发处理性能。多借点处理基于Nginx使用的多模块设计思想，Nignx将HTTP请求的处理过程分为多阶段。

这样可以使一个HTTP请求处理过程由很多模块参与处理，每个模块专注一个独立而简单的功能处理，可以使性能更好、更稳定，同时拥有更好的扩展性。OpenResty在HTTP处理阶段基础上分别在Rewrite/Access阶段、Content阶段、Log阶段注册了自己的handler，加上系统初始阶段master的俩个阶段，共11个阶段为Lua脚本提供处理介入的能力。下图描述了OpenResty可以使用的主要阶段。

OpenResty将我们编写的Lua代码挂载到不同阶段进行处理，每个阶段分工明确，代码独立。

• init_by_lua*：Master进程加载Nginx配置文件时运行，一般用来注册全局变量或者预加载Lua模块。
• init_worker_by_lua*：每个worker进程启动时执行，通常用于定时拉取配置/数据或者进行后端服务的健康检查。
• set_by_lua*：变量初始化。
• rewrite_by_lua*:可以实现复杂的转发、重定向逻辑。
• access_by_lua*:IP准入、接口权限等情况集中处理。
• content_by_lua*:内容处理器，接收请求处理并输出响应。
• header_filter_by_lua*:响应头部或者cookie处理
• body_filter_by_lua*:对响应数据进行过滤，如截断或者替换
• log_by_lua*:会话完成后，本地异步完成日志记录

04性能对比OpenResty基于高性能的Nginx，虽然在实现上采用了“小众”的开发语言Lua，但它的开发效率和运行效率都非常高效。下面，以一个简单的测试案例对比目前较为流行的Web开发环境：NodeJs、Java和Python。本次测试各自实现了一个输出“Hello World”的简单HTTP服务，测试工具使用ApacheBench，测试机为1核2G。压测命令：ab –c 100 –n 10000 http://127.0.0.1:8000/hello压测结果：

从压测结果中可以看出，OpenResty在各项指标上都更胜一筹。

实战

Jshop活动平台Jshop活动平台是京东内部一个能够快速搭建店铺和专题活动的平台，帮助商家和运营对活动页面进行可视化装修，通过添加布局、模块来搭建页面。Jshop活动平台核心流程如下图所示：

图中涉及到5个应用，分别是：

• Jshop-cms：商家或运营使用cms系统完成活动页面的装修，除此之外，cms还提供了权限管理和数据魔方。
• Jshop-engine：Jshop-engine是一个页面渲染引擎，将页面装修所使用的布局、模块和模板渲染成一个完整的静态页面，并将渲染后的页面推送到Redis进行存储。为了防止Redis不可用的情况，也向sale的服务集群推送一份。
• Jshop-worker：主要是一些定时任务，如活动下线，页面定时渲染等。
• sale：sale是基于OpenResty构建的Jshop的活动浏览系统，根据客户端请求URL中活动ID，返回对应的页面静态数据。
• Jshop-act：客户端拿到页面静态数据后，会请求Jshop-act完成页面的动态呈现，例如页面的个性化数据模块、优惠券盖戳、定向投放等。

鉴于本文主要涉及活动浏览相关的内容，sale系统会是接下来我们讨论的重点，首先让我们看一下sale系统为什么采用OpenResty。02sale系统技术选型sale系统主要面向的是C端用户，承载618和双11的大促活动流量，因此高并发、高性能和高可用是我们重点关注的内容。另外，sale系统实现的功能比较简单，核心逻辑就是根据用户请求的活动ID，返回对应的页面数据。我们最终选择基于OpenResty构建sale系统，主要是考虑到以下优势：

• 基于成熟的技术Nginx和Lua来搭建，降低入门门槛和学习成本。
• 依托于LuaJIT，执行效率更高。
• 非阻塞的访问网络IO。
• OpenResty在内存使用率，CPU占用率等方面性能要更好。
• 有完备的缓存机制，不仅支持Redis、Memcached等外部缓存，也在自己的进程内有缓存系统。
• 同步的写代码逻辑，更加符合开发者的思维习惯，无需显式的处理异步回调，调试方便。
• OpenResty工作在七层网络之上，依托于强大灵活的正则规则，可以针对HTTP应用的域名做一些分流和转发策略，既能做负载又能做反向代理。

从图中可以看出，我们的请求来源于多个渠道，需要对多端进行适配。为了应对大促期间的流量，在请求到达sale之前还开启了CDN和Nginx缓存。sale系统默认采用的是本地磁盘文件和Redis的模式，Jshop-engine在执行完渲染页面任务后，会同时更新页面内容到Redis和本地磁盘上。这样就能保证极端情况下，Redis不可用时，sale系统依然可以通过本地文件的方式对外提供服务。04多级缓存sale系统基于OpenResty实现了多级缓存，一般缓存的设计遵循以下两个原则：

• 缓存越靠近用户的请求越好。比如，能用本地缓存就不用发送HTTP请求，能用CDN缓存的就不要打到源站。所以在sale的部署架构中，我们启用了CDN缓存。
• 尽量使用本进程和本机的缓存。跨进程和机器甚至机房，缓存的网络开销就会非常大，这在高并发的时候会非常明显。

根据这两个原则，设计如下：

首先利用了lua-resty-lrucache实现了worker进程内的L1缓存，Nginx启用了多少个worker，就会有多少份缓存数据。由于worker独占的特性，不会触发锁，所以非常高效，缺点就是多份缓存占用了较多的内存。

lua_shared_dict实现了L2缓存，缓存的数据有且只有一份，所有的worker都共用这一份缓存数据。L1缓存没有命中的情况下，就会来查询L2缓存。它的内部使用了自旋锁来保证操作的原子性，因此在并发量非常高的时候，可能会存在一些性能问题。L3缓存使用了Redis，在L2没有命中的情况下，通过回调函数去Redis查询后再缓存到L2中。为了避免缓存风暴，会使用lua-resty-lock来保证只有一个worker去数据源获取数据。如果L3缓存也没有命中，则意味着页面已经过期下线。从整个过程可以看出，缓存的更新是由客户端的请求来被动触发的。

总结

OpenResty是一个兼具开发效率和性能的服务端开发平台，虽然它基于Nginx去实现，但其适用范围早已远远超出了反向代理和负载均衡。目前，国内的很多公司都在特定的场景下使用OpenResty，大多用来处理入口流量，比如负载均衡、安全校验、降级、限流、缓存等。虽然OpenResty是一个广泛应用的技术，但不是一个热门的技术。

OpenResty理论上可以实现各种复杂的web应用，但Lua语言是一门小众的语言，不适合业务逻辑比较重的场景，适合一些轻量级的性能高的WEB服务。
服务推荐。