springcloud



系统架构演变

随着互联网的发展,网站应用的规模不断扩大。需求的激增,带来的是技术上的压力。系统架构也因此也不断的演进、升级、迭代。从单一应用,到垂直拆分,到分布式服务,到SOA,以及现在火热的微服务架构,还有在Google带领下来势汹涌的Service Mesh。我们到底是该乘坐微服务的船只驶向远方,还是偏安一隅得过且过?

集中式架构

当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本。此时,用于简化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键。

存在的问题:

  • 代码耦合,开发维护困难
  • 无法针对不同模块进行针对性优化
  • 无法水平扩展
  • 单点容错率低,并发能力差

水平拆分

在水平扩展模型中,水平拆分是简单的通过增加更多的系统成员来实现。

垂直拆分

当访问量逐渐增大,单一应用无法满足需求,此时为了应对更高的并发和业务需求,我们根据业务功能对系统进行拆分:

优点:

  • 系统拆分实现了流量分担,解决了并发问题
  • 可以针对不同模块进行优化
  • 方便水平扩展,负载均衡,容错率提高
  • 解耦合

缺点:

  • 系统间相互独立,会有很多重复开发工作,影响开发效率,增加维护成本

分布式服务

当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。此时,用于提高业务复用及整合的分布式调用是关键。

优点:

  • 将基础服务进行了抽取,系统间相互调用,提高了代码复用和开发效率

缺点:

  • 系统间耦合度变高,调用关系错综复杂,难以维护

面向服务的架构(SOA)

当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率。此时,用于提高集群利用率的资源调度和治理中心(SOA)是关键

以前出现了什么问题?

  • 服务越来越多,需要管理每个服务的地址
  • 调用关系错综复杂,难以理清依赖关系
  • 服务过多,服务状态难以管理,无法根据服务情况动态管理

服务治理要做什么?

  • 服务注册中心,实现服务自动注册和发现,无需人为记录服务地址
  • 服务自动订阅,服务列表自动推送,服务调用透明化,无需关心依赖关系
  • 动态监控服务状态监控报告,人为控制服务状态

缺点:

  • 服务间会有依赖关系,一旦某个环节出错会影响较大
  • 服务关系复杂,运维、测试部署困难,不符合DevOps思想

微服务

前面说的SOA,英文翻译过来是面向服务。微服务,似乎也是服务,都是对系统进行拆分。因此两者非常容易混淆,但其实有一些差别:

微服务的特点:

  • 单一职责:微服务中每一个服务都对应唯一的业务能力,做到单一职责
  • 微:微服务的服务拆分粒度很小,例如一个用户管理就可以作为一个服务。每个服务虽小,但“五脏俱全”。
  • 面向服务:面向服务是说每个服务都要对外暴露服务接口API。并不关心服务的技术实现,做到与平台和语言无关,也不限定用什么技术实现,只要提供Rest的接口即可。
  • 自治:自治是说服务间互相独立,互不干扰
    • 团队独立:每个服务都是一个独立的开发团队,人数不能过多。
    • 技术独立:因为是面向服务,提供Rest接口,使用什么技术没有别人干涉
    • 前后端分离:采用前后端分离开发,提供统一Rest接口,后端不用再为PC、移动段开发不同接口
    • 数据库分离:每个服务都使用自己的数据源
    • 部署独立,服务间虽然有调用,但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件,可复用,可替换,降低耦合,易维护

微服务结构图:

远程调用方式

无论是微服务还是SOA,都面临着服务间的远程调用。那么服务间的远程调用方式有哪些呢?

常见的远程调用方式有以下几种:

  • RPC:Remote Produce Call远程过程调用,类似的还有RMI。自定义数据格式,基于原生TCP通信,速度快,效率高。早期的webservice,现在热门的dubbo,都是RPC的典型

  • Http:http其实是一种网络传输协议,基于TCP,规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用Http协议。也可以用来进行远程服务调用。缺点是消息封装臃肿。

    现在热门的Rest风格,就可以通过http协议来实现。

认识RPC

RPC,即 Remote Procedure Call(远程过程调用),是一个计算机通信协议。 该协议允许运行于一台计算机的程序调用另一台计算机的子程序,而程序员无需额外地为这个交互作用编程。说得通俗一点就是:A计算机提供一个服务,B计算机可以像调用本地服务那样调用A计算机的服务。

通过上面的概念,我们可以知道,实现RPC主要是做到两点:

  1. 实现远程调用其他计算机的服务

    要实现远程调用,肯定是通过网络传输数据。A程序提供服务,B程序通过网络将请求参数传递给A,A本地执行后得到结果,再将结果返回给B程序。这里需要关注的有两点:

    • 采用何种网络通讯协议?

      现在比较流行的RPC框架,都会采用TCP作为底层传输协议

    • 数据传输的格式怎样?

      两个程序进行通讯,必须约定好数据传输格式。就好比两个人聊天,要用同一种语言,否则无法沟通。所以,我们必须定义好请求和响应的格式。另外,数据在网路中传输需要进行序列化,所以还需要约定统一的序列化的方式。

  2. 要像调用本地服务一样调用远程服务

    如果仅仅是远程调用,还不算是RPC,因为RPC强调的是过程调用,调用的过程对用户而言是应该是透明的,用户不应该关心调用的细节,可以像调用本地服务一样调用远程服务。所以RPC一定要对调用的过程进行封装

RPC调用流程图:

想要了解详细的RPC实现,给大家推荐一篇文章:自己动手实现RPC

认识Http

Http协议:超文本传输协议,是一种应用层协议。规定了网络传输的请求格式、响应格式、资源定位和操作的方式等。但是底层采用什么网络传输协议,并没有规定,不过现在都是采用TCP协议作为底层传输协议。说到这里,大家可能觉得,Http与RPC的远程调用非常像,都是按照某种规定好的数据格式进行网络通信,有请求,有响应。没错,在这点来看,两者非常相似,但是还是有一些细微差别。

  • RPC并没有规定数据传输格式,这个格式可以任意指定,不同的RPC协议,数据格式不一定相同。
  • Http中还定义了资源定位的路径,RPC中并不需要
  • 最重要的一点:RPC需要满足像调用本地服务一样调用远程服务,也就是对调用过程在API层面进行封装。Http协议没有这样的要求,因此请求、响应等细节需要我们自己去实现。
    • 优点:RPC方式更加透明,对用户更方便。Http方式更灵活,没有规定API和语言,跨语言、跨平台
    • 缺点:RPC方式需要在API层面进行封装,限制了开发的语言环境。

例如我们通过浏览器访问网站,就是通过Http协议。只不过浏览器把请求封装,发起请求以及接收响应,解析响应的事情都帮我们做了。如果是不通过浏览器,那么这些事情都需要自己去完成。

如何选择?

既然两种方式都可以实现远程调用,我们该如何选择呢?

  • 速度来看,RPC要比http更快,虽然底层都是TCP,但是http协议的信息往往比较臃肿,不过可以采用gzip压缩。
  • 难度来看,RPC实现较为复杂,http相对比较简单
  • 灵活性来看,http更胜一筹,因为它不关心实现细节,跨平台、跨语言。

因此,两者都有不同的使用场景:

  • 如果对效率要求更高,并且开发过程使用统一的技术栈,那么用RPC还是不错的。
  • 如果需要更加灵活,跨语言、跨平台,显然http更合适

那么我们该怎么选择呢?

微服务,更加强调的是独立、自治、灵活。而RPC方式的限制较多,因此微服务框架中,一般都会采用基于Http的Rest风格服务。

Http客户端工具

既然微服务选择了Http,那么我们就需要考虑自己来实现对请求和响应的处理。不过开源世界已经有很多的http客户端工具,能够帮助我们做这些事情,例如:

  • HttpClient
  • OKHttp
  • URLConnection

接下来,我们就一起了解一款比较流行的客户端工具:HttpClient

HttpClient

HttpClient是Apache公司的产品,是Http Components下的一个组件。

特点

  • 基于标准、纯净的Java语言。实现了Http1.0和Http1.1
  • 以可扩展的面向对象的结构实现了Http全部的方法(GET, POST, PUT, DELETE, HEAD, OPTIONS, and TRACE)
  • 支持HTTPS协议。
  • 通过Http代理建立透明的连接。
  • 自动处理Set-Cookie中的Cookie。

使用

引入依赖

    org.apache.httpcomponents
    httpclient
    4.5.10

测试
@SpringBootTest
class HttpclientconsumerApplicationTests {

    //1. 安装浏览器
    public CloseableHttpClient httpClient;

    @BeforeEach
    public void init() {
        //2. 打开浏览器
        httpClient = HttpClients.createDefault();
    }

    @Test
    public void get() throws IOException {
        //2. 创建get请求
        HttpGet getRequest = new HttpGet("http://localhost:8080/user");
        String response = httpClient.execute(getRequest, new BasicResponseHandler());
        System.out.println(response);
    }

    @Test
    public void post() throws IOException {
        //创建post请求
        HttpPost postRequest = new HttpPost("http://localhost:8080/user");
        //表单数据
        List formparams = new ArrayList();
        formparams.add(new BasicNameValuePair("username", "zhangsan"));
        formparams.add(new BasicNameValuePair("password", "123456"));
        formparams.add(new BasicNameValuePair("phone", "13945126789"));
        formparams.add(new BasicNameValuePair("created", "2019/10/01"));

        UrlEncodedFormEntity entity = new UrlEncodedFormEntity(formparams, "utf-8");
        postRequest.setEntity(entity);

        String response = httpClient.execute(postRequest, new BasicResponseHandler());
        System.out.println(response);

    }

}

