跟我学SpringCloud | 第九篇:服务网关Zuul初

SpringCloud系列教程 | 第九篇:服务网关Zuul初探

前面的文章我们介绍了,Eureka用于服务的注册于发现,Feign支持服务的调用以及均衡负载,Hystrix处理服务的熔断防止故障扩散,Spring Cloud Config服务集群配置中心,似乎一个微服务框架已经完成了。

我们还是少考虑了一个问题,外部的应用如何来访问内部各种各样的微服务呢?在微服务架构中,后端服务往往不直接开放给调用端,而是通过一个API网关根据请求的url,路由到相应的服务。当添加API网关后,在第三方调用端和服务提供方之间就创建了一面墙,这面墙直接与调用方通信进行权限控制,后将请求均衡分发给后台服务端。

一个简单的微服务架构已经跃然纸面:

在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

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默认已经提供了转发功能。

到此zuul的基本使用我们就聊完了。关于zuul高级使用,我们下篇再来介绍。

示例代码-Github

参考:

http://www.ityouknow.com/springcloud/2017/06/01/gateway-service-zuul.html
https://www.fangzhipeng.com/springcloud/2018/08/05/sc-f5-zuul.html

原文地址:https://www.cnblogs.com/babycomeon/p/11142923.html

时间: 2024-08-03 17:00:31

跟我学SpringCloud | 第九篇:服务网关Zuul初的相关文章

springcloud(十):服务网关zuul初级篇

为什么需要API Gateway1.简化客户端调用复杂度 在微服务架构模式下后端服务的实例数一般是动态的,对于客户端而言很难发现动态改变的服务实例的访问地址信息.因此在基于微服务的项目中为了简化前端的调用逻辑,通常会引入API Gateway作为轻量级网关,同时API Gateway中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度. 2.数据裁剪以及聚合 通常而言不同的客户端对于显示时对于数据的需求是不一致的,比如手机端或者Web端又或者在低延迟的网络环境或者高延迟的网络环境. 因此

SpringCloud系列研究---服务网关zuul

一.zuul简介 服务网关是微服务架构中的入口,微服务平台通过服务网关统一向外部暴露API供客户端调用,网关除了具备服务路由.均衡负载功能之外,它还具备了权限控制等功能.在Spring Cloud中的Zuul就担任了这样的一个角色,为微服务架构提供了保护的作用,同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面,使得服务集群主体能够具备更高的可复用性和可测试性. 二.环境介绍 同上一篇介绍ribbo中的环境一样,首先我们在A服务器上启动Eureka服务,然后在B.C两台服务器上分别启动ms

跟我学SpringCloud | 终篇:文章汇总(持续更新)

SpringCloud系列教程 | 终篇:文章汇总(持续更新) 我为什么这些文章?一是巩固自己的知识,二是希望有更加开放和与人分享的心态,三是接受各位大神的批评指教,有任何问题可以联系我: [email protected]. Github源码下载:https://github.com/meteor1993/SpringCloudLearning <跟我学SpringCloud>系列: Greenwich版 Spring Cloud Greenwich.SR1; Spring Boot 2.1

Spring Cloud(十一):服务网关 Zuul(过滤器)【Finchley 版】

Spring Cloud(十一):服务网关 Zuul(过滤器)[Finchley 版] 发表于 2018-04-23 |  更新于 2018-05-07 | 在上篇文章中我们了解了 Spring Cloud Zuul 作为网关所具备的最基本功能:路由(Router).本文我们将关注 Spring Cloud Zuul 的另一核心功能:过滤器(Filter). Filter 的作用 我们已经能够实现请求的路由功能,所以我们的微服务应用提供的接口就可以通过统一的 API 网关入口被客户端访问到了.但

SpringCloud分布式微服务云架构 第五篇: 路由网关(zuul)(Finchley版本)

SpringCloud分布式微服务云架构 第五篇: 路由网关(zuul)(Finchley版本)在微服务架构中,需要几个基础的服务治理组件,包括服务注册与发现.服务消费.负载均衡.断路器.智能路由.配置管理等,了解springcloud架构可以加求求:三五三六二四七二五九,由这几个基础组件相互协作,共同组建了一个简单的微服务系统.一个简答的微服务系统如下图: 注意:A服务和B服务是可以相互调用的,并且配置服务也是注册到服务注册中心的. 在Spring Cloud微服务系统中,一种常见的负载均衡方

[老老实实学WCF] 第九篇 消息通信模式(上) 请求应答与单向

老老实实学WCF 第九篇 消息通信模式(上) 请求应答与单向 通过前两篇的学习,我们了解了服务模型的一些特性如会话和实例化,今天我们来进一步学习服务模型的另一个重要特性:消息通信模式. WCF的服务端与客户端在通信时有三种模式:单向模式.请求/应答模式和双工模式. 如果选用了单向模式,调用方在向被调用方进行了调用后不期待任何回应,被调用方在执行完调用后不给调用方任何反馈.如客户端通过单向模式调用了一个服务端的操作后,就去干别的了,不会等待服务端给他任何响应,他也无从得知调用是否成功,甚至连发生了

服务网关zuul之七:zuul中的动态刷新路由配置

Spring cloud使用/refresh端点手动刷新配置 一 介绍很多场景下,需要在运行期间动态调整配置.如果配置发生了修改,微服务也应该实现配置的刷新.下面实现配置的手动刷新.二 新建项目microservice-config-client-refresh三 为项目添加spring-boot-starter-actuator依赖,该依赖包含了/refresh端点,用于配置的刷新. <dependencies> <dependency> <groupId>org.s

微服务SpringCloud之服务网关zuul一

前面学习了Eureka.Feign.Hystrix.Config,本篇来学习下API网关zuul.在微服务架构中,后端服务往往不直接开放给调用端,而是通过一个API网关根据请求的url,路由到相应的服务.当添加API网关后,在第三方调用端和服务提供方之间就创建了一面墙,这面墙直接与调用方通信进行权限控制,后将请求均衡分发给后台服务端. 为什么需要API Gateway 1.简化客户端调用复杂度 在微服务架构模式下后端服务的实例数一般是动态的,对于客户端而言很难发现动态改变的服务实例的访问地址信息

Flask最强攻略 - 跟DragonFire学Flask - 第九篇 Flask 中的蓝图(BluePrint)

蓝图,听起来就是一个很宏伟的东西 在Flask中的蓝图 blueprint 也是非常宏伟的 它的作用就是将 功能 与 主服务 分开怎么理解呢? 比如说,你有一个客户管理系统,最开始的时候,只有一个查看客户列表的功能,后来你又加入了一个添加客户的功能(add_user)模块, 然后又加入了一个删除客户的功能(del_user)模块,然后又加入了一个修改客户的功能(up_user)模块,在这个系统中,就可以将 查看客户,修改客户,添加客户,删除客户的四个功能做成蓝图加入到客户管理系统中,本篇最后会做