Nginx 是如何进化到 kong 的

在传统的互联网服务中，对网关的主要诉求就是反向代理、负载均衡、路由等基础功能。

一个经典的业务的架构图一般是采用四层 LVS 做 对外 IP 收敛，在七层采用 Nginx 来负责七层 HTTPS 协议接入，反向代理、负载均衡、路由。

Nginx 的每个 Worker 进程在底层都使用一个 epoll 对象，高效管理海量的 socket 连接上的网络事件的处理。

性能上的问题是解决了，但是现在随着微服务的发展，服务被拆的非常零散，降低了耦合度的同时也给服务的统一管理增加了难度。

例如服务发现。在 Nginx 中，所有的后端服务都是以静态配置文件的形式记录的。每当后端服务的 IP 发生变化的时候，需要重新修改配置文件。

但在微服务时代，后端都是用容器部署的，每次版本发布都会导致 IP 的变化。而且微服务时代还需要动态的扩缩容，都会导致后端服务 IP 的变化。传统的修改配置文件才能重新分配流量的方式显然已经无法满足需要。

除了服务发现以外，微服务时代对网关还有其他一些新的需求，例如限流、协议转换、身份验证、安全防护等功能，都需要在网关中能够支持。

我们都知道，Nginx 是用 c 语言写的。如果想在 Nginx 的基础上开发这些功能，成本还是挺高的。首先 c 语言的门槛就会比其它语言要高一些。其次，每次功能的修改都需要重新编译发布 Nginx。

好在