Json转换工具(Jackson)

HttpClient请求数据后是json字符串,需要我们自己把Json字符串反序列化为对象,我们可以使用Jackson工具来实现。

Jackson是SpringMVC内置的json处理工具,其中有一个ObjectMapper类,可以方便的实现对json的处理:

引入依赖


    com.fasterxml.jackson.core
    jackson-databind
    2.10.1

对象转json

@SpringBootTest
class HttpclientserviceApplicationTests {

    @Autowired
    private UserMapper userMapper;

    @Test
    void contextLoads() throws JsonProcessingException {
        TbUser user = userMapper.selectByPrimaryKey(1);

        ObjectMapper mapper=new ObjectMapper();
        //序列化
        String jsonStr = mapper.writeValueAsString(user);
        System.out.println(jsonStr);
    }
}

json转普通对象

    @Test
    public void post() throws IOException {

        //......

        String response = httpClient.execute(postRequest, new BasicResponseHandler());

        ObjectMapper mapper = new ObjectMapper();
        TbUser tbUser = mapper.readValue(response, TbUser.class);
        System.out.println(tbUser);
    }

json转集合

json转集合比较麻烦,因为你无法同时把集合的class和元素的class同时传递到一个参数。因此Jackson做了一个类型工厂,用来解决这个问题:

@Test
public void get() throws IOException {
    //2. 创建get请求
    HttpGet getRequest = new HttpGet("http://localhost:8080/user");
    String response = httpClient.execute(getRequest, new BasicResponseHandler());

    ObjectMapper mapper = new ObjectMapper();
    CollectionLikeType type = mapper.getTypeFactory().constructCollectionType(List.class, TbUser.class);
    List users = mapper.readValue(response, type);
    System.out.println(users);
}

json转任意复杂类型

当对象泛型关系复杂时,类型工厂也不好使了。这个时候Jackson提供了TypeReference来接收类型泛型,然后底层通过反射来获取泛型上的具体类型。实现数据转换。

    @Test
    public void testJsonToMap() throws IOException {
        Map map = new HashMap<>();

        ObjectMapper mapper = new ObjectMapper();
        TypeReference> listTypeReference = new TypeReference>() {
        };

        //使用TypeReference,它是一个抽象类
        List users = mapper.readValue(new URL("http://localhost:8080/user"), listTypeReference);

        for (TbUser user : users) {
            map.put(user.getUsername(), user);
        }

        //序列化
        String mapJson = mapper.writeValueAsString(map);
        System.out.println(mapJson);

        //反序列化,使用类型工厂
        Map result = mapper.readValue(mapJson, mapper.getTypeFactory().constructMapType(HashMap.class, String.class, TbUser.class));


        System.out.println(result);

    }

Spring的RestTemplate

Spring提供了一个RestTemplate模板工具类,对基于Http的客户端进行了封装,并且实现了对象与json的序列化和反序列化,非常方便。RestTemplate并没有限定Http的客户端类型,而是进行了抽象,目前常用的3种都有支持:

  • HttpClient
  • OkHttp
  • JDK原生的URLConnection(默认的)

首先在项目中注册一个RestTemplate对象,可以在启动类位置注册:

要使用RestTemplate,需要映入web场景,web场景包括Jackson,所以可以把开始引入的Jackson依赖删掉了

给调用服务的项目添加web场景


    org.springframework.boot
    spring-boot-starter-web

给容器中添加RestTemplate

@SpringBootApplication
public class HttpclientconsumerApplication {

    public static void main(String[] args) {
        SpringApplication.run(HttpclientconsumerApplication.class, args);
    }

    @Bean
    public RestTemplate resttemplate() {
        return new RestTemplate();
    }
}

测试

@SpringBootTest
class HttpclientconsumerApplicationTests {

    @Autowired
    private RestTemplate restTemplate;

    @Test
    public void restTemplateGet() {
        List users = restTemplate.getForObject("http://localhost:8080/user", List.class);
        System.out.println("users --> " + users);
    }
}

初识SpringCloud

微服务是一种架构方式,最终肯定需要技术架构去实施。

微服务的实现方式很多,但是最火的莫过于Spring Cloud了。为什么?

  • 后台硬:作为Spring家族的一员,有整个Spring全家桶靠山,背景十分强大。
  • 技术强:Spring作为Java领域的前辈,可以说是功力深厚。有强力的技术团队支撑,一般人还真比不了
  • 群众基础好:可以说大多数程序员的成长都伴随着Spring框架,试问:现在有几家公司开发不用Spring?SpringCloud与Spring的各个框架无缝整合,对大家来说一切都是熟悉的配方,熟悉的味道。
  • 使用方便:相信大家都体会到了SpringBoot给我们开发带来的便利,而SpringCloud完全支持SpringBoot的开发,用很少的配置就能完成微服务框架的搭建

简介

SpringCloud是Spring旗下的项目之一,官网:https://spring.io/projects/spring-cloud

Spring最擅长的就是集成,把世界上最好的框架拿过来,集成到自己的项目中。

SpringCloud也是一样,它将现在非常流行的一些技术整合到一起,实现了诸如:配置管理,服务发现,智能路由,负载均衡,熔断器,控制总线,集群状态等等功能。其主要涉及的组件包括:

  • Eureka:注册中心
  • Zuul:服务网关
  • Ribbon:负载均衡
  • Feign:服务调用
  • Hystix:熔断器

以上只是其中一部分,架构图:

SpringCloud的版本

因为Spring Cloud不同其他独立项目,它拥有很多子项目的大项目。所以它的版本是版本名+版本号 (如Angel.SR6)。

版本名:是伦敦的地铁名

版本号:SR(Service Releases)是固定的 ,大概意思是稳定版本。后面会有一个递增的数字。

所以 Edgware.SR3就是Edgware的第3个Release版本。

微服务创景模拟

首先,我们需要模拟一个服务调用的场景,搭建两个工程:springcloud-service-provider(服务提供方)和springcloud-service-consumer(服务调用方)。方便后面学习微服务架构

服务提供方:使用mybatis操作数据库,实现对数据的增删改查;并对外提供rest接口服务。

服务消费方:使用restTemplate远程调用服务提供方的rest接口服务,获取数据。

步骤几乎和HttpClient调一致

服务提供方

  1. 创建项目命名为springcloud-service-provider,选择web场景和mysql驱动,添加通用mapper场景


    4.0.0
    
        org.springframework.boot
        spring-boot-starter-parent
        2.2.6.RELEASE
         
    
    top.codekiller.service
    springcloud-service-provider
    0.0.1-SNAPSHOT
    springcloud-service-provider
    Demo project for Spring Boot

    
        1.8
    

    
        
            org.springframework.boot
            spring-boot-starter-jdbc
        
        
            org.springframework.boot
            spring-boot-starter-web
        
        
            com.baomidou
            mybatis-plus-boot-starter
            3.3.1
        

        
            mysql
            mysql-connector-java
            runtime
        
        
            org.springframework.boot
            spring-boot-starter-test
            test
            
                
                    org.junit.vintage
                    junit-vintage-engine
                
            
        
        
            com.alibaba
            druid-spring-boot-starter
            1.1.20
        
    

    
        
            
                org.springframework.boot
                spring-boot-maven-plugin
            
        
    


  1. 配置数据库连接
application.yml

server:
  port: 8080
spring:
  datasource:
    username: root
    password: root
    url: jdbc:mysql://localhost:3306/leyou?characterEncoding=UTF-8&serverTimezone=UTC
    type: com.alibaba.druid.pool.DruidDataSource
    # 下面为连接池的补充设置,应用到上面所有数据源中
    # 初始化大小,最小,最大
    initialSize: 5   #初始化创建的连接数
    minIdle: 5  #最小空闲连接数
    maxActive: 20 #最大活跃连接数,不宜设置过多
    # 配置获取连接等待超时的时间
    maxWait: 60000
    # 配置间隔多久才进行一次检测,检测需要关闭的空闲连接,单位是毫秒
    timeBetweenEvictionRunsMillis: 60000
    # 配置一个连接在池中最小生存的时间,单位是毫秒
    minEvictableIdleTimeMillis: 30000
    #用来检测连接是否有效的sql,要求是一个查询语句,常用select 'x'。
    validationQuery: select 'x';
    #建议配置为true,不影响性能,并且保证安全性。申请连接的时候检测,
    testWhileIdle: true
    #申请连接时执行validationQuery检测连接是否有效,做了这个配置会降低性能。
    testOnBorrow: false
    #归还连接时执行validationQuery检测连接是否有效,做了这个配置会降低性能。
    testOnReturn: false
    # 打开PSCache,并且指定每个连接上PSCache的大小
    #是否缓存preparedStatement,也就是PSCache。PSCache对支持游标的数据库性能提升巨大,比如说oracle。在mysql下建议关闭。
    poolPreparedStatements: true
    #要启用PSCache,必须配置大于0,当大于0时,poolPreparedStatements自动触发修改为true。
    #在Druid中,不会存在Oracle下PSCache占用内存过多的问题,可以把这个数值配置大一些,比如说100
    maxPoolPreparedStatementPerConnectionSize: 20
    # 配置监控统计拦截的filters,去掉后监控界面sql无法统计,stat用于监控统计,'wall'用于防火墙,防御sql注入,slf4j用于日志
    filters: stat,wall,slf4j
    # 通过connectProperties属性来打开mergeSql功能;慢SQL记录
    connectionProperties: druid.stat.mergeSql=true;druid.stat.slowSqlMillis=5000
    # 合并多个DruidDataSource的监控数据
    useGlobalDataSourceStat: true
    mybatis-plus:
  type-aliases-package: top.codekiller.service.pojo
  global-config:
    db-config:
      id-type: assign_id
      table-prefix: tb_
      logging:
  level:
    top.codekiller.service: debug
  1. 将用户实体类添加到项目中

    @Data
    @Component
    public class User {
        @TableId
        private Long id;
        private String username;
        private String password;
        private String phone;
        private Date created;
    
    }
    
  1. 添加UserMapper

    public interface UserMapper extends BaseMapper {
    
    }
    
  1. UserService
