微服务 API 网关对比和选型
什么是微服务
微服务架构（通常简称为微服务）是指开发应用所用的一种架构形式。通过微服务，可将大型应用分解成多个独立的组件，其中每个组件都有各自的责任领域。
在处理一个用户请求时，基于微服务的应用可能会调用许多内部微服务来共同生成其响应。微服务是互联网业务发展的结果，互联网业务的飞速发展导致系统的架构也在不断地发生变化，总体来说，系统的架构大致经历了：单体应用架构—>
SOA 架构—>微服务架构 的演变，具体发展历程和各自的优缺点如下表所示。
因此，微服务是互联网发展的必然结果，很多传统公司的系统架构也在逐步微服务化。但是，随着互联网业务的发展，API 的数量也在剧增，使用网关对API统一管理也将面临挑战，选择一个更强大的 API 网关，可以有效地增强系统的监控、容灾、鉴权和限流等能力。
什么是微服务网关
API网关是一个服务器，是系统的唯一入口。 从面向对象设计的角度看，它与外观模式类似。
API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、协议转换、限流熔断、静态响应处理。
API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。 通常，网关也是提供REST/HTTP的访问API。
微服务网关作为微服务后端服务的统一入口，它可以统筹管理后端服务，主要分为数据平面和控制平面：
数据平面主要功能是接入用户的HTTP请求和微服务被拆分后的聚合。使用微服务网关统一对外暴露后端服务的API和契约，路由和过滤功能正是网关的核心能力模块。另外，微服务网关可以实现拦截机制和专注跨横切面的功能，包括协议转换、安全认证、熔断限流、灰度发布、日志管理、流量监控等。 控制平面主要功能是对后端服务做统一的管控和配置管理。例如，可以控制网关的弹性伸缩；可以统一下发配置；可以对网关服务添加标签；可以在微服务网关上通过配置Swagger功能统一将后端服务的API契约暴露给使用方，完成文档服务，提高工作效率和降低沟通成本。
微服务遇到的挑战
微服务网关应该首先要具备 API 路由能力，微服务数量变多，API 数量急剧增加，网关还可以根据具体的场景作为流量过滤器来使用，以提供某些额外可选功能，因此对微服务 API Gateway 提出了更高要求，比如：
- 可观测性：在以往的单体应用中，排查问题往往通过查看日志定位错误信息和异常堆栈；但是在微服务架构中服务繁多，出现问题时的问题定位变得非常困难；因此，如何监控微服务的运行状况、当出现异常时能快速给出报警，这给开发人员带来很大挑战。
鉴权认证：而微服务架构下，一个应用会被拆分成若干个微应用，每个微应用都需要对访问进行鉴权，每个微应用都需要明确当前访问用户以及其权限。尤其当访问来源不只是浏览器，还包括其它服务的调用时，单体应用架构下的鉴权方式就不是特别合适了。在微服务架构下，要考虑外部应用接入的场景、用户 -
- 服务的鉴权、服务 - 服务的鉴权等多种鉴权场景。
- 系统稳定性：若大量请求超过微服务的处理能力时，可能会将服务打垮，甚至产生雪崩效应、影响系统的整体稳定性。
- 服务发现：微服务的分散管理，让微服务的负载均衡的实现也更具有挑战性。
解决方案
API 网关作为客户端和服务端的中间桥梁，为微服务系统提供统一的管理机制： 除了基础的请求分发、API 管理和条件路由等功能，还包括身份验证、监控报警、调用链追踪、负载均衡、限流隔离和熔断降级。身份认证：下图表示的是微服务联合 API 网关如何进行身份认证的，由图可见所有请求都通过网关，从而有效地隐藏了微服务。
监控报警/调用链追踪：
API 作为客户端和服务端的中间桥梁，是微服务监控的最好载体，API 网关监控功能的主要职责是及时发现网关以及后端服务器的连接异常，在 API
的监控平台上面用户可以随时查看日志信息，监控信息，调用链等等，并且主机发生的任何异常都会自动报警到控制台。有些网关甚至可以做到给客户端和服务端双向报警。
限流隔离/熔断降级： 随着互联网业务规模的增加，系统的并发度增高，多个服务之间相互调用链路，一条核心链路往往可能调用十个服务。如果在链路中，某个服务的 rt（响应时间）急剧上升，上游服务不断请求，造成恶性循环，上游等待结果线程数越多，使得更上游服务阻塞最终整条链路无法使用，从而导致服务雪崩，所以对入口流量进行整治管理是很有必要的，下图表示微服务系统是如何结合 API 网关进行限流隔离和熔断降级的。
主流网关选择
在微服务领域，有许多开源网关实现，有 NGINX、Kong、Apache APISIX 和 Envoy 等，Java 技术栈的有 Netfilx Zuul、Spring Cloud Gateway、Soul 等。或许你会问“有了 NGINX 和 Kong，为什么还需要 Apache APISIX？” ，下面做个简单对比。
| 网关 | 痛点 | 优势 |
|---|---|---|
| NGINX | 修改配置需要 Reload 才能生效，跟不上云原生的发展。 | 1. 老牌应用；2. 稳定可靠，久经考验；3. 高性能。 |
| Apache APISIX | 文档不够丰富和清晰，需要待改进。 | 1. Apache 基金会顶级项目；2. 技术架构更贴合云原生；3. 性能表现优秀；4. 生态丰富；5. 除了支持 Lua 开发插件外，还支持 Java、Go、Python、Node 等语言插件 |
| Kong | 1. 默认使用 PostgreSQL 或 Cassandra 数据库，使得整个架构非常臃肿，并且会带来高可用的问题；2. 路由使用的是遍历查找，当网关内有超过上千个路由时，它的性能就会出现比较急剧的下降；3. 一些重要功能是需要付费的。 | 1. 开源 API 网关的鼻祖，用户数众多；2. 性能满足大部分用户的需求；3. 生态丰富；4. 支持 Lua 和 Go 开发插件。 |
| Spring Cloud Gateway | 虽然 Spring 社区成熟，但是 Gateway 资源缺乏。 | 1. 内置了非常多的开箱即用功能，并且都可以通过 SpringBoot 配置或者手工编码链式调用来使用；2. Spring 系列可扩展性强，易配置，可维护性好； 3. Spring 社区成熟；4. 简单易用；5. 对于 Java 技术栈来说方便 |
| Traefik | 生产案例不太多 | 1. 基于 golang开发 2. 云原生可编程 api/对接各种服务发现 |