第二代微服务网关组件 - Spring Cloud Gateway

[TOC]

初识Spring Cloud Gateway

简介：

Spring Cloud Gateway是Spring Cloud体系的第二代网关组件，基于Spring 5.0的新特性WebFlux进行开发，底层网络通信框架使用的是Netty，所以其吞吐量高、性能强劲，未来将会取代第一代的网关组件Zuul。Spring Cloud Gateway可以通过服务发现组件自动转发请求，默认集成了Ribbon做负载均衡，以及默认使用Hystrix对网关进行保护，当然也可以选择其他的容错组件，例如Sentinel

优点：

  • 性能强劲：是第一代网关Zuul的1.6倍
  • 功能强大：内置了很多实用的功能，例如转发、监控、限流等
  • 设计优雅，容易扩展

缺点：

  • 其实现依赖Netty与WebFlux，不是传统的Servlet编程模型，有一定的学习成本
  • 不能在Servlet容器下工作，也不能构建成WAR包，即不能将其部署在Tomcat、Jetty等Servlet容器里，只能打成jar包执行
  • 不支持Spring Boot 1.x，需2.0及更高的版本

如果对网关概念或Zuul不了解的话，可以参考另一篇文章：

核心概念：

1、Route（路由）：

Spring Cloud Gateway的基础元素，可简单理解成一条转发规则。包含：ID、目标URL、Predicate集合以及Filter集合

这是一段比较典型的Gateway路由配置：