@Service
public class UserSerivce {

    @Autowired
    UserMapper userMapper;

    public User queryUserById(Long id) {
        return userMapper.selectById(id);
    }

}
  1. UserController
@RequestMapping("user")
@RestController
public class UserController {

    @Autowired
    UserSerivce userSerivce;

    @GetMapping("/{id}")
    public User queryUserById(@PathVariable Long id) {
        return userSerivce.queryUserById(id);

    }
}
  1. 添加mapper扫描
@MapperScan("top.codekiller.service.mapper")
@Configuration
public class MyBatisPlusConfig {

}

服务消费方

  1. 创建工程,名为springcloud-service-consumer,只需要选择web场景即可

  2. 把实体类复制一份过来,把不需要的注解删除掉

  3. 在启动类中向容器注入RestTemplate

    @SpringBootApplication
    public class SpringcloudServiceConsumerApplication {
    
        public static void main(String[] args) {
            SpringApplication.run(SpringcloudServiceConsumerApplication.class, args);
        }
    
        @Bean
        public RestTemplate restTemplate() {
            return new RestTemplate();
        }
    }
    
  4. 创建Controlelr使用restTemplate调用服务

@RestController
@RequestMapping("user")
public class UserController {

    @Autowired
    private RestTemplate restTemplate;

    @GetMapping("/{id}")
    public TbUser getUserById(@PathVariable Long id) {
        return restTemplate.getForObject("http://localhost:8080/user/" + id, User.class);
    }
}
  1. 修改端口号启动测试
server:
  port: 8081
  1. 创建实体类

    @Data
    public class User {
    
        private Long id;
        private String username;
        private String password;
        private String phone;
        private Date created;
    
    }
    

存在的问题?

简单回顾一下,刚才我们写了什么:

  • springcloud-service-provider:一个提供根据id查询用户的微服务。
  • springcloud-service-consumer:一个服务调用者,通过RestTemplate远程调用springcloud-service-provider。

存在什么问题?

  • 在consumer中,我们把url地址硬编码到了代码中,不方便后期维护
  • consumer需要记忆provider的地址,如果出现变更,可能得不到通知,地址将失效
  • consumer不清楚provider的状态,服务宕机也不知道
  • provider只有1台服务,不具备高可用性
  • 即便provider形成集群,consumer还需自己实现负载均衡

其实上面说的问题,概括一下就是分布式服务必然要面临的问题:

  • 服务管理
    • 如何自动注册和发现
    • 如何实现状态监管
    • 如何实现动态路由
  • 服务如何实现负载均衡
  • 服务如何解决容灾问题
  • 服务如何实现统一配置

以上的问题,我们都将在SpringCloud中得到答案。

Eureka注册中心

认识Eureka

首先我们来解决第一问题,服务的管理。

问题分析

在刚才的案例中,springcloud-service-provider对外提供服务,需要对外暴露自己的地址。而consumer(调用者)需要记录服务提供者的地址。将来地址出现变更,还需要及时更新。这在服务较少的时候并不觉得有什么,但是在现在日益复杂的互联网环境,一个项目肯定会拆分出十几,甚至数十个微服务。此时如果还人为的管理地址,不仅开发困难,将来测试、发布上线都会非常麻烦,这与DevOps的思想是背道而驰的。

网约车

这就好比是 网约车出现以前,人们出门叫车只能叫出租车。一些私家车想做出租却没有资格,被称为黑车。而很多人想要约车,但是无奈出租车太少,不方便。私家车很多却不敢拦,而且满大街的车,谁知道哪个才是愿意载人的。一个想要,一个愿意给,就是缺少引子,缺乏管理啊。

此时滴滴这样的网约车平台出现了,所有想载客的私家车全部到滴滴注册,记录你的车型(服务类型),身份信息(联系方式)。这样提供服务的私家车,在滴滴那里都能找到,一目了然。

此时要叫车的人,只需要打开APP,输入你的目的地,选择车型(服务类型),滴滴自动安排一个符合需求的车到你面前,为你服务,完美!

Eureka做什么?

Eureka就好比是滴滴,负责管理、记录服务提供者的信息。服务调用者无需自己寻找服务,而是把自己的需求告诉Eureka,然后Eureka会把符合你需求的服务告诉你。

同时,服务提供方与Eureka之间通过心跳机制进行监控,当某个服务提供方出现问题,Eureka自然会把它从服务列表中剔除。

这就实现了服务的自动注册、发现、状态监控。

原理图

入门案列

搭建EurekaServer

创建一个项目名为springcloud-eureka-server,启动一个EurekaServer

选择依赖

EurekaServer-服务注册中心依赖,Eureka Discovery-服务提供方和服务消费方。因为,对于eureka来说:服务提供方和服务消费方都属于客户端,注意选择Springboot的版本,可以查看springcloud官网当前稳定版本兼容的springboot版本

maven依赖
    
        1.8
        
        Hoxton.SR3
    

    
    
        
            org.springframework.cloud
            spring-cloud-starter-netflix-eureka-server
        

        
            org.springframework.boot
            spring-boot-starter-test
            test
        
    

    
    
        
            
                org.springframework.cloud
                spring-cloud-dependencies
                ${spring-cloud.version}
                pom
                import
            
        
    
配置application.yml
server:
  port: 10086
spring:
  application:
    # 应用名称,会在Eureka中显示
    name: eureka-server
eureka:
  client:
    # 此应用为注册中心,false:不向注册中心注册自己。不配置这个启动会抛出一堆错误,不过不影响启动,就是看着闹心
    register-with-eureka: false
    # 注册中心职责是维护服务实例,false:不检索服务。(因为这是一个单点的EurekaServer,不需要同步其它EurekaServer节点的数据,故设为false)
    fetch-registry: false
    service-url:
      # EurekaServer的地址,现在是自己的地址,如果是集群,需要加上其它Server的地址。
      defaultZone: http://127.0.0.1:${server.port}/eureka
@EnableEurekaServer

声明当前springboot应用是一个eureka服务中心

修改引导类,在类上添加@EnableEurekaServer注解:

@SpringBootApplication
@EnableEurekaServer //启动eureka服务端
public class SpringcloudServiceEurekaApplication {

    public static void main(String[] args) {
        SpringApplication.run(SpringcloudServiceEurekaApplication.class, args);
    }

}

启动服务,访问:http://localhost:10086

注册服务到EurekaServer

注册服务,就是在服务上添加Eureka的客户端依赖,客户端代码会自动把服务注册到EurekaServer中。

创建项目,项目名为springcloud-eureka-service-provider,选择web场景和eureka客户端场景,添加mysql驱动和通用mapper依赖

导入依赖

    1.8
    Hoxton.SR3



    org.springframework.cloud
    spring-cloud-starter-netflix-eureka-client



    
        
            org.springframework.cloud
            spring-cloud-dependencies
            ${spring-cloud.version}
            pom
            import
        
    

其他配置

application.yml
server:
  port: 8080
spring:
  datasource:
    username: root
    password: root
    url: jdbc:mysql://localhost:3306/leyou?characterEncoding=UTF-8&serverTimezone=UTC
    type: com.alibaba.druid.pool.DruidDataSource
#######################省略数据源配置############################
#应用名称,注册到Euerka后的服务名称
  application:
    name: service-provider

mybatis-plus:
  type-aliases-package: top.codekiller.service.pojo
  global-config:
    db-config:
      id-type: assign_id
      table-prefix: tb_


logging:
  level:
    top.codekiller.service: debug

eureka:
  client:
  #EurekaServer地址
    service-url:
      ddefaultZone: http://localhost:10086/eureka

这里我们添加了spring.application.name属性来指定应用名称,将来会作为应用的id使用。

@EurekaDiscoveryClient

在引导类上开启Eureka客户端功能

通过添加@EnableDiscoveryClient来开启Eureka客户端功能,也可以会用@EnableEurekaClient

@SpringBootApplication
@EnableDiscoveryClient  //启动Eureka客户端
public class SpringcloudServiceProviderApplication {

    public static void main(String[] args) {
        SpringApplication.run(SpringcloudServiceProviderApplication.class, args);
    }

}

重启项目,访问http://localhost:10086查看

从Eureka获取服务

引入依赖,配置yml文件,使用@EnableDiscoveryClient

修改Controller
@RequestMapping("consumer/user")
@RestController
public class UserController {

