系列文章：
微服务架构：网关概念与 zuul
微服务网关：Spring Cloud Gateway —— Zuul
微服务网关：Spring Cloud Config- 配置中心
一 摘要
前面我们介绍了 Spring Cloud 体系下的网关 Gateway（Zuul）。事实上，还有很多开源且广泛应用的网关方案，例如 Kong 和 Nacos。本篇将先介绍这两种网关，包括架构和主要原理，并给出集中网关方案的对比。
二 Kong
2.1 介绍
Kong（官网：https://konghq.com/, git:地址 https://github.com/Kong/kong），根据官方介绍，是一个 clould-native、快速的、可扩展的、分布式的微服务抽象层（也称为 API 网关、API 中间件或在某些情况下称为服务网格）框架。
更确切地说，Kong 是一个在 Nginx 中运行的 Lua 应用程序，并且可以通过 lua-nginx 模块实现。Kong 不是用这个模块编译 Nginx，而是与 OpenResty 一起发布，OpenResty 已经包含了 lua-nginx-module。OpenResty 不是 Nginx 的分支，而是一组扩展其功能的模块。
2.2 版本信息
从 git 最近发布信息来看，最新的 Release 版本为 2.3.3，发布于 3 月 6 日。截至当前已经有了 129 个 Release 版本，Star：28.6k，可见社区还是非常活跃的。2.3.x 的官方文档地址：https://docs.konghq.com/gateway-oss/。
2.3 为什么选择 Kong？
Kong 通过插件形式，提供了微服务网关的各项功能，包括负载均衡、日志、授权、限流、转发等等。传统 Client/Services 方式与 Kong（网关）方式的对比如下图所示：
高性能、可扩展、易用性是 Kong 的三大原则。
2.4 Kong 架构
从架构图可见，Kong 由 Kong Server、数据库（Cassandra/PostgreSQL）、Kong Dashboard 三大核心组件构成：
- Kong Server：基于 Nginx 的服务器，用来接收 API 请求。
- Apache Cassandra/PostgreSQL：用来存储操作数据。
- Kong Dashboard：官方推荐 UI 管理工具，也可以使用开源的 Konga 平台。
Kong 采用插件机制进行功能定制，当前本身已经具备了类似安全，限流，日志，认证，数据映射等基础插件能力，同时也可以很方便的通过 Lua 定制自己的插件。插件完全是一种可以动态插拔的模式，通过插件可以方便的实现 Kong 网关能力的扩展。
三 Nacos
3.1 简介
Nacos 是一个动态服务发现、配置和服务管理平台，从官方介绍来看，Nacos 的定位和特性如下：
Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。
Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。
也就是说，Nacos 其实本身包含了服务注册中心、配置中心、网关等一系列功能，这几个部分分别可以对应 Spring Cloud 体系内的 Eureka、Spring Cloud Config、Spring Cloud Gateway。
3.2 Nacos 架构
3.2.1 nacos 地图
官方文档的 nacos 地图，从战略、特性、优势、架构、生态、业务六大角度详细阐述了 nacos 的核心内容。
3.2.2 Nacos 生态
在项目早期，我们通常把 Nacos 用作 dubbo 的注册中心，后续逐渐扩展到了配置中心、网关功能。随着 Nacos 的不断完善，目前已经无缝支持一些主流的开源生态，例如
- Spring Cloud
- Apache Dubbo and Dubbo Mesh
- Kubernetes and CNCF
3.3 Nacos 架构
“服务”是 Nacos 的核心概念，指一个或一组软件功能（例如特定信息的检索或一组操作的执行），其目的是不同的客户端可以为不同的目的重用（例如通过跨进程的网络调用）。
Nacos 由 Server 和 Console 两大部分组成，而 Nacos Server 提供了服务注册：Naming Service（官网叫名字空间，不过一般好像叫命名空间的多一点...）、配置中心：Config Service（配置服务）；并对外暴露 OpenAPI，为服务的提供者（Provider）和消费者（Consumer）提供注册和获取能力；这些都建立在 Nacos Core 模块的基础之上，底层是一致性协议，支持 priv-raft/sync renew/rdbms based。
3.4 逻辑架构及组件
下图阐述了 Nacos 的逻辑架构，包含了各组件构成及在整个 Nacos 体系中的作用和位置：
3.5 集群部署架构图
集群部署支持三种模式：
因此开源的时候推荐用户把所有服务列表放到一个 vip 下面，然后挂到一个域名下面
- http://ip1:port/openAPI 直连 ip 模式，机器挂则需要修改 ip 才可以使用。
- http://SLB:port/openAPI 挂载 SLB 模式(内网 SLB，不可暴露到公网，以免带来安全风险)，直连 SLB 即可，下面挂 server 真实 ip，可读性不好。
- http://nacos.com:port/openAPI 域名 SLB 模式(内网 SLB，不可暴露到公网，以免带来安全风险)，可读性好，而且换 ip 方便，推荐模式。第三种模式的部署架构图：
3.6 其他
此外，官网对 Nacos 的介绍还包括领域模型设计（数据模型、服务领域模型、配置领域模型），类视图（Nacos-SDK），构建物、部署及启动模式等；部署及运维相关操作可参考运维指南，为求标准建议大家直接学习官方架构文档，这里先不再赘述。
四 网关方案对比
4.1 其他开源网关方案
4.1.1 Traefik
Traefik 是一个现代 HTTP 反向代理和负载均衡器，可以轻松部署微服务，Traeffik 可以与您现有的组件（Docker、Swarm，Kubernetes，Marathon，Consul，Etcd，…）集成，并自动动态配置。
4.1.2 Ambassador
Ambassador 是一个开源的微服务 API 网关，建立在 Envoy 代理之上，为用户的多个团队快速发布，监控和更新提供支持，支持处理 Kubernetes ingress controller 和负载均衡等功能，可以与 Istio 无缝集成。
4.1.3 Tyk
Tyk 是一个开源的、轻量级的、快速可伸缩的 API 网关，支持配额和速度限制，支持认证和数据分析，支持多用户多组织，提供全 RESTful API。基于 go 编写。
4.2 几种网关对比
下面这张图，是比较容易找到，并且在多篇文章都有引用的对比结果，但已经可以追溯到 2019 年了，所以在社区活跃度、各具体特性上已经有了一些变化，这点需要注意，仅作为参考。例如，Zuul2.x 目前最新版本是 2.2.0，发布时间为 2020 年 11 月 21 日，发布数量和更新频率比 Kong 低了很多。
五 小结
关于（API）网关，各大公司有各自不同的侧重和选择，但据了解大部分还是基于开源网关方案的基础，在此之上进行定制开发来支持自己的业务特性。例如 网易严选的网关架构演进之路。如何选择合适的网关方案，也是一个值得深入讨论的问题。初步来看，包括功能、性能、稳定性、扩展能力、跨语言/平台支持、社区活跃度等等。当然具体业务场景还需要做进一步的深入分析，这在后面的文章中会做深入讨论。
