为何须要API Gateway
一、简化客户端调用复杂度前端
在微服务架构模式下后端服务的实例数通常是动态的,对于客户端而言很难发现动态改变的服务实例的访问地址信息。所以在基于微服务的项目中为了简化前端的调用逻辑,一般会引入API Gateway做为轻量级网关,同时API Gateway中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度。java
二、数据裁剪以及聚合spring
一般而言不一样的客户端对于显示时对于数据的需求是不一致的,好比手机端或者Web端又或者在低延迟的网络环境或者高延迟的网络环境。后端
所以为了优化客户端的使用体验,API Gateway能够对通用性的响应数据进行裁剪以适应不一样客户端的使用需求。同时还能够将多个API调用逻辑进行聚合,从而减小客户端的请求数,优化客户端用户体验api
三、多渠道支持安全
固然咱们还能够针对不一样的渠道和客户端提供不一样的API Gateway,对于该模式的使用由另一个你们熟知的方式叫Backend for front-end, 在Backend for front-end模式当中,咱们能够针对不一样的客户端分别建立其BFF。网络
四、遗留系统的微服务化改造架构
对于系统而言进行微服务改造一般是因为原有的系统存在或多或少的问题,好比技术债务,代码质量,可维护性,可扩展性等等。API Gateway的模式一样适用于这一类遗留系统的改造,经过微服务化的改造逐步实现对原有系统中的问题的修复,从而提高对于原有业务响应力的提高。经过引入抽象层,逐步使用新的实现替换旧的实现。app
在Spring Cloud体系中, Spring Cloud Zuul就是提供负载均衡、反向代理、权限认证的一个API gateway。负载均衡
Spring Cloud Zuul
Spring Cloud Zuul路由是微服务架构的不可或缺的一部分,提供动态路由,监控,弹性,安全等的边缘服务。Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。
下面咱们经过代码来了解Zuul是如何工做的
简单使用
一、添加依赖
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zuul</artifactId> </dependency>
引入spring-cloud-starter-zuul
包
二、配置文件
spring.application.name=gateway-service-zuul server.port=8888 #这里的配置表示,访问/it/** 直接重定向到http://www.ityouknow.com/** zuul.routes.baidu.path=/it/** zuul.routes.baidu.url=http://www.ityouknow.com/
三、启动类
@SpringBootApplication @EnableZuulProxy public class GatewayServiceZuulApplication { public static void main(String[] args) { SpringApplication.run(GatewayServiceZuulApplication.class, args); } }
启动类添加@EnableZuulProxy,支持网关路由。
史上最简单的zuul案例就配置完了
服务化
经过url映射的方式来实现zull的转发有局限性,好比每增长一个服务就须要配置一条内容,另外后端的服务若是是动态来提供,就不能采用这种方案来配置了。实际上在实现微服务架构时,服务名与服务实例地址的关系在eureka server中已经存在了,因此只须要将Zuul注册到eureka server上去发现其余服务,就能够实现对serviceId的映射。
咱们结合示例来讲明,在上面示例项目gateway-service-zuul-simple的基础上来改造。
一、添加依赖
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-eureka</artifactId> </dependency>
增长spring-cloud-starter-eureka
包,添加对eureka的支持。
二、配置文件
配置修改成:
spring.application.name=gateway-service-zuul server.port=8888 zuul.routes.api-a.path=/producer/** zuul.routes.api-a.serviceId=spring-cloud-producer eureka.client.serviceUrl.defaultZone=http://localhost:8000/eureka/
三、测试
依次启动 spring-cloud-eureka、 spring-cloud-producer、gateway-service-zuul-eureka,访问:http://localhost:8888/producer/hello?name=%E5%B0%8F%E6%98%8E,返回:hello 小明,this is first messge
说明访问gateway-service-zuul-eureka的请求自动转发到了spring-cloud-producer,而且将结果返回。
为了更好的模拟服务集群,咱们复制spring-cloud-producer项目改成spring-cloud-producer-2,修改spring-cloud-producer-2项目端口为9001,controller代码修改以下:
@RestController public class HelloController { @RequestMapping("/hello") public String index(@RequestParam String name) { return "hello "+name+",this is two messge"; } }
修改完成后启动spring-cloud-producer-2
,重启gateway-service-zuul-eureka
。测试屡次访问http://localhost:8888/producer/hello?name=%E5%B0%8F%E6%98%8E
,依次返回:
hello 小明,this is first messge hello 小明,this is two messge hello 小明,this is first messge hello 小明,this is two messge ...
说明经过zuul成功调用了producer服务而且作了均衡负载。
网关的默认路由规则
可是若是后端服务多达十几个的时候,每个都这样配置也挺麻烦的,spring cloud zuul已经帮咱们作了默认配置。默认状况下,Zuul会代理全部注册到Eureka Server的微服务,而且Zuul的路由规则以下:http://ZUUL_HOST:ZUUL_PORT/微服务在Eureka上的serviceId/**会被转发到serviceId对应的微服务。
咱们注销掉gateway-service-zuul-eureka项目中关于路由的配置:
#zuul.routes.api-a.path=/producer/** #zuul.routes.api-a.serviceId=spring-cloud-producer
从新启动后,访问http://localhost:8888/spring-cloud-producer/hello?name=%E5%B0%8F%E6%98%8E,测试返回结果和上述示例相同,说明Spring cloud zuul默认已经提供了转发功能。
到此zuul的基本使用咱们就介绍完了。关于zuul更高级使用,咱们下篇再来介绍。
总体架构以下:
愿意了解框架技术或者源码的朋友直接求求交流分享技术:贰一四七七七五六叁叁