    @Autowired
    private RestTemplate restTemplate;

    @Autowired
    /**
     * eureka客户端,可以获取到eureka中服务的信息
     */
    private DiscoveryClient discoveryClient;

    @GetMapping("/{id}")
    public User queryUserById(@PathVariable("id")Long id){
        List instances = discoveryClient.getInstances("service-provider");
        ServiceInstance instance=instances.get(0);
        String hostName=instance.getHost();
        Integer port=instance.getPort();
        User user=restTemplate.getForObject("http://"+hostName+":"+port+"/user/"+id,User.class);
        return user;
    }
}

Eureka高可用和详解

基础架构

Eureka架构中的三个核心角色:

  • 服务注册中心

    Eureka的服务端应用,提供服务注册和发现功能,就是刚刚我们建立的springcloud-eureka-server

  • 服务提供者

    提供服务的应用,可以是SpringBoot应用,也可以是其它任意技术实现,只要对外提供的是Rest风格服务即可。上节案例中就是我们实现的springcloud-eureka-service-provider

  • 服务消费者

    消费应用从注册中心获取服务列表,从而得知每个服务方的信息,知道去哪里调用服务方。上节案例中就是我们实现的springcloud-eureka-service-consumer

高可用的Eureka Server

Eureka Server即服务的注册中心,在上节的案例中,我们只有一个EurekaServer,事实上EurekaServer也可以是一个集群,形成高可用的Eureka中心。

服务同步

多个Eureka Server之间也会互相注册为服务,当服务提供者注册到Eureka Server集群中的某个节点时,该节点会把服务的信息同步给集群中的每个节点,从而实现数据同步。因此,无论客户端访问到Eureka Server集群中的任意一个节点,都可以获取到完整的服务列表信息。

动手搭建高可用的EurekaServer

我们假设要运行两个EurekaServer的集群,端口分别为:10086和10087。只需要把springcloud-eureka-server启动两次即可。

server:
  port: 10087

spring:
  application:
    name: Eureka-Server

eureka:
  client:
    service-url:
      defaultZone: http://localhost:10086/eureka

所谓的高可用注册中心,其实就是把EurekaServer自己也作为一个服务进行注册,这样多个EurekaServer之间就能互相发现对方,从而形成集群。因此我们做了以下修改:

  • 把service-url的值改成了另外一台EurekaServer的地址,而不是自己

启动报错,很正常。因为10086服务没有启动:

再次修改springcloud-eureka-server的配置(将10087注册给10086):

server:
  port: 10086

spring:
  application:
    name: Eureka-Server

eureka:
  client:
    service-url:
      # EurekaServer的地址,现在是自己的地址,如果是集群,需要加上其它Server的地址。
      defaultZone: http://localhost:10087/eureka

将应用复制一份,换个名字,点击应用然后启动,如果没有services这个窗口,参考这里:RunDashboard如何显示出来,也可以使用第二种方式

当注册和对方后,会同步对方的注册数据

多个如何注册?

例如有3个,地址分别为:

  1. 127.0.0.1:10001
  2. 127.0.0.1:10002
  3. 127.0.0.1:10003

注册时就把1注册给2,2注册给3,3注册给1,形成一个环状

服务提供者

启动springcloud-eureka-service-provider

服务提供者要向EurekaServer注册服务,并且完成服务续约等工作。

服务注册

服务提供者在启动时,会检测配置属性中的:eureka.client.register-with-eureka=true参数是否正确,事实上默认就是true。如果值确实为true,则会向EurekaServer发起一个Rest请求,并携带自己的元数据信息,Eureka Server会把这些信息保存到一个双层Map结构中。

  • 第一层Map的Key就是服务id,一般是配置中的spring.application.name属性

  • 第二层Map的key是服务的实例id。一般host+ serviceId + port,例如:locahost:service-provider:8081

  • 值则是服务的实例对象,也就是说一个服务,可以同时启动多个不同实例,形成集群。

    Map<serviceId,Map<服务实例名,实例对象(instance)>>

服务续约

在注册服务完成以后,服务提供者会维持一个心跳(定时向EurekaServer发起Rest请求),告诉EurekaServer:“我还活着”。这个我们称为服务的续约(renew);

有两个重要参数可以修改服务续约的行为:

eureka:
  instance:
    lease-renewal-interval-in-seconds: 30  #心跳时间
    lease-expiration-duration-in-seconds: 90 #过期时间
  • lease-renewal-interval-in-seconds:服务续约(renew)的间隔,默认为30秒
  • lease-expiration-duration-in-seconds:服务失效时间,默认值90秒

也就是说,默认情况下每隔30秒服务会向注册中心发送一次心跳,证明自己还活着。如果超过90秒没有发送心跳,EurekaServer就会认为该服务宕机,会从服务列表中移除,这两个值在生产环境不要修改,默认即可。

但是在开发时,这个值有点太长了,经常我们关掉一个服务,会发现Eureka依然认为服务在活着。所以我们在开发阶段可以适当调小。

eureka:
  client:
    register-with-eureka: true #默认为true,可以不写。服务提供方启动时,会检测该参数是否为true,true就注册给 
                             #eureka。
  instance:
    lease-renewal-interval-in-seconds: 5  #心跳时间
    lease-expiration-duration-in-seconds: 15 #过期时间

服务消费者

启动springcloud-eureka-service-customer

获取服务列表

当服务消费者启动时,会检测eureka.client.fetch-registry=true参数的值,如果为true,则会拉取Eureka Server服务的列表只读备份,然后缓存在本地(默认为true)。并且每隔30秒会重新获取并更新数据。我们可以通过下面的参数来修改:

eureka:
  client:
    fetch-registry: true
    registry-fetch-interval-seconds: 5

生产环境中,我们不需要修改这个值。

但是为了开发环境下,能够快速得到服务的最新状态,我们可以将其设置小一点。

失效剔除和自我保护

服务下线

当服务进行正常关闭操作时,它会触发一个服务下线的REST请求给Eureka Server,告诉服务注册中心:“我要下线了”。服务中心接受到请求之后,将该服务置为下线状态。具体的是:Eureka Client会通过PUT请求方式调用Eureka Server的REST访问节点/eureka/apps/{appID}/{instanceID}/status?value=DOWN请求地址,告知Eureka Server我要下线了,Eureka Server收到请求后会将该服务实例运行状态UP修改为DOWN,这样我们在管理平台服务列表内看到的就是DOWN状态的服务实例。

失效剔除

有些时候,我们的服务提供方并不一定会正常下线,可能因为内存溢出、网络故障、内存溢出杀死进程服务器宕机等非正常流程等原因导致服务无法正常工作。Eureka Server需要将这样的服务剔除出服务列表。因此它会开启一个定时任务,每隔60秒对所有失效的服务(超过90秒未响应的服务)进行剔除。

可以通过eureka.server.eviction-interval-timer-in-ms参数对其进行修改,单位是毫秒,生产环境不要修改。

这个会对我们开发带来极大的不变,你对服务重启,隔了60秒Eureka才反应过来。开发阶段可以适当调整,比如:10秒

eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka
  server:
    eviction-interval-timer-in-ms: 10000

自我保护

我们关停一个服务,就会在Eureka面板看到一条警告:

这是触发了Eureka的自我保护机制。当服务未按时进行心跳续约时,Eureka会统计服务实例最近15分钟心跳续约的
比例是否低于了85%。在生产环境下,因为网络延迟等原因,心跳失败实例的比例很有可能超标,但是此时就把服务剔除列表并不妥当,因为服务可能没有宕机。Eureka就会把当前实例的注册信息保护起来,不予剔除。生产环境下这很有效,保证了大多数服务依然可用。

但是这给我们的开发带来了麻烦, 因此开发阶段我们都会关闭自我保护模式:(springcloud-eureka-server)

eureka:
  server:
    enable-self-preservation: false # 关闭自我保护模式(缺省为打开)
    eviction-interval-timer-in-ms: 1000 # 扫描失效服务的间隔时间(缺省为60*1000ms)

负载均衡Ribbon

简介

在上节的案例中,我们启动了一个springcloud-service-provider,然后通过DiscoveryClient来获取服务实例信息,然后获取ip和端口来访问。

但是实际环境中,我们往往会开启很多个springcloud-service-provider的集群。此时我们获取的服务列表中就会有多个,到底该访问哪一个呢?

一般这种情况下我们就需要编写负载均衡算法,在多个实例列表中进行选择。

不过Eureka中已经帮我们集成了负载均衡组件:Ribbon,简单修改代码即可使用。

什么是Ribbon:

接下来,我们就来使用Ribbon实现负载均衡。

启动两个服务实例

首先参照springcloud-eureka-server启动两个springcloud-service-provider实例,一个8080,一个8081。

开启负载均衡

因为Eureka中已经集成了Ribbon,所以我们无需引入新的依赖,直接修改代码。

修改springcloud-service-consumer的引导类,在注册RestTemplate的配置方法上添加@LoadBalanced注解:

loadBalanced为负载均衡的意思

@SpringBootApplication
@EnableDiscoveryClient
public class SpringcloudEurekaServiceConsumerApplication {

    public static void main(String[] args) {
        SpringApplication.run(SpringcloudEurekaServiceConsumerApplication.class, args);
    }

    @Bean
    @LoadBalanced
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }

}

