1.2 Kong网关简介
本节将详细介绍Kong网关的发展历程和产品特点，并从不同维度对比Kong网关与其他网关产品的差别，使读者对Kong网关有一个全面的了解。
1.2.1 Kong网关的发展历程
Kong网关起源于2007年，由Augusto、Marco、Michele三人在意大利的一个小车库中开发，当时命名为Mashup平台。在随后7年的时间里，Mashup平台逐渐占据API网关市场的主导地位。2017年10月，Mashup平台正式更名为Kong，并推出了Kong企业版。2018年，Kong公司成立，并发布了Kong 1.0版本。直至今日，Kong版本已经更新到2.1.0。
在1.0版本发布后，Kong网关受到众多用户的喜爱。如今，全球大约有200家企业正在使用Kong网关，其中包括一些超大型企业，例如西门子（Siemens）、通用电器（GE）、三星（SAMSUNG）、嘉吉（Cargill）等。其覆盖的行业也非常广泛，包括互联网/电子商务、电信、软件与技术、金融服务、汽车、食品、饮料和零售等多个领域。大多数公司使用Kong网关来解决自身的痛点问题，以更好地完成微服务架构转型。
2019年，Kong公司对外发布了不少更倾向于云原生服务的产品。例如：Kong网关升级到了2.0版本，并与Kubernetes有机结合，可以作为入口控制器来协调整个Kubernetes集群；Kuma产品基于Envoy的Service Mesh，降低了系统复杂性并提高了服务可靠性。相信Kong公司未来会给我们更多惊喜和更多划时代的新产品。
1.2.2 Kong网关与传统网关对比
在讨论网关服务器之前，我们先来看一下传统服务器的市场份额，如图1-2所示。
图1-2 传统服务器的市场份额
图1-2展示了从1995年至2019年，各大服务器厂商的市场份额。可以发现早些年间，服务器市场完全被Apache服务器和Microsoft的IIS服务器所垄断。这两个服务器代表着两大开发系统的对抗，即选择Linux系统还是Windows系统。在2007到2008年，我们看到了Nginx服务器的身影，随后其突飞猛进，占据服务器市场的“头把交椅”。在大流量、超大流量网站的服务器选型中，Nginx更是作为首选，将竞争对手远远甩在身后。
Kong、OpenResty都是基于Nginx打造的新一代服务器。它们兼具Web服务器的功能，但侧重于网关层特性的延伸。图1-3展示了三者的关系。
图1-3 Kong、OpenResty与Nginx的关系
在功能定位上，Kong和OpenResty有很多相似之处，都是基于Lua脚本做二次开发。但Kong在OpenResty之上又衍生出不少新的概念，对网关内部层级做了更好的抽象，更符合用户使用习惯。如果读者是第一次接触网关层组件，或者希望学习网关层的内部架构设计，Kong网关都是非常好的选择。
1.2.3 其他主流网关
除了Kong网关之外，网关层生态中还有许多其他成熟的网关可供选择，这里我们会给大家做一些简单介绍。
1.Træfik
Træfik是一款云原生的新型HTTP反向代理、负载均衡软件，能轻易部署微服务。它支持多种后端（Docker、Swarm、Mesos/Marathon、Consul、Etcd、Zookeeper、BoltDB、Rest API、File等），也可以对配置进行自动化、动态管理。Træfik整体架构如图1-4所示。
图1-4 Træfik整体架构
Træfik有如下特点。
1）使用Go语言编写、单文件部署、与系统无关，同时提供小尺寸Docker镜像。
2）支持Docker/Etcd后端，天然连接微服务集群。
3）内置Web UI，支持可视化管理。
4）自动配置证书。
5）性能良好，主打易用性。
Træfik凭借其超轻量级、易于配置、简单易上手的特点，满足了中小公司初期对于网关层的需求。相比接下来介绍的几款网关产品中，Træfik与Kong网关在功能上最为接近（虽然底层架构完全不一样）。对Træfik网关感兴趣的读者可以查阅公司官网（https://docs.traefik.io/）学习。
2.Ambassador
Ambassador是一款基于Envoy Proxy构建的、Kubernetes原生的开源微服务网关。Am-bassador在构建之初就致力于支持多个独立团队。传统的网关产品一般是基于Restful API或者yaml文件进行配置，而Ambassador完全基于Kubernetes标准的注解（Annotation）或者CRD进行配置，可以认为是Kubernetes原生的网关产品。
Ambassador依靠Kubernetes实现可扩展、高可用性和持久性，所有配置都直接存储在Kubernetes的Etcd中。Ambassador被打包成一个单独的容器，其中包含控制平面（Control Plane）和Ambassador代理实例。默认情况下，Ambassador会被部署为Kubernetes Deplo-yment，并可以像其他Kubernetes Deployment资源一样进行扩展和管理。
Ambassador作为一款较新推出的开源微服务网关产品，与Kubernetes结合得相当好。它基于注解或CRD的配置方式与Kubernetes浑然一体，就像Kubernetes自身功能的一部分，真正做到了Kubernetes原生。其底层基于Envoy进行流量代理，使得用户无须担心性能问题。
Ambassador和同类的网关产品类似，分为社区版及商业版，其中社区版提供了网关层所必需的基础功能，开发语言为Go。想要深入了解Ambassador网关的读者可以参考https://www.getambassador.io/。
3.Tyk
Tyk是一款采用Go语言实现的API网关产品，拥有API Gateway、Tyk Dashboard、Tyk Pumpd和Tyk Identity Broker等组件。不过，只有API Gateway组件的源代码是开放的。Tyk的插件功能比较强大，一方面提供了IP黑白名单、参数提取和认证等诸多插件，另一方面支持使用JavaScript、Python、Lua语言来自定义插件。
总地来说，Tyk丰富的插件、强大的认证机制给人眼前一亮的感觉。不过，其开源版本的集群管理、日志监控和灰度发布等功能相对较弱，有兴趣的读者可以访问官网（https://tyk.io/）了解相关内容。
4.Zuul
Zuul是Netf lix开源的一个API网关，本质上是一个Web Servlet应用。Zuul可以动态加载过滤器，从而实现网关层的各项功能。Zuul网关从1.0版本升级到2.0版本发生了很大的变化。我们先从图1-5和图1-6看看二者的差别。
图1-5 Zuul 1.0架构
图1-6 Zuul 2.0架构
这里我们对Zuul 1.0和Zuul 2.0做一个简单对比，如表1-1所示。
表1-1 Zuul 1.0和Zuul 2.0的对比
相对而言，Zuul 1.0适用于CPU密集型（CPU-bound）场景，而Zuul 2.0适用于I/O密集型（I/O-bound）场景。由于Zuul网关或者之后推出的Spring Cloud Gateway网关组件都是基于Spring Cloud全家桶提供的配套组件实现的，因此受到了人们的普遍认可。但这两个网关组件也有一些限制，一是它们的底层技术栈要基于Java技术栈，或者基于Spring Cloud框架；二是它们并非云原生服务，相对而言，偏向于企业级内部部署。如果排除这两点，二者在其他各方面的表现都是比较出色的。
注意
I/O密集型任务vs CPU集型任务
·I/O密集型任务指的是磁盘I/O或者网络I/O占主要消耗的任务，计算量很小，比如请求网页、读写文件等。大多数Web应用都是I/O密集型任务。
·CPU密集型任务指的是CPU计算占主要消耗的任务，比如图形渲染中矩阵的运算、神经网络卷积运算等。现在大多数计算任务由GPU完成，更复杂的任务由TPU、NPU完成。
5.各网关横向对比
我们从基本情况、配置、部署、可扩展性和功能等维度对上述各网关进行横向对比，如表1-2至表1-6所示。
表1-2 基本情况
表1-3 配置
表1-4 部署
表1-5 可扩展性
表1-6 功能
可以发现，Kong网关在多项对比中较其他网关均占有一定优势。但我们也不应该忽略Kong网关的薄弱项，即在部署方面相对复杂，这与Kong网关本身偏向提供企业级服务有一定关系。不可否认的是，Kong网关社区版的功能依旧足够强大，并且给开发者留有大量定制化的空间。
注意
我们在做技术选型时，除了需要考虑上述几点之外，还要考虑以下细节。
·开源组件是否易于扩展自己的业务逻辑，是否易于定制化。
·社区是否成熟，文档是否齐全，漏洞修复得是否及时。
·软件是否容易使用，日后升级和维护是否便捷。
·如果对性能指标或者业务场景有特殊要求，需要着重关注该软件是否支持，以免发生本末倒置的现象。