spring:
  cloud:
    gateway:
      routes:
      - id: user-center  # 唯一标识，通常使用服务id
        uri: lb://user-center  # 目标URL，lb代表从注册中心获取服务，lb是Load Balance的缩写
        predicates:
        # Predicate集合
        - Path=/zj/cloud/v1/user-center/**  # 匹配转发路径
        filters:
        # Filter集合
        - StripPrefix=4  # 从第几级开始转发

2、Predicate（谓词）：

即java.util.function.Predicate这个接口，Gateway使用Predicate实现路由的匹配条件

3、Filter（过滤器）：

与我们平时使用的Servlet编程模型里的过滤器概念类似，同样可以用于修改请求以及响应数据，可以利用Filter实现鉴权、访问日志记录，接口耗时记录等功能

Spring Cloud Gateway架构图：

简单解读一下这个图：

Gateway Client发送请求给Spring Cloud Gateway，Gateway Handler Mapping会判断请求的路径是否匹配路由的配置，如果匹配则会进入Gateway Web Handler，Web Handler会读取路由上所配置的过滤器，然后将该请求交给过滤器去处理，最后转发到路由配置的微服务上

  • Gateway Client：泛指外部请求，例如浏览器、app、小程序等
  • Proxied Service：指的是被网关代理的微服务

相关源码：

  • Gateway Handler Mapping：org.springframework.cloud.gateway.handler.RoutePredicateHandlerMapping
  • Gateway Web Handler：org.springframework.cloud.gateway.handler.FilteringWebHandler

由于Webflux大量运用函数式编程思想，所以本文中的示例代码都会使用lambda表达式及函数式API来简化。若对此不了解的话，可以参考相关文章，篇幅有限这里就不进行介绍了：

创建Spring Cloud Gateway项目

这里使用IDEA的Spring Initializr进行项目的创建，到选择依赖这一步勾选gateway依赖，如下图：

网关组件一般都配合服务发现组件使用，我这里使用Nacos作为服务发现组件，具体的依赖如下：

<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-gateway</artifactId>
    </dependency>
    <!-- Nacos Client -->
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    </dependency>
    <!-- actuator -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
    </dependency>
</dependencies>

<dependencyManagement>
    <dependencies>
        <!--整合Spring Cloud-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>Greenwich.SR2</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        <!--整合Spring Cloud Alibaba-->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-alibaba-dependencies</artifactId>
            <version>2.1.0.RELEASE</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

如果对Nacos不熟悉的话可以参考另一篇关于Nacos的文章，或者采用Eureka也是一样的：

然后编写配置文件内容如下：

server:
  port: 8040
spring:
  application:
    name: gateway
  cloud:
    nacos:
      discovery:
        # 指定nacos server的地址
        server-addr: 127.0.0.1:8848
    gateway:
      discovery:
        locator:
          # 让gateway通过服务发现组件找到其他的微服务，从而自动转发请求
          enabled: true

# actuator相关配置
management:
  endpoints:
    web:
      exposure:
        # 暴露所有监控端点
        include: ‘*‘
  endpoint:
    health:
      # 总是显示健康检测详情
      show-details: always

完成以上步骤后，我们来启动这个网关服务，进行一个简单的测试，看看是否能将请求正常地转发到指定的微服务上。此时有一个名为user-center的微服务，该微服务有一个按id获取用户信息的接口，接口路径为/users/{id}。若通过网关服务来访问这个接口，要如何做呢？很简单，gateway配合服务发现组件使用时，会有一个默认的转发规则，如下：

  • ${GATEWAY_URL}/{微服务名称}/{接口路径}

所以按该规则得出来的具体url为：localhost:8040/user-center/users/{id}，访问结果如下：

从测试结果可以看到，gateway可以根据url上的微服务名称将访问请求转发到该微服务上。

以上这种是Gateway最简单的使用方式，但通常在实际开发中，可能不希望使用默认的转发规则，因为这种方式不太灵活，例如一些服务接口是存在版本划分的，需要根据不同版本的访问路径转发到不同版本的微服务上。此时就需要自定义转发路由，实际上在第一小节的时候就已经给出过配置示例了。修改配置如下：

spring:
  cloud:
    gateway:
      routes:
      - id: user-center  # 唯一标识，通常使用服务id
        uri: lb://user-center  # 目标URL，lb代表从注册中心获取服务
        predicates:
        # Predicate集合
        - Path=/zj/cloud/v1/user-center/**  # 匹配转发路径
        filters:
        # Filter集合
        - StripPrefix=4  # 从第几级开始转发，数字从0开始

自定义路由的注意事项：

  • predicates配置项必须有，且必须配置一个及以上的Predicate，但不一定非要配置Path，可以配置其他的Predicate，例如After、Before等，此时Path的默认值为/**

重启项目，此时访问的url为：localhost:8040/zj/cloud/v1/user-center/users/{id}，访问结果如下：

路由配置的两种形式

Spring Cloud Gateway的路由配置有两种形式，分别是路由到指定的URL以及路由到指定的微服务，在上一小节的示例中我们就已经使用过路由到微服务的这种配置形式了。在这两种形式中，均支持访问路径的通配及精确匹配，在之前的示例中我们只使用了通配。所以本小节将给出具体的配置示例，以此直观的了解这两种形式及不同匹配方式在配置上的区别。

1、路由到指定的URL

通配，使用通配符/**进行匹配，示例：

spring:
  cloud:
    gateway:
      routes:
        - id: test_route  # 路由的唯一标识
          uri: http://www.xxx.com
          predicates:
            # 使用通配符匹配
            - Path=/**
  • 该配置使访问 GATEWAY_URL/** 时会转发到 http://www.xxx.com/**

精确匹配，配置具体的接口路径即可，示例：

spring:
  cloud:
    gateway:
      routes:
        - id: test_route  # 路由的唯一标识
          uri: http://www.xxx.com/user/order/detail
          predicates:
            # 指定具体的路径进行匹配
            - Path=/user/order/detail
  • 该配置使访问 GATEWAY_URL/user/order/detail 时会转发到 http://www.xxx.com/user/order/detail

2、路由到指定的微服务

通配，示例：

spring:
  cloud:
    gateway:
      routes:
        - id: user-center  # 路由的唯一标识，这种形式下通常是微服务名称
          uri: lb://user-center  # lb代表从注册中心获取服务
          predicates:
            # 使用通配符匹配
            - Path=/**
  • 该配置使访问 GATEWAY_URL/** 时会转发到 user-center微服务的/**

精确匹配，示例：

spring:
  cloud:
    gateway:
      routes:
        - id: user-center  # 路由的唯一标识，这种形式下通常是微服务名称
          uri: lb://user-center/users/info  # lb代表从注册中心获取服务
          predicates:
            # 指定具体的路径进行匹配
            - Path=/users/info
  • 该配置使访问 GATEWAY_URL/users/info 时会转发到 user-center微服务的/users/info

路由谓词工厂

前面提到过谓词是路由的判断条件，而路由谓词工厂就是作用到指定路由上的一堆谓词判断条件。在之前的示例里，我们就已经使用过路由谓词工厂了，就是自定义转发路径时所配置的Path。

内置的路由谓词工厂

Spring Cloud Gateway内置了众多路由谓词工厂，这些路由谓词工厂为路由匹配的判断提供了有力的支持，而我们之前所使用的Path就是内置的路由谓词工厂之一，用于判断当前访问的接口路径是否与该路由所配置的路径相匹配，若匹配则进行转发。由于Gateway内置的路由谓词工厂比较多，篇幅有限就不在本文中介绍了，可以参考另一篇文章：

自定义路由谓词工厂

现在我们已经知道Spring Cloud Gateway内置了一系列的路由谓词工厂，但如果这些内置的路由谓词工厂不能满足业务需求的话，我们可以自定义路由谓词工厂来实现特定的需求。例如有某个服务限制用户只允许在09:00 - 17:00这个时间段内才可以访问，内置的路由谓词工厂是无法满足这个需求的，所以此时我们就需要自定义能够实现该需求的路由谓词工厂。

首先定义一个配置类，用于承载时间段的配置参数：

@Data
public class TimeBetweenConfig {
    /**
     * 开始时间
     */
    private LocalTime start;

    /**
     * 结束时间
     */
    private LocalTime end;
}