修改调用方式,不再手动获取ip和端口拼接字符串,而是直接通过服务名称调用:

以前的调用方法

@RequestMapping("consumer/user")
@RestController
public class UserController {
@Autowired private RestTemplate restTemplate;
@Autowired /** * eureka客户端,可以获取到eureka中服务的信息 */
private DiscoveryClient discoveryClient;@GetMapping("/{id}") public User queryUserById(@PathVariable("id")Long id){ List instances = discoveryClient.getInstances("service-provider"); ServiceInstance instance=instances.get(0); String hostName=instance.getHost(); Integer port=instance.getPort(); User user=restTemplate.getForObject("http://"+hostName+":"+port+"/user/"+id,User.class); return user; } }

使用负载均衡的调用方式:

@RequestMapping("consumer/user")
@RestController
public class UserController {

    @Autowired
    private RestTemplate restTemplate;


    @GetMapping("/{id}")
    public User queryUserById(@PathVariable("id")Long id){
        User user=restTemplate.getForObject("http://service-provider/user/"+id,User.class);
        return user;
    }
}

源码跟踪

为什么我们只输入了service名称就可以访问了呢?之前还要获取ip和端口。

显然有地方帮我们根据service名称,获取到了服务实例的ip和端口。

我们在调用接口的地方打上端点,一探究竟

以DEBUG的方法重新启动springcloud-service-consumer,然后访问http://localhost:8081/user/1

  1. 调用execute方法

        @Nullable
        public  T getForObject(String url, Class responseType, Object... uriVariables) throws RestClientException {
            RequestCallback requestCallback = this.acceptHeaderRequestCallback(responseType);
            HttpMessageConverterExtractor responseExtractor = new HttpMessageConverterExtractor(responseType, this.getMessageConverters(), this.logger);
            //调用execute方法,f7继续跟踪
            return this.execute(url, HttpMethod.GET, requestCallback, responseExtractor, (Object[])uriVariables);
        }Copy to clipboardErrorCopied
    
  2. 调用doExecute

        @Nullable
        public  T execute(String url, HttpMethod method, @Nullable RequestCallback requestCallback, @Nullable ResponseExtractor responseExtractor, Object... uriVariables) throws RestClientException {
            //将请求封装为URI
            URI expanded = this.getUriTemplateHandler().expand(url, uriVariables);
            //调用doExecute方法,f7继续跟踪
            return this.doExecute(expanded, method, requestCallback, responseExtractor);
        }
    
  3. request.execute,调用AbstractClientHttpRequest的execute方法

  1. 又调用AbstractBufferingClientHttpRequest的executeInternal方法
    public final ClientHttpResponse execute() throws IOException {
        this.assertNotExecuted();
        //f7进入
        ClientHttpResponse result = this.executeInternal(this.headers);
        this.executed = true;
        return result;
    }
  1. 调用InterceptingClientHttpRequest重写的executeInternal方法
    protected ClientHttpResponse executeInternal(HttpHeaders headers) throws IOException {
        byte[] bytes = this.bufferedOutput.toByteArray();
        if (headers.getContentLength() < 0L) {
            headers.setContentLength((long)bytes.length);
        }
        //f7进入
        ClientHttpResponse result = this.executeInternal(headers, bytes);
        this.bufferedOutput = new ByteArrayOutputStream(0);
        return result;
    }
  1. 创建请求拦截器执行对象
    protected final ClientHttpResponse executeInternal(HttpHeaders headers, byte[] bufferedOutput) throws IOException {
        //创建请求拦截器执行对象
        InterceptingClientHttpRequest.InterceptingRequestExecution requestExecution = new InterceptingClientHttpRequest.InterceptingRequestExecution();
        //调用执行方法
        return requestExecution.execute(this, bufferedOutput);
    }
  1. 调用请求拦截器的执行方法

在执行方法中获取拦截器,调用其intercept方法

  1. 负载均衡的执行方法,RibbonLoadBalancerClient.execute
public ClientHttpResponse intercept(final HttpRequest request, final byte[] body, final ClientHttpRequestExecution execution) throws IOException {
    URI originalUri = request.getURI();
    //获取服务名称
    String serviceName = originalUri.getHost();
    Assert.state(serviceName != null, "Request URI does not contain a valid hostname: " + originalUri);
    //调用负载均衡的执行方法
    return (ClientHttpResponse)this.loadBalancer.execute(serviceName, this.requestFactory.createRequest(request, body, execution));
}
  1. 在其中又调用RibbonLoadBalancerClient重载的execute方法
  public  T execute(String serviceId, LoadBalancerRequest request) throws IOException {
        return this.execute(serviceId, (LoadBalancerRequest)request, (Object)null);
    }

    public  T execute(String serviceId, LoadBalancerRequest request, Object hint) throws IOException {
        //获取负载均衡器实例,其中有当前请求服务的地址列表等服务信息
        ILoadBalancer loadBalancer = this.getLoadBalancer(serviceId);
        //根据负载均衡算法从服务列表中获取一个服务
        Server server = this.getServer(loadBalancer, hint);
        if (server == null) {
            throw new IllegalStateException("No instances available for " + serviceId);
        } else {
            RibbonLoadBalancerClient.RibbonServer ribbonServer = new RibbonLoadBalancerClient.RibbonServer(serviceId, server, this.isSecure(server, serviceId), this.serverIntrospector(serviceId).getMetadata(server));
            return this.execute(serviceId, (ServiceInstance)ribbonServer, (LoadBalancerRequest)request);
        }
    }
  1. 获取服务,调用了BaseLoadBalancer中的选择服务
    protected Server getServer(ILoadBalancer loadBalancer, Object hint) {
        //调用负载均衡实例的chooseServer方法,选择服务
        return loadBalancer == null ? null : loadBalancer.chooseServer(hint != null ? hint : "default");
    }
  1. 选择服务
public Server chooseServer(Object key) {
    if (this.counter == null) {
        this.counter = this.createCounter();
    }

    this.counter.increment();
    if (this.rule == null) {
        return null;
    } else {
        try {
            //根据当前的负载均衡规则选择,默认是RoundRobinRule(轮循),是IRule接口的实现
            return this.rule.choose(key);
        } catch (Exception var3) {
            logger.warn("LoadBalancer [{}]:  Error choosing server for key {}", new Object[]{this.name, key, var3});
            return null;
        }
    }
}

负载均衡策略

Ribbon默认的负载均衡策略是简单的轮询,我们可以测试一下:

编写测试类,在刚才的源码中我们看到拦截中是使用RibbonLoadBalancerClient来进行负载均衡的,其中有一个choose方法,找到choose方法的接口方法,是这样介绍的:

public interface ServiceInstanceChooser {

    /**
     * 根据服务名称从负载均衡器中选择一个服务实例返回
     * Chooses a ServiceInstance from the LoadBalancer for the specified service.
     * @param serviceId The service ID to look up the LoadBalancer.
     * @return A ServiceInstance that matches the serviceId.
     */
    ServiceInstance choose(String serviceId);

我们注入这个类的对象,然后对其测试:

创建测试方法

@RunWith(SpringRunner.class)
@SpringBootTest
public class SpringcloudEurekaServiceConsumerApplicationTests {

    @Autowired
    private RibbonLoadBalancerClient loadBalanceClient;

    @Test
    public void contextLoads() {
    }

    @Test
    public void testLoadBalance() {
        for (int i = 0; i < 50; i++) {
            ServiceInstance instance = loadBalanceClient.choose("service-provider");
            System.out.println(instance.getPort());
        }
    }

}

运行后明显可以看出,就是轮询

choose方法的执行过程

public ServiceInstance choose(String serviceId) {
    return this.choose(serviceId, (Object)null);
}
------------------------
public ServiceInstance choose(String serviceId, Object hint) {
    Server server = this.getServer(this.getLoadBalancer(serviceId), hint);
    return server == null ? null : new RibbonLoadBalancerClient.RibbonServer(serviceId, server, this.isSecure(server, serviceId), this.serverIntrospector(serviceId).getMetadata(server));
}
----------------------
protected Server getServer(ILoadBalancer loadBalancer, Object hint) {
    return loadBalancer == null ? null : loadBalancer.chooseServer(hint != null ? hint : "default");
}
---------------------
    public Server chooseServer(Object key) {
        if (this.counter == null) {
            this.counter = this.createCounter();
        }

        this.counter.increment();
        if (this.rule == null) {
            return null;
        } else {
            try {
                return this.rule.choose(key);
            } catch (Exception var3) {
                logger.warn("LoadBalancer [{}]:  Error choosing server for key {}", new Object[]{this.name, key, var3});
                return null;
            }
        }
    }

修改负载均衡策略

SpringBoot也帮我们提供了修改负载均衡规则的配置入口,在springcloud-eureka-service-consumer的application.yaml中添加如下配置:

service-provider:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

格式是:{服务名称}.ribbon.NFLoadBalancerRuleClassName,值就是IRule的实现类。

负载均衡规则(IRule)有图中几个实现

重试机制

Eureka的服务治理强调了CAP原则中的AP,即可用性和分区容错性。它与Zookeeper这一类强调CP(一致性,可靠性)的服务治理框架最大的区别在于:Eureka为了实现更高的服务可用性,牺牲了一定的一致性,极端情况下它宁愿接收故障实例也不愿丢掉健康实例,正如我们上面所说的自我保护机制。

但是,此时如果我们调用了这些不正常的服务,调用就会失败,从而导致其它服务不能正常工作!这显然不是我们愿意看到的。

我们现在关闭一个服务实例,关闭8084端口:

此时再次访问你会得到错误提示

但是此时,8081服务其实是正常的。

因此Spring Cloud 整合了Spring Retry 来增强RestTemplate的重试能力,当一次服务调用失败后,不会立即抛出一次,而是再次重试另一个服务。

只需要简单配置即可实现Ribbon的重试:

但是此时,8081服务其实是正常的。

因此Spring Cloud 整合了Spring Retry 来增强RestTemplate的重试能力,当一次服务调用失败后,不会立即抛出一次,而是再次重试另一个服务。

只需要简单配置即可实现Ribbon的重试:

添加spring-retry依赖


