在微服务架构中,后端服务往往不间接凋谢给调用端,而是通过一个API网关依据申请的url,路由到相应的服务。当增加API网关后,在第三方调用端和服务提供方之间就创立了一面墙,这面墙间接与调用方通信进行权限管制,后将申请平衡分发给后盾服务端。
一个简略的微服务架构曾经跃然纸面:(理解源码可+求求: 1791743380)
在Spring Cloud微服务零碎中,一种常见的负载平衡形式是,客户端的申请首先通过负载平衡(zuul、Ngnix、F5),再达到服务网关(zuul集群),而后再到具体的服务,服务对立注册到高可用的服务注册核心集群,服务的所有的配置文件由配置服务治理,配置服务的配置文件放在git仓库,不便开发人员随时改配置。
1. 为什么须要API Gateway?
1.1 简化客户端调用复杂度
在微服务架构模式下后端服务的实例数个别是动静的,对于客户端而言很难发现动静扭转的服务实例的拜访地址信息。因而在基于微服务的我的项目中为了简化前端的调用逻辑,通常会引入API Gateway作为轻量级网关,同时API Gateway中也会实现相干的认证逻辑从而简化外部服务之间互相调用的复杂度。
### 1.2 数据裁剪以及聚合
通常而言不同的客户端对于显示时对于数据的需要是不统一的,比方手机端或者Web端又或者在低提早的网络环境或者高提早的网络环境。
因而为了优化客户端的应用体验,API Gateway能够对通用性的响应数据进行裁剪以适应不同客户端的应用需要。同时还能够将多个API调用逻辑进行聚合,从而缩小客户端的申请数,优化客户端用户体验
1.3 多渠道反对
当然咱们还能够针对不同的渠道和客户端提供不同的API Gateway,对于该模式的应用由另外一个大家熟知的形式叫Backend for front-end, 在Backend for front-end模式当中,咱们能够针对不同的客户端别离创立其BFF,进一步理解BFF能够参考这篇文章:Pattern: Backends For Frontends
[
](https://springcloud-oss.oss-c...
1.4 遗留零碎的微服务化革新
对于零碎而言进行微服务革新通常是因为原有的零碎存在或多或少的问题,比方技术债权,代码品质,可维护性,可扩展性等等。API Gateway的模式同样实用于这一类遗留零碎的革新,通过微服务化的革新逐渐实现对原有零碎中的问题的修复,从而晋升对于原有业务响应力的晋升。通过引入形象层,逐渐应用新的实现替换旧的实现。
在Spring Cloud体系中, Spring Cloud Zuul就是提供负载平衡、反向代理、权限认证的一个API gateway。在开始聊Zuul如何应用之前,先讲一个比拟有意思的事件,就是在springcloud组件中,服务网关这个组件,springcloud提供了两种抉择,一个是netflix公司开源的Zuul,还有一个是springcloud本人开源的Spring Cloud Gateway,具体这两个组件的恩怨情仇,在前面的Spring Cloud Gateway的文章中咱们再细聊:)
2. Spring Cloud Zuul
2.1 简略应用
Spring Cloud Zuul路由是微服务架构的不可或缺的一部分,提供动静路由,监控,弹性,平安等的边缘服务。Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。
上面咱们来看一下Zuul最简略的应用形式,创立zuul-simple工程
2.1 pom.xml
<?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"\> <modelVersion\>4.0.0</modelVersion\> <parent\> <groupId\>org.springframework.boot</groupId\> <artifactId\>spring-boot-starter-parent</artifactId\> <version\>2.1.6.RELEASE</version\> <relativePath/> <!-- lookup parent from repository --> </parent\> <groupId\>com.springcloud</groupId\> <artifactId\>zuul-simple</artifactId\> <version\>0.0.1-SNAPSHOT</version\> <name\>zuul-simple</name\> <description\>Demo project for Spring Boot</description\> <properties\> <java.version\>1.8</java.version\> <spring-cloud.version\>Greenwich.SR1</spring-cloud.version\> </properties\> <dependencies\> <dependency\> <groupId\>org.springframework.cloud</groupId\> <artifactId\>spring-cloud-starter-netflix-zuul</artifactId\> </dependency\> <dependency\> <groupId\>org.springframework.boot</groupId\> <artifactId\>spring-boot-starter-test</artifactId\> <scope\>test</scope\> </dependency\> </dependencies\> <dependencyManagement\> <dependencies\> <dependency\> <groupId\>org.springframework.cloud</groupId\> <artifactId\>spring-cloud-dependencies</artifactId\> <version\>${spring-cloud.version}</version\> <type\>pom</type\> <scope\>import</scope\> </dependency\> </dependencies\> </dependencyManagement\> <build\> <plugins\> <plugin\> <groupId\>org.springframework.boot</groupId\> <artifactId\>spring-boot-maven-plugin</artifactId\> </plugin\> </plugins\> </build\> </project\>
引入spring-cloud-starter-netflix-zuul包
2.2 配置文件application.yml
server: port: 8080 spring: application: name: spring-cloud-zuul zuul: routes: baidu: path: /baidu/\*\* url: https://www.baidu.com/
这里的配置示意,拜访/baidu/ 间接重定向到https://www.baidu.com/
如果间接拜访http://localhost:8080/baidu,则会间接跳转到https://www.baidu.com/。
2.3 启动类
package com.springcloud.zuulsimple; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.netflix.zuul.EnableZuulProxy; @SpringBootApplication @EnableZuulProxy public class ZuulSimpleApplication { public static void main(String\[\] args) { SpringApplication.run(ZuulSimpleApplication.class, args); } }
启动类增加@EnableZuulProxy,反对网关路由。
史上最简略的zuul案例就配置完了
2.4 测试
启动我的项目,在浏览器拜访http://localhost:8080/baidu/,咱们能够看到页面曾经跳转到百度首页。
再尝试拜访http://localhost:8080/baidu/aa,咱们能够看到页面跳转至:https://www.baidu.com/search/error.html, 因为https://www.baidu.com/aa 这个链接不存在, 所以百度帮咱们跳转到的error页面。
至此,Zuul简略应用曾经介绍结束,上面咱们来聊一下服务化的形式。
2.2 服务化
通过url映射的形式来实现Zuul的转发有局限性,比方每减少一个服务就须要配置一条内容,另外后端的服务如果是动静来提供,就不能采纳这种计划来配置了。实际上在实现微服务架构时,服务名与服务实例地址的关系在eureka server中曾经存在了,所以只须要将Zuul注册到eureka server下来发现其余服务,就能够实现对serviceId的映射。
咱们联合示例来阐明,在下面示例我的项目根底上来进行革新
2.2.1 增加依赖
<dependency\> <groupId\>org.springframework.cloud</groupId\> <artifactId\>spring-cloud-starter-netflix-eureka-client</artifactId\> </dependency\>
减少spring-cloud-starter-netflix-eureka-client包,增加对eureka的反对。
2.2.2 配置文件application.yml
server: port: 8080 spring: application: name: spring-cloud-zuul zuul: routes: api-producer: path: /producer/\*\* serviceId: spring-cloud-producer eureka: client: service-url: defaultZone: http://localhost:8761/eureka/
在这里咱们减少了对服务的反对,这里的Zuul配置的含意为拜访/producer/**,转向到eureka下面serviceId为spring-cloud-producer的服务。
2.2.3 测试
先从上一篇的我的项目中copy Eureka到本篇的文件夹中,再从第五篇的我的项目中copy一个producer到本篇的文件夹中。
顺次启动eureka,producer和Zuul.
咱们关上浏览器拜访:http://localhost:8080/producer/hello?name=spring, 能够看到页面失常显示producer的响应:hello spring,producer is ready。阐明通过zuul胜利调用了producer服务。
这里producer能够启动两个服务,屡次刷新http://localhost:8080/producer/hello?name=spring, 能够看到Zuul对服务的调用是负载平衡的。
2.3 网关的默认路由
然而如果后端服务多达十几个的时候,每一个都这样配置也挺麻烦的,spring cloud zuul曾经帮咱们做了默认配置。默认状况下,Zuul会代理所有注册到Eureka Server的微服务,并且Zuul的路由规定如下:http://ZUUL_HOST:ZUUL_PORT/微服务在Eureka上的serviceId/**会被转发到serviceId对应的微服务。
咱们登记掉zuul-simple配置文件中无关路由的配置。
#zuul: \# routes: \# api-producer: \# path: /producer/\*\* \# serviceId: spring-cloud-producer
再次启动Zuul。
咱们在浏览器中拜访http://localhost:8080/spring-cloud-producer/hello?name=spring,能够看到和下面一样的返回后果,阐明Spring cloud zuul默认曾经提供了转发性能。