然后定义一个路由谓词工厂，具体代码如下：

package com.zj.node.gateway.predicate;

import com.zj.node.gateway.config.TimeBetweenConfig;
import lombok.extern.slf4j.Slf4j;
import org.springframework.cloud.gateway.handler.predicate.AbstractRoutePredicateFactory;
import org.springframework.stereotype.Component;
import org.springframework.web.server.ServerWebExchange;

import java.time.LocalTime;
import java.util.Arrays;
import java.util.List;
import java.util.function.Predicate;

/**
 * 路由谓词工厂必须以RoutePredicateFactory结尾，
 * 这是Spring Cloud Gateway的约定
 *
 * @author 01
 * @date 2019-08-14
 **/
@Slf4j
@Component
public class TimeBetweenRoutePredicateFactory extends AbstractRoutePredicateFactory<TimeBetweenConfig> {

    public TimeBetweenRoutePredicateFactory() {
        super(TimeBetweenConfig.class);
    }

    /**
     * 实现谓词判断的方法
     */
    @Override
    public Predicate<ServerWebExchange> apply(TimeBetweenConfig config) {
        return exchange -> {
            LocalTime start = config.getStart();
            LocalTime end = config.getEnd();

            // 判断当前时间是否为允许访问的时间段内
            LocalTime now = LocalTime.now();
            return now.isAfter(start) && now.isBefore(end);
        };
    }

    /**
     * 控制配置类（TimeBetweenConfig）属性和配置文件中配置项（TimeBetween）的映射关系
     */
    @Override
    public List<String> shortcutFieldOrder() {
        /*
         * 例如我们的配置项是：TimeBetween=上午9:00, 下午5:00
         * 那么按照顺序，start对应的是上午9:00；end对应的是下午5:00
         **/
        return Arrays.asList("start", "end");
    }
}

最后需要在配置文件中启用该路由谓词工厂，并且需要禁止gateway通过服务发现组件转发请求到其他的微服务，修改Gateway相关配置如下：

spring:
  cloud:
    gateway:
      discovery:
        locator:
          # 禁止gateway通过服务发现组件转发请求到其他的微服务
          enabled: false
      routes:
        - id: user-center
          # 目标URL，lb代表从注册中心获取服务
          uri: lb://user-center
          predicates:
            # 注意名称必须为路由谓词工厂类名的前缀，参数为允许访问的时间段
            - TimeBetween=上午9:00,下午5:00

可以看到这里主要是配置了我们自定义的路由谓词工厂类名的前缀以及允许访问的时间段，这个时间格式不是随便配置的，而是Spring Cloud Gateway的默认时间格式，相关源码如下：

  • org.springframework.format.support.DefaultFormattingConversionService#addDefaultFormatters

时间格式是可以注册的，关于时间格式注册的相关源码如下：

  • org.springframework.format.datetime.standard.DateTimeFormatterRegistrar#registerFormatters

另外，这里之所以要禁止gateway通过服务发现组件转发请求到其他的微服务，是因为开启该配置项的话会导致我们自定义的路由谓词工厂不生效。不生效也是有原因的，开启该配置项会令Gateway优先将请求按照该配置项进行转发，那么我们自定义的路由就不会生效。