    org.springframework.retry
    spring-retry

server:
  port: 8083
spring:
  application:
    name: service-consumer
  cloud:
    loadbalancer:
      retry:
        enabled: true #开启Spring Cloud的重试功能,默认就是true
eureka:
  client:
    service-url:
      defaultZone: http://localhost:10086/eureka
    fetch-registry: true
    registry-fetch-interval-seconds: 5

Hystrix

简介

Hystrix,英文意思是豪猪,全身是刺,看起来就不好惹,是一种保护机制。

Hystrix也是Netflix公司的一款组件。

那么Hystix的作用是什么呢?具体要保护什么呢?

Hystix是Netflix开源的一个延迟和容错库,用于隔离访问远程服务、第三方库,防止出现级联失败。

雪崩问题

微服务中,服务间调用关系错综复杂,一个请求,可能需要调用多个微服务接口才能实现,会形成非常复杂的调用链路:

如图,一次业务请求,需要调用A、P、H、I四个服务,这四个服务又可能调用其它服务。

如果此时,某个服务出现异常:

例如微服务I发生异常,请求阻塞,用户不会得到响应,则tomcat的这个线程不会释放,于是越来越多的用户请求到来,越来越多的线程会阻塞:

服务器支持的线程和并发数有限,请求一直阻塞,会导致服务器资源耗尽,从而导致所有其它服务都不可用,形成雪崩效应。

这就好比,一个汽车生产线,生产不同的汽车,需要使用不同的零件,如果某个零件因为种种原因无法使用,那么就会造成整台车无法装配,陷入等待零件的状态,直到零件到位,才能继续组装。 此时如果有很多个车型都需要这个零件,那么整个工厂都将陷入等待的状态,导致所有生产都陷入瘫痪。一个零件的波及范围不断扩大。

Hystix解决雪崩问题的手段有两个:

  • 线程隔离
  • 服务熔断

线程隔离,服务降级

原理

线程隔离示意图

解读:

Hystrix为每个依赖服务调用分配一个小的线程池,如果线程池已满调用将被立即拒绝,默认不采用排队.加速失败判定时间。

用户的请求将不再直接访问服务,而是通过线程池中的空闲线程来访问服务,如果线程池已满,或者请求超时,则会进行降级处理,什么是服务降级?

服务降级:优先保证核心服务,而非核心服务不可用或弱可用。

用户的请求故障时,不会被阻塞,更不会无休止的等待或者看到系统崩溃,至少可以看到一个执行结果(例如返回友好的提示信息) 。

服务降级虽然会导致请求失败,但是不会导致阻塞,而且最多会影响这个依赖服务对应的线程池中的资源,对其它服务没有响应。

触发Hystix服务降级的情况:

  • 线程池已满
  • 请求超时

引入依赖

虽然Eureka已经集成了Hystrix,但是还缺少一些依赖,还是要手动添加hystrix的场景依赖

首先在springcloud-service-consumer的pom.xml中引入Hystrix依赖:


    org.springframework.cloud
    spring-cloud-starter-netflix-hystrix

开启熔断(@EnableCircuitBreaker)

在启动类上添加@EnableCircuitBreaker注解,表示开启熔断

@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public class SpringcloudServiceConsumerApplication {

    @Bean
    @LoadBalanced
    public RestTemplate restTemplate(){
        return new RestTemplate();
    }

    public static void main(String[] args) {
        SpringApplication.run(SpringcloudServiceConsumerApplication.class, args);
    }
}

@SpringCloudApplication

可以看到,我们类上的注解越来越多,在微服务中,经常会引入上面的三个注解,于是Spring就提供了一个组合注解:@SpringCloudApplication

@SpringCloudApplication
public class SpringcloudEurekaServiceConsumerApplication Copy to clipboardErrorCopied

编写降级逻辑

我们改造springcloud-eureka-service-consumer,当目标服务的调用出现故障,我们希望快速失败,给用户一个友好提示。因此需要提前编写好失败时的降级处理逻辑,要使用HystixCommond来完成:

@RequestMapping("consumer/user")
@RestController
public class UserController {

    @Autowired
    private RestTemplate restTemplate;

    @Autowired
    /**
     * eureka客户端,可以获取到eureka中服务的信息
     */
    private DiscoveryClient discoveryClient;

    @GetMapping("/{id}")
    @HystrixCommand(fallbackMethod = "queryUserByIdFallback")
    public String queryUserById(@PathVariable("id")Long id){
        String user=restTemplate.getForObject("http://service-provider/user/"+id,String.class);
        return user;
    }

    public String queryUserByIdFallback(Long id){
        return "服务正忙,请稍后再试";
    }
}

@HystrixCommand(fallbackMethod = "queryUserByIdFallback"):用来声明一个降级逻辑的方法

要注意,因为熔断的降级逻辑方法必须跟正常逻辑方法保证:相同的参数列表和返回值声明。失败逻辑中返回实体类对象没有太大意义,一般会返回友好提示。所以我们把queryUserById的方法改造为返回String,反正也是Json数据。这样失败逻辑中返回一个错误说明,会比较方便。

然后重启springcloud-service-consumer,访问http://localhost/consumer/user/1

这是正常情况所以和以前一样返回请求的数据

接下来把两个服务提供应用都关闭,再重新访问

会发现页面返回了降级处理信息:

默认FallBack

我们刚才把fallback写在了某个业务方法上,如果这样的方法很多,那岂不是要写很多。所以我们可以把Fallback配置加在类上,实现默认fallback

@RequestMapping("consumer/user")
@RestController
@DefaultProperties(defaultFallback = "defaultFallback")
public class UserController {

    @Autowired
    private RestTemplate restTemplate;

    @Autowired
    /**
     * eureka客户端,可以获取到eureka中服务的信息
     */
    private DiscoveryClient discoveryClient;

    @GetMapping("/{id}")
    @HystrixCommand
    public String queryUserById(@PathVariable("id")Long id){
        String user=restTemplate.getForObject("http://service-provider/user/"+id,String.class);
        return user;
    }

    public String defaultFallback(){
        return "服务正忙,请稍后再试";
    }
}
  • @DefaultProperties(defaultFallback = "defaultFallBack"):在类上指明统一的失败降级方法
  • @HystrixCommand:在方法上直接使用该注解,使用默认的降级方法。
  • defaultFallback():默认降级方法,不能有任何参数,且返回值一定要一致,以匹配更多方法

设置超时

在之前的案例中,请求在超过1秒后都会返回错误信息,这是因为Hystix的默认超时时长为1,我们可以通过配置修改这个值:

hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 6000 # 设置hystrix的超时时间为6000ms(6秒)

这里我们修改服务提供方,模拟网络延迟,在服务提供方睡眠8秒,启动

@RestController
@RequestMapping("user")
public class UserController {

    @Autowired
    private IUserService userService;

    @GetMapping("/{id}")
    public TbUser queryUserById(@PathVariable Long id) {
        try {
            Thread.sleep(8000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return userService.queryById(id);
    }
}

重启springcloud-eureka-service-consumer

再访问:

这次就不是立马返回结果了,而是6秒之后

服务熔断

熔断原理

熔断器,也叫断路器,其英文单词为:Circuit Breaker

熔断状态机3个状态:

  • Closed:关闭状态,所有请求都正常访问。
  • Open:打开状态,所有请求都会被降级。Hystix会对请求情况计数,当一定时间内失败请求百分比达到阈值,则触发熔断,断路器会完全打开。默认失败比例的阈值是50%,请求次数最少不低于20次。
  • Half Open:半开状态,open状态不是永久的,打开后会进入休眠时间(默认是5S)。随后断路器会自动进入半开状态。此时会释放部分请求通过,若这些请求都是健康的,则会完全关闭断路器,否则继续保持打开,再次进行休眠计时

动手实践

为了能够精确控制请求的成功或失败,我们在consumer的调用业务中加入一段逻辑:

@RequestMapping("consumer/user")
@RestController
@DefaultProperties(defaultFallback = "defaultFallback")
public class UserController {

    @Autowired
    private RestTemplate restTemplate;

    @Autowired
    /**
     * eureka客户端,可以获取到eureka中服务的信息
     */
    private DiscoveryClient discoveryClient;

    @GetMapping("/{id}")
    @HystrixCommand
    public String queryUserById(@PathVariable("id")Long id){
        if(id==1){
          throw new RuntimeException();
        }
        String user=restTemplate.getForObject("http://service-provider/user/"+id,String.class);
        return user;
    }

    public String defaultFallback(){
        return "服务正忙,请稍后再试";
    }
}

这样如果参数是id为1,一定失败,其它情况都成功。

不要忘了删掉service-provider中的休眠逻辑

接下来

  1. 请求http://localhost/consumer/user/2,一切正常
  2. 然后慢悠悠的请求,http://localhost/consumer/user/1,20次,慢一点
  3. 然后再访问2,还是正常
  4. 接下来,疯狂请求http://localhost/consumer/user/2,20次,快,一定要快
  5. 接着再访问2,咦!发现2也无法访问,也被降级了
  6. 然后,数5秒后再访问1后再访问2,依旧无法访问
  7. 最后再数5秒后访问2,就可以访问了,结合熔断状态机3个状态想想,应该知道是怎么回事了吧

修改熔断策略

我们可以注解修改熔断策略:

@RequestMapping("consumer/user")
@RestController
@DefaultProperties(defaultFallback = "defaultFallback",
                    commandProperties = {
                            @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "5"),
                            @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds", value = "10000"),
                            @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "50")
                    })
public class UserController {

