gateway动态路由_spring-cloud-gateway简介

概述

API网关出现的原因是微服务架构的出现，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求。如果让客户端直接与各个微服务通信，会有以下的问题：

客户端会多次请求不同的微服务，增加了客户端的复杂性。
存在跨域请求，在一定场景下处理相对复杂。
认证复杂，每个服务都需要独立认证。
难以重构，随着项目的迭代，可能需要重新划分微服务。例如，可能将多个服务合并成一个或者将一个服务拆分成多个。如果客户端直接与微服务通信，那么重构将会很难实施。
某些微服务可能使用了防火墙 / 浏览器不友好的协议，直接访问会有一定的困难。

以上这些问题可以借助API网关解决。API网关是介于客户端和服务器端之间的中间层，所有的外部请求都会先经过 API 网关这一层。也就是说，API 的实现方面更多的考虑业务逻辑，而安全、性能、监控可以交由API网关来做，这样既提高业务灵活性又不缺安全性。

由于篇幅比较长, 决定分几篇来介绍相关知识:

spring-cloud-gateway简介+基本环境搭建
spring-cloud-gateway过滤器+审计
spring-cloud-gateway静态路由
spring-cloud-gateway动态路由
spring-cloud-gateway限流+过载保护
spring-cloud-gateway认证
spring-cloud-gateway鉴权

环境参数

开发工具: IDEA
基础工具: Maven+JDK8
SpringBoot版本: 2.1.4.RELEASE
SpringCloud版本: Greenwich.SR3
服务发现: consul

consul搭建可以参照官网,开箱即用。也可以参照Docker实战之Consul集群基于docker环境搭建。

SpringCloud项目搭建

项目pom.xml

<?xml version="1.0" encoding="UTF-8"?>

服务提供者1(服务提供+服务消费)

pom.xml

<?xml version="1.0" encoding="UTF-8"?>

配置文件application.yml

spring

SpringBoot项目入口Provider1App.java

@EnableFeignClients

远程调用RemoteService.java

@FeignClient

web服务

@RestController

服务提供者2(服务提供)

provider2和provider1类似，这里只改写下web实现类

@RestController

Feign中集成了Ribbon负载均衡。这里可以用不同端口启动2个provider2实例, 然后通过provider1调用provider2，可以看到轮询输出不同的端口。

网关服务

pom.xml

<?xml version="1.0" encoding="UTF-8"?>

application.yml

server

启动类

@SpringBootApplication

结语

到这里基本环境就搭建完毕了，下节做过滤器的相关实现。感谢大家阅读，欢迎关注公众号【当我遇上你】学习交流。