到此为止我们就实现了一个自定义路由谓词工厂，若此时不在允许的访问时间段内，访问就会报404，如下：

过滤器工厂

前面提到了过滤器可以为请求和响应添加一些业务逻辑或者修改请求和响应对象等，适当地使用过滤器可以让我们的工作事半功倍，而本小节将要介绍的过滤器工厂就是用来创建过滤器的。在此之前我们已经学习过路由谓词工厂了，而过滤器工厂与路由谓词工厂在使用上是类似的，只不过实现的功能不一样。

内置的过滤器工厂

同样的Spring Cloud Gateway内置了非常多的过滤器工厂，有二十多个。通过这些内置的过滤器工厂就已经可以灵活且方便地处理请求和响应数据，由于Gateway内置的过滤器工厂实在太多，而篇幅有限就不在本文中介绍了，可以参考另一篇文章：

自定义过滤器工厂

若Spring Cloud Gateway内置的过滤器工厂无法满足我们的业务需求，那么此时就需要自定义自己的过滤器工厂以实现特定功能。所谓过滤器工厂实际上就是用于创建过滤器实例的，而创建的过滤器实例都实现于GatewayFilter接口。

过滤器的生命周期：

  • Gateway以转发请求为边界，所以其生命周期只包含pre和post：

    • pre：Gateway转发请求之前
    • post：Gateway转发请求之后

自定义过滤器工厂的方式：

  1. 继承AbstractGatewayFilterFactory，参考源码：org.springframework.cloud.gateway.filter.factory.RequestSizeGatewayFilterFactory。使用该方式实现的过滤器工厂的配置形式如下：

    spring:
cloud:
gateway:
  routes:
    filters:
    # 过滤器工厂的名称
    - name: RequestSize
      # 该过滤器工厂的参数
      args:
        maxSize: 500000
  2. 继承AbstractNameValueGatewayFilterFactory，参考源码：org.springframework.cloud.gateway.filter.factory.AddRequestHeaderGatewayFilterFactory。使用该方式实现的过滤器工厂的配置形式如下： 
    spring:
cloud:
gateway:
  routes:
    filters:
    # 过滤器工厂的名称及参数以name-value的形式配置
    - AddRequestHeader=S-Header, Bar

注：AbstractNameValueGatewayFilterFactory继承了AbstractGatewayFilterFactory，所以实际上第二种方式是第一种方式的简化

核心API：

  • exchange.getRequest().mutate().xxx：修改request
  • exchange.mutate().xxx：修改exchange
  • chain.filter(exchange)：传递给下一个过滤器处理
  • exchange.getResponse()：获取响应对象

注：这里的exchange实际类型为ServerWebExchange，chain实际类型为GatewayFilter

最后我们来实际动手编写一个自定义过滤器工厂，需求是记录访问日志，这里为了简单起见采用第二种方式实现，具体代码如下：

package com.zj.node.gateway.filter;

import lombok.extern.slf4j.Slf4j;
import org.springframework.cloud.gateway.filter.GatewayFilter;
import org.springframework.cloud.gateway.filter.factory.AbstractNameValueGatewayFilterFactory;
import org.springframework.http.server.reactive.ServerHttpRequest;
import org.springframework.stereotype.Component;
import org.springframework.web.server.ServerWebExchange;

/**
 * 过滤器工厂必须以GatewayFilterFactory结尾，
 * 这是Spring Cloud Gateway的约定
 *
 * @author 01
 * @date 2019-08-15
 **/
@Slf4j
@Component
public class PreLogGatewayFilterFactory extends AbstractNameValueGatewayFilterFactory {

    @Override
    public GatewayFilter apply(NameValueConfig config) {
        // 使用lambda表达式来创建GatewayFilter的实例，实际就是匿名内部类的简写
        return (exchange, chain) -> {
            // 通过config获取配置的参数
            log.info("配置参数：{}, {}", config.getName(), config.getValue());

            // 修改request，可以添加一些header什么的
            ServerHttpRequest modifiedRequest = exchange.getRequest()
                    .mutate()
                    .header("X-GatewayHeader","A","B")
                    .build();

            // 打印访问的接口地址
            String path = modifiedRequest.getURI().getPath();
            log.info("访问的接口为：{}", path);

            // 修改exchange
            ServerWebExchange modifiedExchange = exchange.mutate()
                    .request(modifiedRequest).build();

            // 传递给下一个过滤器处理
            return chain.filter(modifiedExchange);
        };
    }
}