    @Autowired
    private RestTemplate restTemplate;

    @Autowired
    /**
     * eureka客户端,可以获取到eureka中服务的信息
     */
    private DiscoveryClient discoveryClient;

    @GetMapping("/{id}")
    @HystrixCommand
    public String queryUserById(@PathVariable("id")Long id){
        if(id==1){
          throw new RuntimeException();
        }
        String user=restTemplate.getForObject("http://service-provider/user/"+id,String.class);
        return user;
    }

    public String defaultFallback(){
        return "服务正忙,请稍后再试";
    }
}
  • requestVolumeThreshold:触发熔断的最小请求次数,默认20
  • sleepWindowInMilliseconds:休眠时长,默认是5000毫秒
  • errorThresholdPercentage:触发熔断的失败请求最小占比,默认50%

Feign

在前面的学习中,我们使用了Ribbon的负载均衡功能,大大简化了远程调用时的代码:

    @GetMapping("/{id}")
    @HystrixCommand
    public String queryUserById(@PathVariable("id")Long id){
        String user=restTemplate.getForObject("http://service-provider/user/"+id,String.class);
        return user;
    }

如果就学到这里,你可能以后需要编写类似的大量重复代码,格式基本相同,无非参数不一样。有没有更优雅的方式,来对这些代码再次优化呢?

这就是我们接下来要学的Feign的功能了。

简介

为什么叫伪装?

Feign可以把Rest的请求进行隐藏,伪装成类似SpringMVC的Controller一样。你不用再自己拼接url,拼接参数等等操作,一切都交给Feign去做。

导入依赖


    org.springframework.cloud
    spring-cloud-starter-openfeign

@EnableFeignClients

我们在启动类上,添加@EnableFeignClients注解,开启Feign功能,也不需要我们向容器中注入Resttemplate

@SpringCloudApplication
@EnableFeignClients
public class SpringcloudEurekaServiceConsumerApplication {

    public static void main(String[] args) {
        SpringApplication.run(SpringcloudEurekaServiceConsumerApplication.class, args);
    }

//    @Bean
//    @LoadBalanced
//    public RestTemplate restTemplate() {
//        return new RestTemplate();
//    }

}

feign已经自动集成了Ribbon负载均衡的RestTemplate。所以,不需要我们再注册RestTemplate。

Feign的客户端

添加UserClient接口,一般这种接口都放在client包下

@FeignClient(value="service-provider",
             fallback = UserClientFallBack.class,
             configuration = FeignConfiguration.class)
public interface UserClient {

    @GetMapping("user/{id}")
    public String queryUserById(@PathVariable Long id);

}
  • 首先这是一个接口,Feign会通过动态代理,帮我们生成实现类。这点跟mybatis的mapper很像

  • @FeignClient,声明这是一个Feign客户端,类似@Mapper注解。同时通过value属性指定服务名称

  • 接口中的定义方法,完全采用SpringMVC的注解,Feign会根据注解帮我们生成URL,并访问获取结果

  • 接口的方法名随意,但是注解上的请求路径,方法参数要和服务方的相同,返回值可以换成String

  • 注意:尽量不要用@RequestMapping("user")注解,而是拼接到GetMapping上,有时候会出错

负载均衡

Feign中本身已经集成了Ribbon依赖和自动配置:

因此我们不需要额外引入依赖,也不需要再注册RestTemplate对象。

Feign、Hystrix、Eureka都集成了Ribbon,版本有springcloud管理,所以不用我们去管理依赖

Hystrix支持

Feign默认也有对Hystrix的集成:

只不过,默认情况下是关闭的。我们需要通过下面的参数来开启:(在配置添加如下内容)

feign:
  hystrix:
    enabled: true # 开启Feign的熔断功能

但是,Feign中的Fallback配置不像hystrix中那样简单了。

首先,我们要定义一个类去实现刚才编写的UserClient接口,作为fallback的处理类。并将该类添加到容器中

@Component
public class UserClientFallBack implements UserClient {
    @Override
    public String queryUserById(Long id) {
        return "服务器正繁忙,请稍后再试";
    }
}

然后在UserClient接口的@FeignClient注解中,指定刚才编写的实现类

@FeignClient(value="service-provider",
             fallback = UserClientFallBack.class,
             configuration = FeignConfiguration.class)
public interface UserClient {

    @GetMapping("user/{id}")
    public String queryUserById(@PathVariable Long id);

}

请求压缩

Spring Cloud Feign 支持对请求和响应进行GZIP压缩,以减少通信过程中的性能损耗。通过下面的参数即可开启请求与响应的压缩功能:

feign:
  compression:
    request:
      enabled: true # 开启请求压缩
    response:
      enabled: true # 开启响应压缩Copy to clipboardErrorCopied

同时,我们也可以对请求的数据类型,以及触发压缩的大小下限进行设置:

feign:
  compression:
    request:
      enabled: true # 开启请求压缩
      mime-types: text/html,application/xml,application/json # 设置压缩的数据类型
      min-request-size: 2048 # 设置触发压缩的大小下限Copy to clipboardErrorCopied

注:上面的数据类型、压缩大小下限均为默认值。

日志级别

springboot可以通过logging.level.xx=debug来设置日志级别。然而这个对Fegin客户端而言不会产生效果。因为@FeignClient注解修改的客户端在被代理时,都会创建一个新的Fegin.Logger实例。我们需要额外指定这个日志的级别才可以。

  1. 设置cn.clboy.springcloud.eureka.service.consumer包下的日志级别都为debug

    logging:
      level:
        top.codekiller.service: debug
    
  2. 编写配置类,定义日志级别

    @Configuration
    public class FeignLogConfiguration {
    
        @Bean
        Logger.Level feignLoggerLevel(){
            return Logger.Level.FULL;
        }
    }
    

这里指定的Level级别是FULL,Feign支持4种级别:

public static enum Level {
        NONE,
        BASIC,
        HEADERS,
        FULL;

        private Level() {
        }
    }
  • NONE:不记录任何日志信息,这是默认值。
  • BASIC:仅记录请求的方法,URL以及响应状态码和执行时间
  • HEADERS:在BASIC的基础上,额外记录了请求和响应的头信息
  • FULL:记录所有请求和响应的明细,包括头信息、请求体、元数据。
  1. 在FeignClient中指定配置类:

    @FeignClient(value="service-provider",
                 fallback = UserClientFallBack.class,
                 configuration = FeignConfiguration.class)
    public interface UserClient {
    
        @GetMapping("user/{id}")
        public String queryUserById(@PathVariable Long id);
    
    }
    
  1. 重启项目,即可看到每次访问的日志:

Zuul网关

通过前面的学习,使用Spring Cloud实现微服务的架构基本成型,大致是这样的:

我们使用Spring Cloud Netflix中的Eureka实现了服务注册中心以及服务注册与发现;

而服务间通过RibbonFeign实现服务的消费以及均衡负载。

为了使得服务集群更为健壮,使用Hystrix的融断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。

在该架构中,我们的服务集群包含:内部服务Service A和Service B,他们都会注册与订阅服务至Eureka Server,而Open Service是一个对外的服务,通过均衡负载公开至服务调用方。我们把焦点聚集在对外服务这块,直接暴露我们的服务地址,这样的实现是否合理,或者是否有更好的实现方式呢?

先来说说这样架构需要做的一些事儿以及存在的不足:

  • 破坏了服务无状态特点。

    为了保证对外服务的安全性,我们需要实现对服务访问的权限控制,而开放服务的权限控制机制将会贯穿并污染整个开放服务的业务逻辑,这会带来的最直接问题是,破坏了服务集群中REST API无状态的特点。

    从具体开发和测试的角度来说,在工作中除了要考虑实际的业务逻辑之外,还需要额外考虑对接口访问的控制处理

  • 无法直接复用既有接口。

