通过前面的学习,使用Spring Cloud实现微服务的架构基本成型,大致是这样的:
我们使用Spring Cloud Netflix中的Eureka实现了服务注册中心以及服务注册与发现;而服务间通过Ribbon或Feign实现服务的消费以及均衡负载;通过Spring Cloud Config实现了应用多环境的外部化配置以及版本管理。为了使得服务集群更为健壮,使用Hystrix的融断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。
在该架构中,我们的服务集群包含:内部服务Service A和Service B,他们都会注册与订阅服务至Eureka Server,而Open Service是一个对外的服务,通过均衡负载公开至服务调用方。我们把焦点聚集在对外服务这块,直接暴露我们的服务地址,是否有更好的实现方式呢?
这样架构需要做的一些事儿以及存在的不足:
从具体开发和测试的角度来说,在工作中除了要考虑实际的业务逻辑之外,还需要额外考虑对接口访问的控制处理。
为了解决上面这些问题,我们需要将权限控制这样的东西从我们的服务单元中抽离出去,而最适合这些逻辑的地方就是处于对外访问最前端的地方,我们需要一个更强大一些的均衡负载器的 服务网关。
服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中,除了具备服务路由、均衡负载功能之外,它还具备了权限控制等功能。Spring Cloud Netflix中的Zuul就担任了这样的一个角色,为微服务架构提供了前门保护的作用,同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面,使得服务集群主体能够具备更高的可复用性和可测试性。
1、访问 http://start.spring.io/
2、选择构建工具 Maven Project、Java、Spring Boot 版本 2.1.3 以及一些工程基本信息,可参考下图所示:依赖选择Zuul
3、点击 Generate Project 下载项目压缩包
4、解压后,使用 Idea 导入项目,File -> New -> Model from Existing Source… -> 选择解压后的文件夹 -> OK,选择 Maven 一路 Next,OK done!
5、引导类上通过@EnableZuulProxy注解开启Zuul的功能:
@SpringBootApplication
@EnableZuulProxy
public class DemoZuulApplication {
public static void main(String[] args) {
SpringApplication.run(DemoZuulApplication.class, args);
}
}
6、编写application.yml
server:
port: 10010 #服务端口
spring:
application:
name: api-gateway #指定服务名
7、编写路由规则
zuul:
routes:
user-service:
path: /user-service/** # 这里是映射路径
url: http://127.0.0.1:8081 # 映射路径对应的实际url地址
我们将符合path 规则的一切请求,都代理到 url参数指定的地址
本例中,我们将 /user-service/**开头的请求,代理到http://127.0.0.1:8081
8、启动访问:http://127.0.0.1:10010/user-service/user/1
,测试成功
入门案例的路由规则中,我们把路径对应的服务地址写死了!如果同一服务有多个实例的话,这样做显然就不合理了。我们应该根据服务的名称,去Eureka注册中心查找 服务对应的所有实例列表,然后进行动态路由才对!
优化:
1、添加Eureka客户端依赖:
org.springframework.cloud
spring-cloud-starter-netflix-eureka-client
2、开启Eureka客户端发现功能
@SpringBootApplication
@EnableZuulProxy
@EnableDiscoveryClient
public class DemoZuulApplication {
public static void main(String[] args) {
SpringApplication.run(DemoZuulApplication.class, args);
}
}
3、添加Eureka配置,注册并获取服务信息
eureka:
client:
registry-fetch-interval-seconds: 5 # 获取服务列表的周期:5s
service-url:
defaultZone: http://127.0.0.1:10086/eureka
4、修改映射配置,通过服务名称获取
zuul:
routes:
user-service: # 这里是路由id,随意写
path: /user-service/** # 这里是映射路径
serviceId: user-service # 指定服务名称
5、再次启动,这次Zuul进行代理时,会利用Ribbon进行负载均衡访问:日志中可以看到使用了负载均衡器
在上面的配置中,我们的规则是这样的:
大多数情况下,我们的:路由名称,往往和服务名会写成一样的。因此Zuul就提供了一种简化的配置语法:zuul.routes.=
比方说上面我们关于user-service的配置可以简化为一条:省去了对服务名称的配置。
zuul:
routes:
user-service: /user-service/** # 这里是映射路径
在使用Zuul的过程中,上面讲述的规则已经大大的简化了配置项。但是当服务较多时,配置也是比较繁琐的。因此Zuul就指定了默认的路由规则:
我们通过zuul.prefix=/api来指定了路由的前缀,这样在发起请求时,路径就要以/api开头:
zuul:
prefix: /api # 添加路由前缀
Zuul作为网关的其中一个重要功能,就是实现请求的鉴权。而这个动作我们往往是通过Zuul提供的过滤器来实现的。
1、ZuulFilter
ZuulFilter是过滤器的顶级父类。在这里我们看一下其中定义的4个最重要的方法:
public abstract ZuulFilter implements IZuulFilter{
abstract public String filterType();
abstract public int filterOrder();
boolean shouldFilter();// 来自IZuulFilter
Object run() throws ZuulException;// IZuulFilter
}
异常流程:
自定义一个过滤器,模拟一个登录的校验。基本逻辑:如果请求中有access-token参数,则认为请求有效,放行。
@Component
public class LoginFilter extends ZuulFilter {
/**
* 过滤器类型,前置过滤器
* @return
*/
@Override
public String filterType() {
return "pre";
}
/**
* 过滤器的执行顺序
* @return
*/
@Override
public int filterOrder() {
return 1;
}
/**
* 该过滤器是否生效
* @return
*/
@Override
public boolean shouldFilter() {
return true;
}
/**
* 登陆校验逻辑
* @return
* @throws ZuulException
*/
@Override
public Object run() throws ZuulException {
// 获取zuul提供的上下文对象
RequestContext context = RequestContext.getCurrentContext();
// 从上下文对象中获取请求对象
HttpServletRequest request = context.getRequest();
// 获取token信息
String token = request.getParameter("access-token");
// 判断
if (StringUtils.isBlank(token)) {
// 过滤该请求,不对其进行路由
context.setSendZuulResponse(false);
// 设置响应状态码,401
context.setResponseStatusCode(HttpStatus.SC_UNAUTHORIZED);
// 设置响应信息
context.setResponseBody("{\"status\":\"401\", \"text\":\"request error!\"}");
}
// 校验通过,把登陆信息放入上下文信息,继续向后执行
context.set("token", token);
return null;
}
}
Zuul中默认就已经集成了Ribbon负载均衡和Hystix熔断机制。但是所有的超时策略都是走的默认值,比如熔断超时时间只有1S,很容易就触发了。因此建议我们手动进行配置:
hystrix:
command:
execution:
isolation:
thread:
timeoutInMillisecond: 6000 # 熔断超时时长:6000ms