JAVA的微服务网关实操【一】：SCG 和 APISIX 到底应该怎么选择？

前言

一、JAVA的微服务网关实操【一】：SCG 和 APISIX 到底应该怎么选择？

二、JAVA的微服务网关实操【二】：SCG Nacos 实现动态的感知上下线

三、JAVA的微服务网关实操【三】：很详细介绍并理解 SCG 路由和断言与过滤器

在本系列文章中，我着重要讲的是如何从 0 到 1 搭建一个完整可用的网关，并且会处理网关常见的一些问题比如：

1. 及时感知服务上下线。
2. 流量限流。
3. 服务熔断。
4. 链路追踪。

同时，还有必要给网关搭建一个控制台，利用图形化的优势增加操作便利性，减少出错的可能性。

涉及到的中间件主要有网关中间件（Spring Cloud Gateway）、配置中心（Nacos）、注册中心（Nacos）和熔断器（Sentinel），相关的选型我会在本文最后揭晓，除了这些之外，其他的中间件如 APISIX 和 另一个熔断器我会作为补充文章后续发出来，本系列的主体文章也不涉及太多的源码解析，后续我如果写的话也是在最后作为补充文章发到这个专栏，如果文章对你有所帮助可以点个赞支持一下，现在进入正文。

网关中间件选型

在本次做网关的过程中，摆在我面前的第一个问题就是，用哪个中间件作为网关？

虽然我原来没做过网关，但是目前业内比较知名的网关中间件有两个：Spring Cloud Gateway 和 APISIX，熟悉 Java 的读者应该对Spring Cloud Gateway 都有一些或多或少的了解，毕竟属于 Spring Cloud 家族系列，是 Java 业务开发者每天都会接触到的东西。

而 APISIX 可能相对于 Spring Cloud Gateway 来说名气并没有那么大，但是它出身是 Apache 软件基金会，所以技术方面还是有实力保障的，而且国内很多企业也都在落地实践了，各个场景下也都有一些比较成熟靠谱的解决方案，也是一个非常不错的中间件。

但是无论它们功能如何，立足实际才是我们进行技术选型时最重要的一点，接下来我们先看看介绍了解一下它们，再来谈选型。

APISIX

我把 APISIX 放在第一个介绍，因为大家可能对它会更陌生一点。

Apache APISIX 是 Apache 软件基金会下的云原生 API 网关，它兼具动态、实时、高性能等特点，提供了负载均衡、动态上游、灰度发布（金丝雀发布）、服务熔断、身份认证、可观测性等丰富的流量管理功能。我们可以使用 Apache APISIX 来处理传统的南北向流量，也可以处理服务间的东西向流量。同时，它也支持作为 K8s Ingress Controller 来使用。

从上面的介绍中，我大概提炼出两个要点：云原生 支持 K8S，其他的功能一般的网关都具备，所以我单独拎这两个特点来说一说。

云原生：它代表了 APISIX 不是由 Java 语言所写的，虽然 Java 也会老将云原生拿出来提，但是因为其启动速度以及内存方面的原因，一般的 Java 应用是不符合云原生定义的。

支持K8S：现代大型应用一般都使用K8S作为服务编排中间件，而 APISIX 作为一个网关中间件支持作为 K8s Ingress Controller 来使用则代表了它可以完全接管 K8S 的请求分发，这对使用 K8S 的作为容器编排的技术架构来说是一个非常方便的功能，加之 APISIX 提供了 APISIX Dashboard 来进行可视化路由操作，这会大大降低运维人员的负担。

APISIX 所采用的技术栈是 NGINX Lua，它还有一个自己的维护的 NGINX 发行版，加上 Lua 脚本做动态性处理达到配置即时生效的目的，除此之外 NGINX Lua 也给 APISIX 带来了巨大的吞吐量和很少的内存占用。

通过以上这些可以看出 APISIX 确实是为大型服务网关而生的，它非常契合云原生环境下软件的特性，并且除了优异的性能之外还具有非常方便的可视化控制台：

并且，虽然它不是主流开发语言所开发的，但是你却可以通过主流开发语言开发它的插件来提供一些自定义功能，以下是它的架构图，图片来自于其官网：

可以看到它的插件系统支持 Java、Go、Python 等主流语言，所以对于一些技术栈不是 Lua 的开发团队也能很好的上手使用。

Spring Cloud Gateway

Spring Cloud Gateway 在 Java 生态中也算是一个比较老牌的网关中间件了，原来Java的网关中间件是由 Zuul 扛大旗的，不过由于 Zuul2 的一再跳票，Spring 自己造了一个网关中间件就是 Spring Cloud Gateway，而且性能要比 Zuul 更加强大。

Spring Cloud Gateway 是在 Spring WebFlux 的基础上构建的网关中间件，Spring WebFlux 则是 Spring 家族的一个异步非阻塞 Web 容器，采用了开源项目 Project Reactor 提供了 Reactor 模式进行异步非阻塞编程，Spring Cloud Gateway 提供了以下几个特性：

• 基于 Spring Framework 5、Project Reactor 和 Spring Boot 2.0 构建
• 能够匹配任何请求属性的路由。
• 谓词和过滤器特定于路由。
• 断路器集成。
• Spring Cloud Discovery 客户端集成
• 易于编写谓词和过滤器
• 请求速率限制
• 路径重写

我简单总结一下，其实就是：高性能 路由能力强 熔断器集成 限流器集成，这几个特点中高性能就不用介绍了，其他的几个特点在后面的文章中我们都有更加详细的介绍。

Spring Cloud Gateway 的实现方案是用责任链模式实现的，设计模式中叫责任链，立足于实际中就是一串 Java 中的过滤器，就像下面这样：

Spring 家族中除了 Gateway 项目之外，Spring Security 也是用这种方案实现的，我之前深入了解过，感兴趣的读者可以翻阅我之前的文章。

责任链模式有一个很大的优点就是扩展性强，你有什么需求往里面加一个过滤器一般就能满足了，不过由于 Gateway中 使用了 Reactor 项目，所以上手起来比起我们经常写的 Spring 模式代码还是有一点难度的，不太熟悉的读者刚上手的时候可能会对 Reactor 一脸懵，因为你要理解它背后的异步思想之后才能正确的写代码，不然可能代码根本不会运行，别问我怎么知道的~

选型要点

前面我说了，技术选型要立足于实际，上面我简单带大家了解了一下这两个中间件，如果让你各说出一个它们最大的优点，你脑海中会有什么想法？说说我的想法：

• APISIX：性能高。
• Spring Cloud Gateway：易于扩展。

这个时候再想想我最需要什么？我需要的是一个能够快速上手的网关帮我处理一些业务痛点，然而快速上手一定是要有一个前提就是：熟悉它。

对于 APISIX 我显然是不够熟悉的，甚至连它的开发语言 Lua 的语法都不熟悉，虽然它自带了 Java 插件可以帮助我，但是上手还是有一定的成本，而且因为它不是 Java，所以我如果使用它还需要找运维帮我安装且售后。

反观 Spring Cloud Gateway 这边，性能足够用，同时它是 Java 语言编写，我扩展起来也会非常方便，更重要的是因为它是一个纯 Java 项目，我可以对它有百分百的控制权，所以思考到这，我这次的技术选型就是 Spring Cloud Gateway 了。

不过我没选并不代表 APISIX 差，如果你要做一个公司的总网关，也就是全面代替NGINX的那层网关，我非常且极力的推荐 APISIX，光是一个可视化配置就能够提高很高效率，NGINX 有的它全有，NGINX 没的它也有，非常之方便。

这篇好文章是转载于：学新通技术网