我们使用Spring Cloud Netflix中的Eureka实现了服务注册中心以及服务注册与发现;而服务间通过Ribbon或Feign实现服务的消费以及均衡负载;通过Spring Cloud Config实现了应用多环境的外部化配置以及版本管理。为了使得服务集群更为健壮,使用Hystrix的融断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。
在这样的架构中,对外服务Open Service这块,直接暴露我们的服务地址,这样的实现是不合理的,它破坏了服务无状态特点,无法直接复用既有接口。解决这些问题,就是服务网关了。
Spring Cloud Netflix中的Zuul就起到了服务网关的作用,添加服务网关Zuul后,不管是来自于客户端(PC或移动端)的请求,还是服务内部调用。一切对服务的请求都会经过Zuul这个网关,然后再由网关来实现 鉴权、动态路由等等操作。Zuul就是我们服务的统一入口。
Zuul是Netflix开源的微服务网关,他可以和Eureka、Ribbon、Hystrix等组件配合使用,它的核心是一些列的过滤器,这些过滤器可以实现的功能:身份认证与安全、审查与监控、动态路由、压力测试、负载分配、静态响应处理、多区域弹性。
服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中,除了具备服务路由、均衡负载功能之外,它还具备了权限控制等功能。
Spring Cloud Netflix中的Zuul就起到了服务网关的作用,为微服务架构提供了前门保护的作用,同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面,使得服务集群主体能够具备更高的可复用性和可测试性。
在前几篇博客所建立的的案例的基础上
org.springframework.cloud
spring-cloud-starter-netflix-zuul
server:
port: 10010
spring:
application:
name: api-gateway
zuul:
routes:
producer-service: # 这里是路由id,随意写
path: /producer-service/** # 这里是映射路径
url: http://127.0.0.1:8081 # 映射路径对应的实际url地址
@SpringBootApplication
@EnableZuulProxy // 开启Zuul的网关功能
public class ZuulDemoApplication {
public static void main(String[] args) {
SpringApplication.run(ZuulDemoApplication.class, args);
}
}
上边这种实现方式,服务对应的地址url是写死的,实际上我们应该从Eureka注册中心查找服务对应的所有实例列表,然后进行动态路由才对!
1)添加依赖
org.springframework.cloud
spring-cloud-starter-netflix-eureka-client
2)修改配置文件
eureka:
client:
registry-fetch-interval-seconds: 5 # 获取服务列表的周期
service-url:
defaultZone: http://127.0.0.1:10086/eureka
instance:
prefer-ip-address: true
ip-address: 127.0.0.1
zuul:
routes:
producer-service: # 这里是路由id,随意写
path: /producer-service/** # 这里是映射路径
serviceId: producer-service # 指定服务名称
3)在启动文件中添加注解@EnableDiscoveryClient,开启Eureka客户端发现功能
@SpringBootApplication
@EnableZuulProxy // 开启Zuul的网关功能
@EnableDiscoveryClient // 开启Eureka客户端发现功能
public class ZuulDemoApplication {
public static void main(String[] args) {
SpringApplication.run(ZuulDemoApplication.class, args);
}
}
关于路由配置,可简化
原来的格式:
zuul.routes.route.path=/xxx/**
zuul.routes.route.serviceId=/xxx
简化后:
zuul.routes.serviceId=path
也可配置添加访问前缀
Zuul中默认就已经集成了Ribbon负载均衡和Hystix熔断机制。但是所有的超时策略都是走的默认值,比如熔断超时时间只有1S,很容易就触发了。因此我们需要手动进行配置
zuul:
retryable: true
ribbon:
ConnectTimeout: 250 # Ribbon的连接超时时间
ReadTimeout: 1000 # Ribbon的数据读取超时时间
OkToRetryOnAllOperations: true # 是否对所有操作都进行重试
MaxAutoRetriesNextServer: 1 # 切换实例的重试次数
MaxAutoRetries: 1 # 对当前实例的重试次数
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMilliseconds: 6000 # 设置Hystrix的超时时间为6000ms,默认是1000ms