springcloud gateway option 请求慢_【实战】搭建Spring Cloud新一代网关Gateway

人生可以有过错，但不能有错过；意志决定你的成功，进取决定你的未来；怀疑和等待你永远看不到未来，拼搏的人生才会更精彩 ！

---

上篇文章主要分享了一下API网关相关理论知识，这篇文章我们主要介绍一下使用Spring Cloud的Gateway搭建API 网关。

首先我们先简单回顾一下，什么是API网关呢？通俗说就是介于客户端与服务端之间一个接受所有请求的系统服务，解决微服务架构中客户端直接请求服务端存在的一些问题。比如有这样一个场景：像一个电商网站的产品详情页面不仅包含基本的产品信息(如名称、描述、价格)还包括购物车中的商品数量、历史订单、客户评论、低库存预警、送货选项、各种推荐、其它的购物选择等，若采用微服务架构，显示在产品页上的数据会分布在不同的微服务上，可能有：购物车服务：提供购物车中的件数；订单服务提供历史订单数据；目录服务：提供商品基本信息，如名称、图片和价格等；评论服务提供对客户评论的支持；库存服务提供对低库存预警的支持；送货服务提供送货选项、期限和费用，这些信息单独从送货方API获取；推荐服务提供给用户推荐商品的支持等等。

上述场景如果客户端直接和服务端通信会存在什么问题呢？

问题一：客户端需要和每个微服务暴露的细粒度API去匹配。在上述场景中，显示一个产品页面客户端需要发送7个独立请求。在更复杂的应用程序中，可能要发送更多的请求，毋庸置疑页面加载效率很低而且客户端代码会很复杂。

问题二：各个服务使用的协议不同，可能是Thrift 二进制 RPC，AMQP 消息传递协议，或应用程序应该使用HTTP和 WebSocket 之类的协议，所以客户端需要实现多种协议的请求。

问题三：它会使得微服务难以重构，随着时间推移，我们可能想要更改系统拆分成服务的方式。例如，我们可能合并两个服务，或者将一个服务拆分成两个或更多服务。然而，如果客户端与微服务直接通信，那么执行这类重构就非常困难了。

使用API网关可以很好解决上述问题，API网关是提供系统唯一入口的服务，封装了内部系统架构，并向客户端提供API，解放了客户端的复杂编码，客户端不需要知道每个微服务的端口和ip；还有是可能各个服务的协议也是不同的，那么客户端也不需要关心请求服务的协议，网关对外统一暴露http协议，然后网关实现协议的转换，然后请求到不同的微服务；如果微服务进行了重构，客户端也不要跟着变，客户端调整也很方便。除此之外，它还可能负责诸如用户验证、监控、负载均衡、缓存、请求管理、静态响应处理等功能。

当然，任何事情都是有利有弊，使用API网关也有弊端：①增加了一个需要开发、部署和维护的高可用组件；②API网关有时候变成了开发的瓶颈。开发者为了暴露新的微服务必须更新API网关，API网关的更新流程要尽可能的简单，否则，开发人员不得不排队等待。尽管它有这些不足，但对于大部分的应用程序而言，使用 API 网关是合理的。

Spring Cloud 网关 Gateway

接下来我们搭建 Spring Cloud的新一代网关Gateway，估计很多小伙伴之前