网关是SpringCloud的重要组成部分。网关的作用是作为一种API架构来保护、增强和控制对API服务的访问。API网关是应用或服务之前的一个系统（提供RESTAPI接口服务），用于管理授权、访问控制和流量限制等，使RESTAPI接口服务受到API网关的保护和对所有来电者透明。因此，隐藏在API网关后面的业务系统可以专注于创建和管理服务，而不是处理这些战略基础设施。所谓APIl网关是指系统的统一入口，封装了应用程序的内部结构，为客户端提供统一的服务。一些与业务本身功能无关的公共逻辑可以在这里实现，比如鉴权、鉴权、监听、路由转发等。导致问题1.客户端维护地址困难服务器代码2.认证复杂3.先从跨域问题说起。让我们直接创建一个名为api-getaway的新模块。具体目录如下：gateway具体是ymlserver:port:7000spring:application:name:api-gatewaycloud:nacos:discovery:server-addr:localhost:8848#注册到nacoosgateway:discovery:locator:enabled:true#让网关发现nacos中的微服务routes:#routing数组可以存放多条路由。满足什么条件转发到哪个微服务-id:product_route#当前路由标识，默认uuiduri:http://localhost:8081#转发地址order:1#路由越小，优先级越高predicates:#Assertion(条件判断，返回值为bool，满足条件)可以自定义路由配置详情看AGEROUTER-Path=/product-serv/**#当请求的规则满足filters:#FiltercustomfilterLog-StripPrefix=1#在代码测试的请求转发路径去掉一层：我们可以直接访问原来的商品查询接口，然后通过我们api网关的地址进行查询，实现了我们网关的请求转发。这样一来，又会出现一个问题，就是如果我们频繁修改接口，那么我们就需要经常修改yml文件。有什么办法可以自动找到ip吗？其实是有的，就是我们在nacos中通过服务名来调用。这里我们需要在pom文件中引入nacos，然后在启动类中添加注册发现注解（这个在之前的章节中有介绍，不再赘述）。重要的是我们的yml配置。server:port:7000spring:application:name:api-gatewaycloud:nacos:discovery:server-addr:localhost:8848#注册到nacoosgateway:discovery:locator:enabled:true#让网关发现nacos中的微服务路由:#路由数组可以包含多个路由。满足什么条件转发到哪个微服务-id:product_route#当前路由标识，默认uuid#uri:http://localhost:8081#转发的地址uri:lb://service-product#遵循lb负载均衡by具体微服务识别顺序：1#路由越小，优先级越高谓词：#Assertion（条件判断，返回值为bool，满足条件）可以自定义路由配置详情看AGEROUTER-Path=/product-serv/**#当请求规则满足过滤器时：#过滤自定义过滤器Log-StripPrefix=1#在请求转发路径中去掉一层#-Log=true,false最后的uri是这一行：lb://service-product，注释的很清楚，值得注意的是后面的微服务名称要和nacos保持一致。下面是比较深入的题，一些断言和过滤题。网关包含很多断言：查看地址：https://docs.spring.io/spring...基于日期时间的断言工厂这种类型的断言是根据时间来判断的。主要有三种：AfterRoutePredicateFactory：接收一个日期参数，判断请求的日期是否晚于指定的日期BeforeRoutePredicateFactory：接收一个日期参数，判断请求的日期是否早于指定的日期BetweenRoutePredicateFactory：接收两个日期参数，判断请求的日期是否在指定时间段内Java可以通过ZonedDateTime.now()-After=2022-02-22T17:42:47.666-07:00[Asia/Shanghai]RemoteAddrRoutePredicateFactory基于远程地址断言工厂获取日期值：接收IP地址段，判断请求主机地址是否在该地址段内RemoteAddr=192.168.1.1/24基于Cookie的断言工厂CookieRoutePredicateFactory：接收两个参数，cookie名称和正则表达式。确定请求cookie的给定名称和值是否与正则表达式匹配。-Cookie=巧克力，ch。基于标头的断言工厂HeaderRoutePredicateFactory：接收两个参数，标头名称和正则表达式。确定请求标头是否具有给定的名称并且该值是否与正则表达式匹配。-Header=X-Request-Id,\d+基于主机的断言工厂HostRoutePredicateFactory：接收一个参数，主机名模式。判断请求的Host是否满足匹配规则。‐Host=**.testhost.orgMethodRoutePredicateFactory基于Method请求方法的断言工厂：接收一个参数判断请求类型是否匹配指定类型。‐Method=GETPathRoutePredicateFactory，基于Path请求路径的断言工厂：接收一个参数判断请求的URI部分是否满足路径规则。‐Path=/foo/{segment}基于查询请求参数的断言工厂QueryRoutePredicateFactory:接收两个参数，请求参数和正则表达式，判断请求参数是否具有给定的名称和值与正则表达式匹配。‐查询=baz,ba。WeightRoutePredicateFactory，一个基于路由权重的断言工厂：接收一个[groupname,weight]，然后根据权重转发同组的路由，也就是说如果有十个请求，都发送到product/*，按照1:9的转发。routes:-id:weight_route1uri:host1predicates:-Path=/product/**-Weight=group3,1-id:weight_route2uri:host2predicates:-Path=/product/**-Weight=group3,9这里这些是一些断言工厂。自定义断言让我们设置一个场景：假设我们的应用程序只允许年龄在(min,max)之间的人访问。routes:#routing数组可以容纳多条路由。满足什么条件转发到哪个微服务-id:product_route#当前路由标识，默认uuid#uri:http://localhost:8081#转发的地址uri:lb://service-product#遵循lb负载均衡by具体微服务识别顺序：1#路由越小，优先级越高谓词：#Assertion（条件判断，返回值为bool，满足条件）可以自定义路由配置详情看AGEROUTER-Path=/product-serv/**#当请求规则满足时-Age=18,60#限制18到60人filters:#FiltercustomfilterLog-StripPrefix=1#去掉请求转发路径中的一层，新建一个相关类，该类需要Notice。网关定制；路由断言工厂前面必须加上-age（可以在配置yml文件中自定义）+RoutePredicateFactory通过age自定义断言年龄。我们的输入是有一个正确范围的，但是如果输入不在范围内，就会有错误提示。FilterSpringCloudGateway的Filter生命周期没有Zuul丰富，它只有两个：“pre”和“post”。PRE：在路由请求之前调用此过滤器。我们可以使用这个过滤器来实现鉴权，在集群中选择请求的微服务，记录调试信息等。过滤器类型SpringCloudGateway的Filter从作用范围上可以分为另外两种类型，GatewayFilter和GlobalFilter。GatewayFilter：应用于单个路由或一组路由。GlobalFilter：应用于所有路由。部分过滤器部分过滤器（GatewayFilter），是针对单个路由的过滤器。它可以过滤访问的URL并进行面对面的处理。在SpringCloudGateway中以GatewayFilter的形式构建了许多不同类型的本地过滤器。这是SpringCloudGateway内置的所有过滤器工厂的简单表格。虽然不是很详细，但可以作为一个快速概览。如下：每个过滤器工厂对应一个实现类，这些类的名字必须以GatewayFilterFactory结尾，这是\SpringCloudGateway的约定。比如AddRequestHeader对应的实现类是\AddRequestHeaderGatewayFilterFactory。这些过滤器的使用方法请参考官方文档\GlobalFilter全局过滤器（GlobalFilter）作用于所有路由。SpringCloudGateway定义了GlobalFilter接口，用户可以自定义自己的GlobalFilter。通过全局过滤器可以实现权限统一验证、安全验证等功能，全局过滤器也是程序员用的比较多的一个过滤器。在内部，SpringCloudGateway通过一系列内置的全局过滤器来处理整个路由转发，如下：还是需要我们自己写一个filter来实现，那我们一起用代码的形式自定义一个filter来完成统一的权限验证。认证逻辑开发中的认证逻辑：当客户端第一次请求服务时，服务端对用户进行信息认证（登录）认证，将用户信息加密形成token，返回给客户端作为logincredential对于每个请求，客户端携带经过身份验证的token，服务器对token进行解密，判断其是否有效。如上图所示，可以在网关层统一检查验证用户是否登录的过程。检验标准是请求是否携带token证书和token的正确性。具体代码实现这是网关的基本实现。如果用的比较仔细，还是要根据业务情况进行更改。后面我会继续补充这个项目，喜欢就点start吧~项目源码参考分支220217_xgc_gatewayGitee:https://gitee.com/coderxgc/sp...GitHub:https://github.com/coderxgc/s...
