人生可以有过错,但不能有错过;意志决定你的成功,进取决定你的未来;怀疑和等待你永远看不到未来,拼搏的人生才会更精彩 !
上篇文章主要分享了一下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,估计很多小伙伴之前