前言
在前面的文章我们讲解了,Eureka
服务注册与发现,Ribbon
负载均衡,Feign
的声明式服务调用,用户服务保护的Hystrix
,配置中心SpringCloudConfig
,似乎一个完整的微服务架构已经搭建完成了。
不知道大家是否还记得刚开始介绍SpringCloud的时候有一张微服务架构图:
仔细的同学可能会发现,我们还缺少一个东西,就是API Gateway
,也就是服务网关。
在微服务架构中,后端服务往往不直接开放给调用端,而是通过一个API网关根据请求的url,路由到相应的服务。当添加API网关后,在第三方调用端和服务提供方之间就创建了一面墙,这面墙直接与调用方通信进行权限控制后再将请求均衡分发给后台服务端。
API Gateway的作用
1、简化客户端调用复杂度
在微服务架构模式下后端服务的实例数一般是动态的,对于客户端而言很难发现动态改变的服务实例的访问地址信息。因此在基于微服务的项目中为了简化前端的调用逻辑,通常会引入API Gateway
作为轻量级网关,同时API Gateway
中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度。
2、数据裁剪以及聚合
通常而言不同的客户端对于显示时对于数据的需求是不一致的,比如手机端或者Web端又或者在低延迟的网络环境或者高延迟的网络环境。
因此为了优化客户端的使用体验,API Gateway
可以对通用性的响应数据进行裁剪以适应不同客户端的使用需求。同时还可以将多个API调用逻辑进行聚合,从而减少客户端的请求数,优化客户端用户体验
3、多渠道支持
当然我们还可以针对不同的渠道和客户端提供不同的API Gateway
,对于该模式的使用由另外一个大家熟知的方式叫Backend for front-end
, 在Backend for front-end
模式当中,我们可以针对不同的客户端分别创建其BFF
,进一步了解BFF可以参考这篇文章:Pattern: Backends For Frontends
4、遗留系统的微服务化改造
对于系统而言进行微服务改造通常是由于原有的系统存在或多或少的问题,比如技术债务,代码质量,可维护性,可扩展性等等。API Gateway
的模式同样适用于这一类遗留系统的改造,通过微服务化的改造逐步实现对原有系统中的问题的修复,从而提升对于原有业务响应力的提升。通过引入抽象层,逐步使用新的实现替换旧的实现。
此段引用:纯洁的微笑-服务网关zuul初级篇
SpringCloud Zuul
Spring Cloud Zuul就是提供负代理、路由、过滤的一个API gateway。
Zuul包含了对请求的路由和过滤两个最主要的功能:
其中路由功能负责将外部请求转发到具体的微服务实例上,是实现外部访问统一入口的基础而过滤器功能则负责对请求的处理过程进行干预,是实现请求校验、服务聚合等功能的础。
Zuul
和Eureka
进行整合,将Zuul
自身注册为Eureka
服务治理下的应用,同时从Eureka
中获得其他微服务的消息,也即以后的访问微服务都是通过Zuul
进行路由。
集成Zuul
新建项目spring-cloud-zuul
:
修改pom文件,引入zuul
依赖:
<!--zuul-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zuul</artifactId>
</dependency>
完整pom:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<parent>
<artifactId>spring-cloud-examples</artifactId>
<groupId>com.chaytech</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>spring-cloud-zuul</artifactId>
<packaging>jar</packaging>
<dependencies>
<!--zuul-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zuul</artifactId>
</dependency>
</dependencies>
</project>
新增配置application.yml
:
server:
port: 9527
spring:
application:
name: spring-cloud-zuul
#配置路由规则:这里的配置表示,访问/baidu/** 直接重定向到http://www.baidu.com/**
zuul:
routes:
baidu.path: /baidu/**
baidu.url: http://www.baidu.com/
启动类增加@EnableZuulProxy
注解,开启zuul
代理:
@SpringBootApplication
@EnableZuulProxy
public class SpringCloudZuul9527_Application {
public static void main(String[] args) {
SpringApplication.run(SpringCloudZuul9527_Application.class,args);
}
}
启动服务测试,访问:http://127.0.0.1:9527/baidu,会重定向到https://www.baidu.com/
上面简单的演示了zuul
的路由跳转,下面我们将zuul
注册到eureka
中,进行服务转发。
注册到Eureka
引入eureka依赖:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>
修改application.yml
,增加eureka
配置:
eureka:
client: #客户端注册进eureka服务列表内
service-url:
#defaultZone: http://localhost:7001/eureka (单机)
defaultZone: http://eureka7001:7001/eureka/,http://eureka7002:7002/eureka/,http://eureka7003:7003/eureka/ #(集群)
instance:
instance-id: spring-cloud-config-zuul9527 # 自定义服务名称信息
prefer-ip-address: true # 访问路径可以现实IP
依次启动eureka
集群、用户微服务、服务网关服务:
可以看到服务网关已经注册到了eureka
。
不通过路由访问:http://127.0.0.1:8080/consumer/user/listUser
通过路由访问:http://127.0.0.1:9527/user-provider/user/listUser
上面我们是使用的Spring Cloud zuul
的默认路由配置。默认情况下,Zuul
会代理所有注册到Eureka Server
的微服务,路由规则如下:http://ZUUL_HOST:ZUUL_PORT/微服务在Eureka上的serviceId/**会被转发到serviceId对应的微服务。
正常情况下,服务的名称是不会让暴露给用户的,一般会配置代理名称,下面我们来配置代理名称,使用代理名称来进行服务调用:
zuul:
routes:
myUser.serviceId: user-provider
myUser.path: /myUser/**
重启zuul
服务,访问:http://127.0.0.1:9527/myUser/user/listUser
OK,到此zuul
的基本使用我们就介绍完了,后面将会zuul
的高级部分。