最后需要添加相关配置以启用这个过滤器工厂，如下：

spring:
  cloud:
    gateway:
      routes:
        - id: user-center
          uri: lb://user-center
          predicates:
            - TimeBetween=上午9:00,下午5:00
          filters:
            # 名称必须为过滤器工厂类名的前缀，并且参数只能有两个，因为NameValueConfig里只定义了两个属性
            - PreLog=testName,testValue

启动项目，访问user-center的接口，此时控制台输出的日志如下：

全局过滤器

现在我们已经知道前面所介绍的过滤器工厂实际用于创建GatewayFilter实例，并且这些GatewayFilter实例仅作用于指定的路由上，那么有没有可以作用于全部路由上的过滤器呢？答案是有的，这就是本小节将要介绍的全局过滤器。Spring Cloud Gateway默认就内置了许多全局过滤器，本文仅介绍如何自定义全局过滤器，关于Gateway内置的过滤器可以参考另一篇文章：

自定义全局过滤需要实现GlobalFilter 接口，该接口和 GatewayFilter 有一样的方法定义，只不过 GlobalFilter 的实例会作用于所有的路由。

Tips：

官方声明：GlobalFilter的接口定义以及用法在未来的版本可能会发生变化。

个人判断：GlobalFilter可用于生产；如果有自定义GlobalFilter的需求，理论上也可放心使用。因为未来即使接口定义以及使用方式发生变化，理应也是平滑过渡的（比如Zuul的Fallback，原先叫ZuulFallbackProvider，后来改叫FallbackProvider，中间就有段时间新旧使用方式都支持，后面才逐步废弃老的使用方式）。

接下来我们自定义一个全局过滤器，需求是打印访问的接口路径以及打印该接口的访问耗时。具体代码如下：

package com.zj.node.gateway.filter;

import lombok.extern.slf4j.Slf4j;
import org.springframework.cloud.gateway.filter.GatewayFilterChain;
import org.springframework.cloud.gateway.filter.GlobalFilter;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;

/**
 * 自定义全局过滤器
 *
 * @author 01
 * @date 2019-08-17
 **/
@Slf4j
public class MyGlobalFilter implements GlobalFilter {

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        String path = exchange.getRequest().getURI().getPath();
        log.info("[MyGlobalFilter] 访问的接口：{}", path);

        long start = System.currentTimeMillis();
        return chain.filter(exchange)
                // then的内容会在过滤器返回的时候执行，即最后执行
                .then(Mono.fromRunnable(() ->
                        log.info("[ {} ] 接口的访问耗时：{} /ms",
                        path, System.currentTimeMillis() - start))
                );
    }
}

最后需要使该全局过滤器生效，方法有很多种，可以直接在该类上加@Component注解，也可以通过代码配置（@Bean），还有其他的一些方式。这里个人比较倾向于使用一个专门的配置类去实例化这些全局过滤器并交给Spring容器管理。代码如下：

package com.zj.node.gateway.config;

import com.zj.node.gateway.filter.MyGlobalFilter;
import lombok.extern.slf4j.Slf4j;
import org.springframework.cloud.gateway.filter.GlobalFilter;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.core.Ordered;
import org.springframework.core.annotation.Order;

@Slf4j
@Configuration
public class FilterConfig {

    @Bean
    // 该注解用于指定过滤器的执行顺序，数字越小越优先执行
    @Order(Ordered.HIGHEST_PRECEDENCE)
    public GlobalFilter myGlobalFilter(){
        log.info("create myGlobalFilter...");
        return new MyGlobalFilter();
    }
}

启动项目，看看我们自定义的全局过滤器是否已生效，访问Gateway控制台输出如下：

原文地址：https://blog.51cto.com/zero01/2430424

时间： 2024-10-11 07:42:03

第二代微服务网关组件 - Spring Cloud Gateway的相关文章

微服务架构之spring cloud gateway

Spring Cloud Gateway是spring cloud中起着非常重要的作用,是终端调用服务的入口,同时也是项目中每个服务对外暴露的统一口径,我们可以在网关中实现路径映射.权限验证.负载均衡.服务聚合等业务功能. (一) 版本说明 a) Spring boot 2.0.6.RELEASE b) Spring cloud Finchley.SR2 c) Java version 1.8 d) spring-cloud-starter-gateway 2.0.2.RELEASE (二) 项

