Gateway网关
提供一种简单而有效的方式对API进行路由,以及提供强大的过滤器的功能。(webflux是一种异步非阻塞的框架),也算是一种微服务,需要注册中心注册。
使用:
导入依赖:
application.yml的配置:
server:
port: 9527
spring:
application:
name: cloud-gateway
cloud:
gateway:
discovery:
locator:
enabled: true #开启从注册中心动态创建路由的功能,利用微服务名进行路由
routes:
- id: payment_routh #payment_route #路由的ID,没有固定规则但要求唯一,建议配合服务名
#uri: http://localhost:8001 #匹配后提供服务的路由地址,路由代替的就是这个地址
uri: lb://cloud-payment-service #匹配后提供服务的路由地址,lb表示负载均衡的去找服务
predicates:
- Path=/payment/get/** # 断言,路径相匹配的进行路由
- id: payment_routh2 #payment_route #路由的ID,没有固定规则但要求唯一,建议配合服务名
#uri: http://localhost:8001 #匹配后提供服务的路由地址
uri: lb://cloud-payment-service #匹配后提供服务的路由地址,lb表示启用Gateway负载均衡的去找服务
predicates:
- Path=/payment/lb/** # 断言,路径相匹配的进行路由
#- After=2020-02-21T15:51:37.485+08:00[Asia/Shanghai]#设置时间,在这个时间以后断言才为真
#- Cookie=username,zzyy #设置访问Cookie中必须带有username
#- Header=X-Request-Id, \d+ # 请求头要有X-Request-Id属性并且值为整数的正则表达式
eureka:
instance:
hostname: cloud-gateway-service
client: #服务提供者provider注册进eureka服务列表内
service-url:
register-with-eureka: true
fetch-registry: true
defaultZone: http://eureka7001.com:7001/eureka
网关说白了就是不想暴露原有服务的端口号,在其套上一层端口号,并提供过滤器,断言等功能,防止攻击和入侵。
动态路由就是不将被套端口写死,写成一个服务名
需要开启动态路由的规则:
过滤器:
需要实现两个接口才能使用
/**
* 网关过滤器,本过滤器设置必须有名字才能访问
*/
@Component
@Slf4j
public class MyLogGateWayFilter implements GlobalFilter,Ordered
{
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain)
{
log.info("***********come in MyLogGateWayFilter: "+new Date());
//获取当前访问的用户名
String uname = exchange.getRequest().getQueryParams().getFirst("uname");
if(uname == null)
{
log.info("*******用户名为null,非法用户,o(╥﹏╥)o");
//如果用户名为空,则将状态调整为不接收
exchange.getResponse().setStatusCode(HttpStatus.NOT_ACCEPTABLE);
return exchange.getResponse().setComplete();
}
return chain.filter(exchange);
}
@Override
public int getOrder()
{
return 0;
}
}
Config
配置中心的出现是因为微服务的数量增多,导致配置文件有可能出现大量的冗余(比如说数据库的连接),所以就将冗余的部分提取出来作为一个配置中心,一般都放在github上,用配置去提取。
使用:
导入依赖:
server:
port: 3344
spring:
application:
name: cloud-config-center #注册进Eureka服务器的微服务名
cloud:
config:
server:
git:
uri: git@github.com:zzyybs/springcloud-config.git #GitHub上面的git仓库名字
####搜索目录
search-paths:
- springcloud-config
####读取分支
label: master
#服务注册到eureka地址
eureka:
client:
service-url:
defaultZone: http://localhost:7001/eureka
##rabbitmq相关配置,暴露bus刷新配置的端点
management:
endpoints: #暴露bus刷新配置的端点
web:
exposure:
include: 'bus-refresh'
主启动类需要标注:
当启动服务时,就可以访问到配置文件内容。
上述操作是 配置中心服务端的操作,下面是客户端的操作:
导入依赖:
配置文件叫 bootstrap.yml,他会在项目加载时,同时加载这个名字的配置文件。
配置文件内容(客户端的配置文件就应该去找服务端配置中心):
server:
port: 3355
spring:
application:
name: config-client
cloud:
#Config客户端配置
config:
label: master #分支名称
name: config #配置文件名称
profile: dev #读取后缀名称 上述3个综合:master分支上config-dev.yml的配置文件被读取http://config-3344.com:3344/master/config-dev.yml
uri: http://localhost:3344 #配置中心地址k
但是当github上的配置文件发生改变时,Config的服务端会同时改变,但客户端只有重启才能改变,所以这个就需要一个监控,并让客户端暴露监控点:
在客户端的Controller加上:
这些都配置完后,再在cmd中的发送一个命令才能改变:
但是当客户端多的时候也不可能每个都去这样的发送,所以就有了下面的 BUS。
BUS
这里使用 RabbitMQ作为通知:
给客户端和服务端都导入:
并在配置文件中都加入:
此时只需要刷新一下 服务端的配置即可:
定点通知只需要配上 服务名加端口号就可:
Stream消息驱动
因为消息中间件有很多,不同人学习的中间件也不一样,为了排除这种差异性,就使用 Stream消息驱动 去除这种差异性。
但目前仅支持 RabbitMQ和Kafka
这里以 RabbitMQ为例:
导入依赖:
application.yml配置:
server:
port: 8802
spring:
application:
name: cloud-stream-consumer
cloud:
stream:
binders: # 在此处配置要绑定的rabbitmq的服务信息;
defaultRabbit: # 表示定义的名称,用于于binding整合
type: rabbit # 消息组件类型
environment: # 设置rabbitmq的相关的环境配置
spring:
rabbitmq:
host: localhost
port: 5672
username: guest
password: guest
bindings: # 服务的整合处理
input: # 这个名字是一个通道的名称
destination: studyExchange # 表示要使用的Exchange名称定义
content-type: application/json # 设置消息类型,本次为对象json,如果是文本则设置“text/plain”
binder: defaultRabbit # 设置要绑定的消息服务的具体设置
Sleuth分布式请求链式追踪
在微服务架构中,一个由客户端发起的请求会经过多个不同的服务节点调用来协同产生最后的请求结果,每一个前端请求都会产生一条复杂的的分布式服务调用链路,链路中任何一环出现延迟或错误都会导致整个的失败,Sleuth就是提供监控功能,可以看到调用的整个链路,包括故障的所在