微服务网关方案：Kong & Nacos
系列文章：
一 摘要
前面我们介绍了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
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其实本身包含了服务注册中心、配置中心、网关等一系列功能，这几个部分分别可以对应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的不断完善，目前已经无缝支持一些主流的开源生态，例如
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下面，然后挂到一个域名下面
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）网关，各大公司有各自不同的侧重和选择，但据了解大部分还是基于开源网关方案的基础，在此之上进行定制开发来支持自己的业务特性。例如 。如何选择合适的网关方案，也是一个值得深入讨论的问题。初步来看，包括功能、性能、稳定性、扩展能力、跨语言/平台支持、社区活跃度等等。当然具体业务场景还需要做进一步的深入分析，这在后面的文章中会做深入讨论。