微服务为什么选Spring Cloud？

前言现如今微服务架构十分流行,而采用微服务构建系统也会带来更清晰的业务划分和可扩展性.同时,支持微服务的技术栈也是多种多样的,本系列文章主要介绍这些技术中的翘楚--Spring Cloud.这是序篇,主要讲述我们为什么选择Spring Cloud和它的技术概览. 1.为什么微服务架构需要Spring Cloud 简单来说,服务化的核心就是将传统的一站式应用根据业务拆分成一个一个的服务,而微服务在这个基础上要更彻底地去耦合(不再共享DB.KV,去掉重量级ESB),并且强调DevOps和快速演化.这

微服务架构之spring cloud 介绍

在当前的软件开发行业中,尤其是互联网,微服务是非常炽热的一个词语,市面上已经有一些成型的微服务框架来帮助开发者简化开发工作量,但spring cloud 绝对占有一席之地,不管你是否为java开发,大部分都应该听说过,因为他实现了微服务所必备的功能. Spring cloud总体概览,这是我用了近3个小时的成果,也是实际项目的总结. a)         Spring cloud gateway 是网关,起到总管的作用,也是终端调用服务的第一道门槛,统一的入口. b)        Spring

最全面的改造Zuul网关为Spring Cloud Gateway（包含Zuul核心实现和Spring Cloud Gateway核心实现）

前言: 最近开发了Zuul网关的实现和Spring Cloud Gateway实现,对比Spring Cloud Gateway发现后者性能好支持场景也丰富.在高并发或者复杂的分布式下,后者限流和自定义拦截也很棒. 提示: 本文主要列出本人开发的Zuul网关核心代码以及Spring Cloud Gateway核心代码实现.因为本人技术有限,主要是参照了 Spring Cloud Gateway 如有不足之处还请见谅并留言指出. 1:为什么要做网关 (1)网关层对外部和内部进行了隔离,保障了后台服

创建网关项目(Spring Cloud Gateway)

创建网关项目 加入网关后微服务的架构图 创建项目 POM文件 <properties> <java.version>1.8</java.version> <spring-cloud.version>Greenwich.SR3</spring-cloud.version> </properties> <dependencies> <dependency> <groupId>org.springfram

微服务架构之spring cloud eureka

Spring Cloud Eureka是spring cloud的核心组件,负责服务治理功能,起到中心枢纽作用,其它组件都依赖eureka来获取服务,然后再根据项目需求实现自己的业务,eureka在整个微服务架构中的位置绝对是核心地位. (一)   版本说明 a)         Spring boot   2.0.6.RELEASE b)        Spring cloud  Finchley.SR2 c)         Java version   1.8 (二)   项目设置 Pom

微服务架构之spring cloud turbine

在前面介绍了spring cloud hystrix及其hystrix dashboard,但都是对单个项目的监控,对于一个为项目而言,必定有很多微服务,一个一个去看非常的不方便,如果有一个能集中熔断器监控的地方就完美了,spring cloud turbine 就实现了这样的功能,这篇文章就来介绍spring cloud turbine. (一) 版本说明 a) Spring boot 2.0.6.RELEASE b) Spring cloud Finchley.SR2 c) Java ver

微服务架构之spring cloud hystrix&amp;hystrix dashboard

在前面介绍spring cloud feign中我们已经使用过hystrix,只是没有介绍,spring cloud hystrix在spring cloud中起到保护微服务的作用,不会让发生的异常无边界的蔓延下去,很像我们电路中的保险设置,有超压或者线路有问题就即时的断开,保护用电设备不被损坏,这篇文章就来介绍spring cloud hystrix及其hystrix dashboard. (一) 版本说明 a) Spring boot 2.0.6.RELEASE b) Spring clou

微服务：整合 Spring cloud Eureka - 服务治理机制

一.简介 在体验了Spring Cloud Eureka 通过简单的注解配置就能实现强大的服务治理功能之后,我们可以进一步了解一些Eureka基础架构中各个元素之间的通信行为,以此来更加深入的理解Eureka服务治理体系是如何运转起来的. 二.微服务基础架构拓扑图 1.“Eureka Server 服务注册中心-1” 和 “Eureka Server 服务注册中心-2” ,他们相互注册成为高可用集群. 2.服务提供者启动两个实例,一个注册到“Eureka Server 服务注册中心-1” 上,另