    当我们需要对一个即有的集群内访问接口,实现外部服务访问时,我们不得不通过在原有接口上增加校验逻辑,或增加一个代理调用来实现权限控制,无法直接复用原有的接口。

面对类似上面的问题,我们要如何解决呢?答案是:服务网关!

为了解决上面这些问题,我们需要将权限控制这样的东西从我们的服务单元中抽离出去,而最适合这些逻辑的地方就是处于对外访问最前端的地方,我们需要一个更强大一些的均衡负载器的 服务网关。

服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中,除了具备服务路由均衡负载功能之外,它还具备了权限控制等功能。Spring Cloud Netflix中的Zuul就担任了这样的一个角色,为微服务架构提供了前门保护的作用,同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面,使得服务集群主体能够具备更高的可复用性和可测试性。

简介

Zuul:维基百科

电影《捉鬼敢死队》中的怪兽,Zuul,在纽约引发了巨大骚乱。

事实上,在微服务架构中,Zuul就是守门的大Boss!一夫当关,万夫莫开!

Zuul后的架构

不管是来自于客户端(PC或移动端)的请求,还是服务内部调用。一切对服务的请求都会经过Zuul这个网关,然后再由网关来实现 鉴权、动态路由等等操作。Zuul就是我们服务的统一入口。

快速入门

添加Zuul依赖

编写配置

server:
  port: 10010

spring:
  application:
    name: service-zuul

@EnableZuulProxy

通过@EnableZuulProxy注解开启Zuul的功能:

@SpringBootApplication
@EnableZuulProxy
public class SpringcloudZuulApplication {

    public static void main(String[] args) {
        SpringApplication.run(SpringcloudZuulApplication.class, args);
    }

}

编写路由规则

server:
  port: 10010 #服务端口
spring:
  application:
    name: service-zuul #指定服务名
zuul:
  routes:
    service-provider: #这里是路由id,随意写(一般为服务名)
      path: /service-provider/** # 这里是映射路径
      url: http://localhost:8081 # 映射路径对应的实际url地址

我们将符合path 规则的一切请求,都代理到 url参数指定的地址

面向服务的路由

在刚才的路由规则中,我们把路径对应的服务地址写死了!如果同一服务有多个实例的话,这样做显然就不合理了。我们应该根据服务的名称,去Eureka注册中心查找 服务对应的所有实例列表,然后进行动态路由才对!

springcloud-zuul工程修改优化:

添加Eureka依赖


    org.springframework.cloud
    spring-cloud-starter-netflix-eureka-client

添加Eureka的配置

eureka:
  client:
    service-url:
      defaultZone: http://localhost:10086/eureka
    registry-fetch-interval-seconds: 5

开启Eureka客户端

@SpringBootApplication
@EnableZuulProxy
@EnableDiscoveryClient
public class SpringcloudZuulApplication {

    public static void main(String[] args) {
        SpringApplication.run(SpringcloudZuulApplication.class, args);
    }
}

修改映射配置,通过服务名获取

因为已经有了Eureka客户端,我们可以从Eureka获取服务的地址信息,因此映射时无需指定IP地址,而是通过服务名称来访问,而且Zuul已经集成了Ribbon的负载均衡功能。

server:
  port: 10010

spring:
  application:
    name: service-zuul

eureka:
  client:
    service-url:
      defaultZone: http://localhost:10086/eureka
    registry-fetch-interval-seconds: 5

zuul:
  routes:
    service-provider: 
      path: /service-provider/**
#      url: http://localhost:8081
      serviceId: service-provider

简化的路由配置

在刚才的配置中,我们的规则是这样的:

  • zuul.routes..path=/xxx/**: 来指定映射路径。``是自定义的路由名
  • zuul.routes..serviceId=service-provider:来指定服务名。

而大多数情况下,我们的`路由名称往往和服务名会写成一样的。因此Zuul就提供了一种简化的配置语法:zuul.routes.=`

比方说上面我们关于service-provider的配置可以简化为一条:

server:
  port: 10010

spring:
  application:
    name: service-zuul

eureka:
  client:
    service-url:
      defaultZone: http://localhost:10086/eureka
    registry-fetch-interval-seconds: 5

zuul:
  routes:
    service-provider: /service-provider/** #路由名称,习惯上服务名
#      path: /service-provider/**
#      url: http://localhost:8081
#      serviceId: service-provider

默认的路由配置

在使用Zuul的过程中,上面讲述的规则已经大大的简化了配置项。但是当服务较多时,配置也是比较繁琐的。因此Zuul就指定了默认的路由规则:

  • 默认情况下,一切服务的映射路径就是服务名本身。例如服务名为:service-provider,则默认的映射路径就是:/service-provider/**

也就是说,刚才的映射规则我们完全不配置也是OK的,不信就试试看。

server:
  port: 10010

spring:
  application:
    name: service-zuul

eureka:
  client:
    service-url:
      defaultZone: http://localhost:10086/eureka
    registry-fetch-interval-seconds: 5

注意:尽量使用第三种方式。并且注意url的拼接,比如:/service-provider/**,如果请求路径是/service-provider/user/2,那么/user/2就会去匹配服务提供商的路径。

路由前缀

用来区分哪些服务是经过路由的

server:
  port: 10010

spring:
  application:
    name: service-zuul

eureka:
  client:
    service-url:
      defaultZone: http://localhost:10086/eureka
    registry-fetch-interval-seconds: 5

zuul:
  routes:
    service-provider: /service-provider/** #路由名称,习惯上服务名
  prefix: /api
#      path: /service-provider/**
#      url: http://localhost:8081
#      serviceId: service-provider

我们通过zuul.prefix=/api来指定了路由的前缀,这样在发起请求时,路径就要以/api开头。

过滤器

Zuul作为网关的其中一个重要功能,就是实现请求的鉴权。而这个动作我们往往是通过Zuul提供的过滤器来实现的。

ZuulFilter

ZuulFilter是过滤器的顶级父类。在这里我们看一下其中定义的4个最重要的方法:

public abstract ZuulFilter implements IZuulFilter{

    abstract public String filterType();

    abstract public int filterOrder();

    boolean shouldFilter();// 来自IZuulFilter

    Object run() throws ZuulException;// IZuulFilter
}
  • shouldFilter:返回一个Boolean值,判断该过滤器是否需要执行。返回true执行,返回false不执行。

  • run:过滤器的具体业务逻辑。

  • filterType:返回字符串,代表过滤器的类型。包含以下4种:

    • pre:请求在被路由之前执行
    • route:在路由请求时调用
    • post:在route和errror过滤器之后调用
    • error:处理请求时发生错误调用
  • filterOrder:通过返回的int值来定义过滤器的执行顺序,数字越小优先级越高。

过滤器的生命周期

这张是Zuul官网提供的请求生命周期图,清晰的表现了一个请求在各个过滤器的执行顺序。

正常流程:

请求到达首先会经过pre类型过滤器,而后到达route类型,进行路由,请求就到达真正的服务提供者,执行请求,返回结果后,会到达post过滤器。而后返回响应。
异常流程:

整个过程中,pre或者route过滤器出现异常,都会直接进入error过滤器,在error处理完毕后,会将请求交给POST过滤器,最后返回给用户。
如果是error过滤器自己出现异常,最终也会进入POST过滤器,将最终结果返回给请求客户端。
如果是POST过滤器出现异常,会跳转到error过滤器,但是与pre和route不同的是,请求不会再到达POST过滤器了。
所有内置过滤器列表:

使用场景

场景非常多:

  • 请求鉴权:一般放在pre类型,如果发现没有访问权限,直接就拦截了
  • 异常处理:一般会在error类型和post类型过滤器中结合来处理。
  • 服务调用时长统计:pre和post结合使用。

自定义过滤器

接下来我们来自定义一个过滤器,模拟一个登录的校验。基本逻辑:如果请求中有token参数,则认为请求有效,放行。

定义过滤器类

需要添加到spring容器中
```java
package top.codekiller.service.filter;

import com.netflix.zuul.ZuulFilter;
import com.netflix.zuul.context.RequestContext;
import com.netflix.zuul.exception.ZuulException;
import org.apache.commons.lang.StringUtils;
import org.springframework.context.annotation.FilterType;
import org.springframework.http.HttpStatus;
import org.springframework.stereotype.Component;
import javax.servlet.http.HttpServletRequest;

@Component
public class LoginFilter extends ZuulFilter {
/**

 * 过滤器的类型:pre,route,post,error
 * @return
 */
@Override
public String filterType() {
    return "pre";
}

/**
 * 执行顺序,返回值越小,优先级越高
 * @return
 */
@Override
public int filterOrder() {
    return 10;
}

/**
 * 是否执行该过滤器的run方法
 * @return
 */
@Override
public boolean shouldFilter() {
    return true;
}

/**
 * 过滤器的业务逻辑
 * @return
 * @throws ZuulException
 */
@Override
public Object run() throws ZuulException {
    //获取参数
    RequestContext context=RequestContext.getCurrentContext();

    //获取request对象
    HttpServletRequest request=context.getRequest();

    //获取参数
    String token=request.getParameter("token");
    //如果为空则进行拦截
    if(StringUtils.isBlank(token)){
        //拦截,不转发请求
        context.setSendZuulResponse(false);
        //响应状态码,401-身份未认证
        context.setResponseStatusCode(HttpStatus.UNAUTHORIZED.value());
        //设置响应提示
        context.setResponseBody("request error!");
    }
    //返回值null,仅代表该过滤器什么都不做
    return null;
}

}




### 负载均衡和熔断

Zuul中默认就已经集成了Ribbon负载均衡和Hystix熔断机制。但是所有的超时策略都是走的默认值,比如熔断超时时间只有1S,很容易就触发了。因此建议我们手动进行配置:

```yaml
hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 2000 # 设置hystrix的超时时间2秒

文章作者: 迷雾总会解
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 迷雾总会解 !
评论
  目录