本文为稀土掘金技术社区首发签约文章，14天内禁止转载，14天后未获授权禁止转载，侵权必究！
又来给大家更文了。
最近签约了掘金第二期，开了一个新专栏打算给大家带来一波微服务网关实战的系列文章，先来说说为啥写这个系列吧。
今年换工作之后，我就来到了现在所在的业务组，刚来的时候我们业务组并没有一个属于自己的网关系统，很多业务上需要的处理例如：封IP、url重定向服务、限流还需要找运维在 Nginx 层做处理，包括我未来要做的链路追踪 / 流量大屏之类的功能也需要一个网关型的东西在所有服务的最前方，所以有一个属于我们自己的业务网关是我急切渴望的一个事，毕竟你不能整天指望运维给你在 Nginx 层做一些你想要的个性化处理吧。
而且当时我们的服务频频被人刷，已经严重影响到线上业务运行，虽然做了一个服务限流，但是由于是在服务内的限流，所以占用线程资源是必不可少的，这也不是一个很好的解决方案。
基于以上考虑，我上个季度的 OKR 就定为了搭建一个业务网关，目前我做的网关也已经在生产环境非常稳定的跑了一段时间，有了这个经验之后，我正好将相关的东西整理一下拿来写本系列文章。
当然，除去上面的工作需要之外，网关确实可以做很多别的事，比如：流量控制、请求拦截、权重分发、服务下线、链路追踪、服务熔断等操作。
说完了我写文的动机，再来聊聊读者们能从我这里获得什么吧，没有价值的文章是没有写的必要的，虽然我在处理网关方面问题时也参考了许多网上的文章，但是可用的文章很少很少，更多还是要通过自己的知识体系去尝试一遍之后才可行，所以我才要写点有参考价值的东西出来，帮助大家少走弯路。
在本系列文章中，我着重要讲的是如何从 0 到 1 搭建一个完整可用的网关，并且会处理网关常见的一些问题比如：
及时感知服务上下线。流量限流。服务熔断。链路追踪。
同时，还有必要给网关搭建一个控制台，利用图形化的优势增加操作便利性，减少出错的可能性。
涉及到的中间件主要有网关中间件（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 没的它也有，非常之方便。
最后
今天的这篇文章没有技术点，本篇的重点是选型，主要是我在进行微服务网关选型中的一点想法，同时也带大家先熟悉一下这两个网关中间件，可能我们还没用过它，但是软件向来都是自顶向下，有一个全局的了解，哪怕没有用过你也等于了解它一半了。
不过想冲进来学习 Spring Cloud Gateway 的读者也不要伤心，今天同时发两篇文章，第二篇开始就是 Spring Cloud Gateway 的技术文章了，链接在这：「微服务网关实战二」SCG + Nacos 动态感知上下线
最后，希望各位读者大人们抬抬手点点赞，你们的赞与评论就是我更新的最大动力，下篇见。
