title: 微服务总结
date: 2020/02/20 10:33
author: yujx
前言：系统架构演变
注：微服务架构之前都是前后端未分离的时代。
单体应用架构
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。
比如说一个电商系统，里面会包含很多用户管理，商品管理，订单管理，物流管理等等很多模块，我们会把它们做成一个web项目，然后部署到一台tomcat服务器上。
image
优点：
- 项目架构简单，小型项目的话，开发成本低
- 项目部署在一个Tomcat上，易于部署
缺点：
- 全部功能集成在一个工程中，对于大型项目来讲不易开发和维护
- 项目模块之间紧密耦合，单点容错率低，并发能力差（一个功能挂掉，其它全部歇菜。单个Tomcat的并发有限制）
- 无法针对不同模块进行针对性优化和水平扩展
垂直应用架构
当访问量逐渐增大，单一应用无法满足需求，单一应用只能依靠增加节点来应对，但是这时候会发现并不是所有的模块都会有比较大的访问量。
还是以上面的电商为例子，用户访问量的增加可能影响的只是用户和订单模块，但是对消息模块的影响就比较小. 那么此时我们希望只多增加几个订单模块，而不增加消息模块。此时单体应用就做不到了，垂直应用就应运而生了。
垂直应用架构，就是将原来的一个应用拆成互不相干的几个应用，以提升效率。
比如我们可 以将上面电商的单体应用拆分成:
- 电商系统（商品管理、订单管理）
- 后台系统（用户管理、订单管理、客户管理）
- CMS系统（广告管理、营销管理）
这样拆分完毕之后，一旦用户访问量变大，只需要增加电商系统的节点就可以了，而无需增加后台和CMS的节点。
image
优点：
- 系统拆分实现了流量分担，解决了并发问题
- 可以针对不同模块进行优化和水平扩展（集群）
- 一个系统的问题不会影响到其他系统，提高容错率
缺点：系统间相互独立，无法互相调用，从而导致会有很多重复开发工作
分布式架构
当垂直应用越来越多，重复的业务代码就会越来越多。这时候，我们就思考可不可以将重复的代码抽取出来，做成统一的业务层作为独立的服务，然后由前端控制层调用不同的业务层服务呢?
这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分，服务层中包含业务 逻辑。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。
image
优点：抽取公共的功能为服务层，提高代码复用性
缺点：系统间耦合度变高，调用关系错综复杂，难以维护
注：由于当时前后端还未分离，所以一定要有一个web层进行前端代码的书写。（我认为的，不一定对）
SOA架构（面向服务架构）
在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心对集群进行实时管理。此时，用于资源调度和治理中心是关键。
注1：资源就是指的我们的服务。
注2：面向服务架构引出了一个概念 —— 服务治理（SOA governance）
SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、Web Service技术之后的自然延伸。
服务治理，也称为SOA治理，是指用来管理SOA的采用和实现的过程。以下是在2006年时IBM对于服务治理要点的总结：
- 服务定义（服务的范围、接口和边界）
- 服务部署生命周期（各个生命周期阶段）
- 服务版本治理（包括兼容性）
- 服务迁移（启用和退役）
- 服务注册中心（依赖关系）
- 服务消息模型（规范数据模型）
- 服务监视（进行问题确定）
- 服务所有权（企业组织）
- 服务测试（重复测试）
- 服务安全（包括可接受的保护范围）
限于当时的技术发展水平，广大软件设计与开发人员对于SOA和服务治理的技术认知还主要停留在Web Service和ESB总线等技术和规范上，并没有真正在软件开发中得以充分落地。
实现方式1
中心化：服务之间互相调用通过ESB实现，这样的缺点，网上写了很多，这里不赘述了。
实现方式2，通过注册中心
去中心化：服务注册到注册中心，当调用时，服务调用时，调用方通过注册中心获取要调用的地址，进行调用（当然，还可以客户端缓存下来）
优点：使用注册中心\ESB解决了服务间调用关系的自动调节
缺点：
- 服务间会有依赖关系，一旦某个环节出错会影响较大（服务雪崩）
- 服务关系复杂，运维、测试部署困难
微服务
微服务是由以单一应用程序构成的小服务，自己拥有自己的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通信。同时服务会使用最小的规模的集中管理 (例如 Docker) 能力，服务可以用不同的编程语言与数据库等组件实现。（微服务使用不同的数据库） —— WIKI
微服务实际上是SOA的一个子集，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
微服务的特点：
- 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责
- 微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五脏俱全”。
- 面向服务：面向服务是说每个服务都要对外暴露服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供Rest的接口即可。
- 自治：自治是说服务间互相独立，互不干扰
- 团队独立：每个服务都是一个独立的开发团队，人数不能过多。
- 技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉
- 前后端分离：采用前后端分离开发，提供统一Rest接口，后端不用再为PC、移动段开发不同接口
- 数据库分离：每个服务都使用自己的数据源
- 部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护
微服务的设计原则
image
Spring Cloud架构格式
微服务架构的常见问题：
- 这么多小服务，如何管理他们？（服务注册与发现 -> 注册中心[服务注册 发现 剔除]）
- 这么多小服务，他们之间如何通讯？（rest\rpc）
- 这么多小服务，客户端怎么访问他们?（服务网关）
- 这么多小服务，一旦出现问题了，应该如何自处理？（服务容错）
- 这么多小服务，一旦出现问题了，应该如何排错？（链路追踪）
image
image
总结
系统架构实际上是由于现有架构满足不了需求从而对原有架构进行演变过来的，所以在选择的时候一定要选择适合的。
微服务架构是SOA架构的子集，只不过微服务定义了服务划分的粒度、通信方式。
一、微服务架构常见概念
1.1 服务注册与发现
一般会通过注册中心来实现服务的注册与发现，服务注册中心一般有下面3个功能：
- 服务注册：服务实例将自身服务信息注册到注册中心。
- 服务发现：服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。
- 服务剔除：服务注册中心将出问题的服务自动剔除到可用列表之外，使其不会被调用到。
image
1.2 服务调用
在微服务架构中，通常存在多个服务之间的远程调用的需求。目前主流的远程调用技术有基于
HTTP的RESTful接口以及基于TCP的RPC协议。
REST：这是一种HTTP调用的格式，更标准，更通用，无论哪种语言都支持http协议
RPC：一种进程间通信方式。允许像调用本地服务一样调用远程服务。RPC框架的主要目标就是让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式、序列化方式和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。
区别：
| REST | RPC | |
|---|---|---|
| 通讯协议 | HTTP | 一般使用TCP |
| 性能 | 略低 | 较高 |
| 灵活度 | 高 | 低 |
| 应用 | 一般应用于微服务架构 | 一般应用于SOA架构 |
1.3 服务网关
随着微服务的不断增多，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信可能出现:
- 客户端需要调用不同的url地址，增加难度
- 在一定的场景下，存在跨域请求的问题
- 每个微服务都需要进行单独的身份认证
针对这些问题，API网关顺势而生。
API网关直面意思是将所有API调用统一接入到API网关层，由网关层统一接入和输出。一个网关的基本功能有：统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。有了网关之后，各个API服务提供团队可以专注于自己的的业务逻辑处理，而API网关更专注于安全、流量、路由等问题。
image
1.4 服务容错
在微服务当中，一个请求经常会涉及到调用几个服务，如果其中某个服务不可用，没有做服务容错的话，极有可能会造成一连串的服务不可用，这就是雪崩效应。
我们没法预防雪崩效应的发生，只能尽可能去做好容错。服务容错的三个核心思想是:
- 不被外界环境影响（观察服务的外界环境，例如服务器CPU、内存，保证外界环境是良好的，不会影响应用内部）
- 不被上游请求压垮
- 不被下游响应拖垮
image
1.5 链路追踪
随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。互联 网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程 语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要对一次请求涉及的多个服务链路进行日志记录，性能监控即链路追踪。
二、微服务架构的常见解决方案
2.1 ServiceComb
Apache ServiceComb，前身是华为云的微服务引擎 CSE (Cloud Service Engine) 云服务，是全球首个Apache微服务顶级项目。它提供了一站式的微服务开源解决方案，致力于帮助企业、用户和开发者将企业应用轻松微服务化上云，并实现对微服务应用的高效运维管理。
2.2 SpringCloud
Spring Cloud是一系列框架的集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基 础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用 Spring Boot的开发风格做到一键启动和部署。
Spring Cloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服 务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留 出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
SpringCloud现有实现
注：上面的组件都是可以任意组合的。
其中SpringCloud Netflix已经停止开发，所以我们只能使用SpringCloud Alibaba了。
2.2.1 SpringCloud Alibaba
Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。
依托 Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。
主要功能
服务限流降级：默认支持 WebServlet、WebFlux, OpenFeign、RestTemplate、Spring Cloud Gateway, Zuul, Dubbo 和 RocketMQ限流降级功能的接入，可以在运行时通过控制台实时修改限流降级规则，还支持查看限流降级 Metrics 监控。
服务注册与发现：适配Spring Cloud 服务注册与发现标准，默认集成了 Ribbon 的支持。
分布式配置管理：支持分布式系统中的外部化配置，配置更改时自动刷新。 消息驱动能力：基于 Spring Cloud Stream为微服务应用构建消息驱动能力。
分布式事务：使用 @GlobalTransactional 注解，高效并且对业务零侵入地解决分布式事务问题。
阿里云对象存储：阿里云提供的海量、安全、低成本、高可靠的云存储服务。支持在任何应用、任何时间、任何地点存储和访问任意类型的数据。
分布式任务调度：提供秒级、精准、高可靠、高可用的定时（基于 Cron
表达式）任务调度服务。同时提供分布式的任务执行模型，如网格任务。网格任务支持海量子任务均匀分配到所有 Worker（schedulerx-client）上执行。
阿里云短信服务：覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。
组件
Sentinel：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
Nacos：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
RocketMQ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。
Dubbo：Apache Dubbo™ 是一款高性能 Java RPC 框架。
Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。
Alibaba Cloud ACM：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。
Alibaba Cloud OSS: 阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。
Alibaba Cloud SchedulerX: 阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。
Alibaba Cloud SMS: 覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。
三、服务注册与发现 Nacos Discovery
3.1 简介
服务注册：在服务治理框架中，都会构建一个注册中心，每个服务单元向注册中心登记自己提供服务的详细信息。并在注册中心形成一张服务的清单，服务注册中心需要以心跳的方式去监测清单中的服务是否可用，如果不可用，需要在服务清单中剔除不可用的服务。
服务发现：服务调用方向服务注册中心咨询服务，并获取所有服务的实例清单，实现对具体服务实例的访问。
image
常见的注册中心
Zookeeper
zookeeper是一个分布式服务框架，是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。
Eureka
Eureka是Springcloud Netflix中的重要组件，主要作用就是做服务注册和发现。
Consul
Consul是基于GO语言开发的开源工具，主要面向分布式，服务化的系统提供服务注册、服务发现和配置管理的功能。Consul的功能都很实用，其中包括：服务注册/发现、健康检查、Key/Value 存储、多数据中心和分布式一致性保证等特性。Consul本身只是一个二进制的可执行文件，所以安装和部署都非常简单，只需要从官网下载后，在执行对应的启动脚本即可。
Nacos
Nacos是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。它是 Spring Cloud Alibaba 组件之一，负责服务注册发现和服务配置，可以这样认为nacos=eureka+config。
3.2 Nacos 实战
3.2.1 安装
docker pull nacos/nacos-server
docker run --env MODE=standalone --name nacos -d -p 8848:8848 nacos/nacos-server
浏览器访问 http://localhost:8848/nacos 就可以访问服务，默认密码为nacos/nacos。
3.2.2 将微服务注册到nacos
1、在pom.xml中添加依赖
<!--nacos客户端-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
2、在application.yml中添加nacos服务的地址
spring:
cloud:
nacos:
discovery:
server-addr: localhost:8848
3、启动微服务，查看是否注册到nacos
image
3.2.3 示例：订单微服务调用商品微服务
1、在订单微服务的主启动类上添加@EnableDiscoveryClient注解
2、将RestTemplate注入容器
@EnableDiscoveryClient
@EntityScan("cn.x5456.common")
@SpringBootApplication
public class OrderApplication {
public static void main(String[] args) {
SpringApplication.run(OrderApplication.class);
}
@Bean
public RestTemplate getRestTemplate() {
return new RestTemplate();
}
}
3、创建OrderController
@RestController
@Slf4j
public class OrderController {
@Autowired
private RestTemplate restTemplate;
// 我们可以通过它获取到注册到注册中心的所有服务
@Autowired
private DiscoveryClient discoveryClient;
@Autowired
private OrderDao orderDao;
//下单
@RequestMapping("/order/prod/{pid}")
public Order order(@PathVariable("pid") Integer pid) {
log.info("接收到{}号商品的下单请求,接下来调用商品微服务查询此商品信息", pid);
// 通过discoveryClient获取服务的实例信息
List<ServiceInstance> instances = discoveryClient.getInstances("service-product");
ServiceInstance instance = instances.get(0);
//调用商品微服务，查询商品信息
Product product = restTemplate.getForObject("http://" + instance.getHost() + ":" + instance.getPort() + "/product/" + pid, Product.class);
log.info("查询到{}号商品的信息,内容是:{}", pid, JSON.toJSONString(product));
//下单(创建订单)
Order order = new Order();
order.setUid(1);
order.setUsername("测试用户");
order.setPid(pid);
order.setPname(product.getPname());
order.setPprice(product.getPprice());
order.setNumber(1);
orderDao.save(order);
return order;
}
}
4、启动订单和商品微服务，访问 http://127.0.0.1:8091/order/prod/1
image
注：一般情况下，我们都会将一个微服务部署好多份，目的就是为了可以对请求进行负载，像我们上面那样写，每次调用都会使用同一个服务。
3.2.4 配置服务调用采用负载均衡
负载均衡就是将负载(工作任务，访问请求)进行分摊到多个操作单元(服务器,组件)上进行执行。
根据负载均衡发生位置的不同，一般分为服务端负载均衡和客户端负载均衡。
服务端负载均衡指的是发生在服务提供者一方，比如常见的nginx负载均衡。
而客户端负载均衡指的是发生在服务请求的一方，也就是在发送请求之前已经选好了由哪个实例处理请求。
image
我们在微服务调用关系中一般会选择客户端负载均衡，也就是在服务调用的一方来决定服务由哪个提供者执行。
使用Netflix Ribbon 实现
1、再启动一个商品微服务
image
2、在注入的RestTemplate上加上@LoadBalanced注解
@EnableDiscoveryClient // 这个注解可以删除
@EntityScan("cn.x5456.common")
@SpringBootApplication
public class OrderApplication {
public static void main(String[] args) {
SpringApplication.run(OrderApplication.class);
}
@Bean
@LoadBalanced // 添加这个注解
public RestTemplate getRestTemplate() {
return new RestTemplate();
}
}
3、修改order方法
// 可以删掉
@Autowired
private DiscoveryClient discoveryClient;
//下单--自定义负载均衡
@RequestMapping("/order/prod/{pid}")
public Order order(@PathVariable("pid") Integer pid) {
log.info("接收到{}号商品的下单请求,接下来调用商品微服务查询此商品信息", pid);
Product product = restTemplate.getForObject("http://service-product/product/" + pid, Product.class);
log.info("查询到{}号商品的信息,内容是:{}", pid, JSON.toJSONString(product));
//下单(创建订单)
Order order = new Order();
order.setUid(1);
order.setUsername("测试用户");
order.setPid(pid);
order.setPname(product.getPname());
order.setPprice(product.getPprice());
order.setNumber(1);
orderDao.save(order);
log.info("创建订单成功,订单信息为{}", JSON.toJSONString(order));
return order;
}
4、多访问几遍 http://127.0.0.1:8091/order/prod/1 ，查看日志。
Ribbon支持的负载均衡策略
Ribbon内置了多种负载均衡策略,内部负载均衡的顶级接口为 com.netflix.loadbalancer.IRule，具体的负载策略如下表所示：
| 策略名 | 策略声明 | 策略描述 | 实现说明 |
|---|---|---|---|
| BestAvailableRule | public class BestAvailableRule extends ClientConfigEnabledRoundRobinRule | 选择一个最小的并发请求的server | 逐个考察Server，如果Server被tripped了，则忽略，在选择其中ActiveRequestsCount最小的server |
| AvailabilityFilteringRule | public class AvailabilityFilteringRule extends PredicateBasedRule | 过滤掉那些因为一直连接失败的被标记为circuit tripped的后端server，并过滤掉那些高并发的的后端server（active connections 超过配置的阈值） | 使用一个AvailabilityPredicate来包含过滤server的逻辑，其实就就是检查status里记录的各个server的运行状态 |
| WeightedResponseTimeRule | public class WeightedResponseTimeRule extends RoundRobinRule | 根据响应时间分配一个weight，响应时间越长，weight越小，被选中的可能性越低。 | 一个后台线程定期的从status里面读取评价响应时间，为每个server计算一个weight。Weight的计算也比较简单responsetime 减去每个server自己平均的responsetime是server的权重。当刚开始运行，没有形成status时，使用roubine策略选择server。 |
| RetryRule | public class RetryRule extends AbstractLoadBalancerRule | 对选定的负载均衡策略机上重试机制。 | 在一个配置时间段内当选择server不成功，则一直尝试使用subRule的方式选择一个可用的server |
| RoundRobinRule | public class RoundRobinRule extends AbstractLoadBalancerRule | roundRobin方式轮询选择server | 轮询index，选择index对应位置的server |
| RandomRule | public class RandomRule extends AbstractLoadBalancerRule | 随机选择一个server | 在index上随机，选择index对应位置的server |
| ZoneAvoidanceRule | public class ZoneAvoidanceRule extends PredicateBasedRule | 复合判断server所在区域的性能和server的可用性选择server | 使用ZoneAvoidancePredicate和AvailabilityPredicate来判断是否选择某个server，前一个判断判定一个zone的运行性能是否可用，剔除不可用的zone（的所有server），AvailabilityPredicate用于过滤掉连接数过多的Server。 |
我们可以通过修改配置来调整Ribbon的负载均衡策略，具体代码如下：
service-product: # 调用的提供者的名称
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
四、服务调用 Open Feign
Feign是Spring Cloud提供的一个声明式的伪Http客户端，它使得调用远程服务就像调用本地服务一样简单，只需要创建一个接口并添加一个注解即可。
Nacos很好的兼容了Feign，Feign默认集成了 Ribbon，所以在Nacos下使用Fegin默认就实现了负载均衡的效果。
4.1 使用
1、在order微服务中引入Feign的依赖
<!--fegin-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>
2、在主启动类上添加@EnableFeignClients注解，由于Feign会自动采用Ribbon做负载，所以就可以不用RestTemplate了。
@EnableFeignClients
@EntityScan("cn.x5456.common")
@SpringBootApplication
public class OrderApplication {
public static void main(String[] args) {
SpringApplication.run(OrderApplication.class);
}
// @Bean
// @LoadBalanced
// public RestTemplate getRestTemplate() {
// return new RestTemplate();
// }
}
3、创建一个接口
//value用于指定调用nacos下哪个微服务
@FeignClient(value = "service-product")
public interface ProductClient {
//@FeignClient的value + @RequestMapping的value值 其实就是完成的请求地址 "http://service-product/product/" + pid
//指定请求的URI部分
@RequestMapping("/product/{pid}")
Product findByPid(@PathVariable("pid") Integer pid);
}
4、修改order方法，使用Feign进行调用
@Autowired
private ProductClient productClient;
//下单--fegin
@RequestMapping("/order/prod/{pid}")
public Order order(@PathVariable("pid") Integer pid) {
log.info("接收到{}号商品的下单请求,接下来调用商品微服务查询此商品信息", pid);
//调用商品微服务,查询商品信息
Product product = productClient.findByPid(pid);
log.info("查询到{}号商品的信息,内容是:{}", pid, JSON.toJSONString(product));
//下单(创建订单)
Order order = new Order();
order.setUid(1);
order.setUsername("测试用户");
order.setPid(pid);
order.setPname(product.getPname());
order.setPprice(product.getPprice());
order.setNumber(1);
orderDao.save(order);
log.info("创建订单成功,订单信息为{}", JSON.toJSONString(order));
return order;
}
五、服务容错 Sentinel
5.1 服务雪崩效应
在微服务架构中，我们将业务拆分成一个个的服务，服务与服务之间可以相互调用，但是由于网络原因或者自身的原因，服务并不能保证服务的100%可用，如果单个服务出现问题，调用这个服务就会出现网络延迟，此时若有大量的网络涌入，会形成任务堆积，最终导致服务瘫痪。
由于服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩效应” 。
image
雪崩发生的原因多种多样，有不合理的容量设计，或者是高并发下某一个方法响应变慢，亦或是某台机器的资源耗尽。我们无法完全杜绝雪崩源头的发生，只有做好足够的容错，保证在一个服务发生问题，不会影响到其它服务的正常运行。也就是"雪落而不雪崩"。
5.2 常见的容错方案
容错说白了就是保护自己不被猪队友拖垮的一些措施，下面介绍常见的服务容错思路和组件。
常见的容错思路
1、隔离
它是指将系统按照一定的原则划分为若干个服务模块，各个模块之间相对独立，无强依赖。当有故障发生时，能将问题和影响隔离在某个模块内部，而不扩散风险，不波及其它模块，不影响整体的系统服务。常见的隔离方式有：线程池隔离和信号量隔离。
image
2、超时
在上游服务调用下游服务的时候，设置一个最大响应时间，如果超过这个时间，下游未作出反应，就断开请求，释放掉线程。
image
3、限流
限流就是限制系统的输入和输出流量已达到保护系统的目的。为了保证系统的稳固运行，一旦达到的需要限制的阈值，就需要限制流量并采取少量措施以完成限制流量的目的。
image
4、熔断
在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整 体的可用性，可以暂时切断对下游服务的调用。这种牺牲局部，保全整体的措施就叫做熔断。
image
服务熔断一般有三种状态:
- 熔断关闭状态(Closed) ：服务没有故障时，熔断器所处的状态，对调用方的调用不做任何限制
- 熔断开启状态(Open) ：后续对该服务接口的调用不再经过网络，直接执行本地的fallback方法
- 半熔断状态(Half-Open)：尝试恢复服务调用，允许有限的流量调用该服务，并监控调用成功率。如果成功率达到预期，则说明服务已恢复，进入熔断关闭状态；如果成功率仍旧很低，则重新进入熔断关闭状态。
5、降级
降级其实就是为服务提供一个托底方案，一旦服务无法正常调用，就使用托底方案。
image
常见的容错组件
Hystrix：
Hystrix是由Netflix开源的一个延迟和容错库，用于隔离访问远程系统、服务或者第三方库，防止级联失败，从而提升系统的可用性与容错性。
Resilience4J：
Resilicence4J一款非常轻量、简单，并且文档非常清晰、丰富的熔断工具，这也是Hystrix官方推荐的替代产品。不仅如此，Resilicence4j还原生支持Spring Boot 1.x/2.x，而且监控也支持和 prometheus等多款主流产品进行整合。
Sentinel：
Sentinel 是阿里巴巴开源的一款断路器实现，本身在阿里内部已经被大规模采用，非常稳定。
| Sentinel | Hystrix | resilience4j | |
|---|---|---|---|
| 隔离策略 | 信号量隔离（并发线程数限流） | 线程池隔离/信号量隔离 | 信号量隔离 |
| 熔断降级策略 | 基于响应时间、异常比率、异常数等 | 异常比率模式、超时熔断 | 基于异常比率、响应时间 |
| 实时统计实现 | 滑动窗口（LeapArray） | 滑动窗口（基于 RxJava） | Ring Bit Buffer |
| 动态规则配置 | 支持多种配置源 | 支持多种数据源 | 有限支持 |
| 扩展性 | 丰富的 SPI 扩展接口 | 插件的形式 | 接口的形式 |
| 基于注解的支持 | 支持 | 支持 | 支持 |
| 限流 | 基于 QPS，支持基于调用关系的限流 | 有限的支持 | Rate Limiter |
| 集群流量控制 | 支持 | 不支持 | 不支持 |
| 流量整形 | 支持预热模式、匀速排队模式等多种复杂场景 | 不支持 | 简单的 Rate Limiter 模式 |
| 系统自适应保护 | 支持 | 不支持 | 不支持 |
| 控制台 | 提供开箱即用的控制台，可配置规则、查看秒级监控、机器发现等 | 简单的监控查看 | 不提供控制台，可对接其它监控系统 |
| 多语言支持 | Java / C++ | Java | Java |
| 开源社区状态 | 活跃 | 停止维护 | 较活跃 |
5.3 Sentinel简介&安装
Sentinel (分布式系统的流量防卫兵) 是阿里开源的一套用于服务容错的综合性解决方案。它以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来保护服务的稳定性。
Sentinel 具有以下特征：
丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀(即突发流量控制在系统容量可以承受的范围)、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
完备的实时监控：Sentinel 提供了实时的监控功能。通过控制台可以看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。
广泛的开源生态：Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。只需要引入相应的依赖并进行简单的配置即可快速地接入Sentinel。
完善的 SPI 扩展点：Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。
Sentinel 分为两个部分：
-
核心库(Java 客户端)不依赖任何框架/库，能够运行于所有 Java 运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持。
-
控制台(Dashboard)基于 Spring Boot 开发，打包后可以直接运行，不需要额外的 Tomcat 等应用容器。
安装Sentinel控制台
见项目的docker文件夹中。
安装完成后，访问http://127.0.0.1:8099/，默认密码为sentinel/sentinel
image
Sentinel的控制台其实就是一个SpringBoot编写的程序。我们需要将我们的微服务程序注册到控制台上，即在微服务中指定控制台的地址，并且还要开启一个跟控制台传递数据的端口，控制台也可以通过此端口调用微服务中的监控程序获取微服务的各种信息。
image
将order微服务注册到Sentinel控制台 & 简单使用
1、引入依赖
<!--sentinel-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
2、编写OrderController2
@RestController
@Slf4j
public class OrderController2 {
@RequestMapping("/order/message1")
public String message1() {
return "message1";
}
@RequestMapping("/order/message2")
public String message2() {
return "message2";
}
}
3、在application.yml添加配置
spring:
cloud:
sentinel:
transport:
port: 9999 #跟控制台交流的端口,随意指定一个未使用的端口即可
dashboard: localhost:8099 # 指定控制台服务的地址
4、启动订单微服务，访问http://127.0.0.1:8091/order/message1，刷新控制台页面
image
5、为/order/message1接口添加一个流控规则
image
image
6、快速访问http://127.0.0.1:8091/order/message1
image
5.4 Sentinel的基本概念&功能
基本概念
资源：资源是 Sentinel 的关键概念。它可以是 Java 应用程序中的任何内容，可以是一个服务，也可以是一个方法，甚至可以是一段代码。换句话说资源就是Sentinel要保护的东西。
注：上面那个demo中
message1方法就可以认为是一个资源
规则：规则作用在资源之上，定义以什么样的方式保护资源，主要包括流量控制规则、熔断降级规则以及系统保护规则。
注：上面那个demo中就是为message1资源设置了一种流控规则，限制了进入message1的流量
功能（可以联系5.2阅读）
image
流量控制：
流量控制在网络传输中是一个常用的概念，它用于调整网络包的数据。任意时间到来的请求往往是随机不可控的，而系统的处理能力是有限的。我们需要根据系统的处理能力对流量进行控制。
熔断降级：
当检测到调用链路中某个资源出现不稳定的表现，例如请求响应时间长或异常比例升高的时候，则对这个资源的调用进行限制，让请求快速失败，避免影响到其它的资源而导致级联故障。
Sentinel 对这个问题采取了两种手段：
-
通过并发线程数进行限制：
- Sentinel 通过限制资源并发线程的数量，来减少不稳定资源对其它资源的影响。当某个资源出现不稳定的情况下，例如响应时间变长，对资源的直接影响就是会造成线程数的逐步堆积。当线程数在特定资源上堆积到一定的数量之后，对该资源的新请求就会被拒绝。堆积的线程完成任务后才开始继续接收请求。
-
通过响应时间对资源进行降级:
- 除了对并发线程数进行控制以外，Sentinel 还可以通过响应时间来快速降级不稳定的资源。当依赖的资源出现响应时间过长后，所有对该资源的访问都会被直接拒绝，直到过了指定的时间窗口之后才重新恢复。
注：Sentinel 和 Hystrix 的区别？
两者的原则是一致的，都是当一个资源出现问题时，让其快速失败，不要波及到其它服务。
但是在限制的手段上，确采取了完全不一样的方法：
Hystrix 采用的是线程池隔离的方式，优点是做到了资源之间的隔离，缺点是增加了线程切换的成本。
Sentinel 采用的是通过并发线程的数量和响应时间来对资源做限制。（信号量隔离）
系统负载保护
Sentinel 同时提供系统维度的自适应保护能力。当系统负载较高的时候，如果还持续让请求进入可能会导致系统崩溃，无法响应。在集群环境下，会把本应这台机器承载的流量转发到其它的机器上去。如果这个时候其它的机器也处在一个边缘状态的时候，Sentinel 提供了对应的保护机制，让系统的入口流量和系统的负载达到一个平衡，保证系统在能力范围之内处理最多的请求。
注：系统的负载能力，与其所在的服务器内存和CPU等外界环境有关。
5.5 Sentinel规则
5.5.1 流控规则
流量控制，其原理是监控应用流量的QPS(每秒查询率) 或并发线程数等指标，当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。
image
资源名：唯一名称，默认是请求路径，可自定义
针对来源；指定对哪个微服务进行限流，默认指default，意思是不区分来源，全部限制
阈值类型/单机阈值：
- QPS(每秒请求数量)：当调用该接口的QPS达到阈值的时候，进行限流
- 线程数：当调用该接口的线程数达到阈值的时候，进行限流
是否集群：暂不需要集群
配置好后，疯狂请求/order/message1接口时，就会出现下面的情况：
image
3种流控模式
image
1、直接流控模式
直接流控模式是最简单的模式，当指定的接口达到限流条件时开启限流。就是我们上面演示的例子。
2、关联流控模式
关联流控模式指的是，当指定接口关联的接口达到限流条件时，开启对指定接口开启限流。
image
当/order/message2接口的OPS大于1的时候，/order/message1就会被限流。
image
3、链路流控模式
链路流控模式指的是，当从某个接口过来的资源达到限流条件时，开启限流。它的功能有点类似于针对来源配置项，区别在于：针对来源是针对上级微服务，而链路流控是针对上级接口，也就是说它的粒度更细。
1）编写OrderService
@Service
public class OrderServiceImpl {
// 定义资源 value是资源的名称
@SentinelResource("message")
public void message() {
System.out.println("message");
}
}
2）修改OrderController2中的2个方法，调用service层的message方法。
@RestController
@Slf4j
public class OrderController2 {
@Autowired
private OrderServiceImpl orderService;
@RequestMapping("/order/message1")
public String message1() {
orderService.message();
return "message1";
}
@RequestMapping("/order/message2")
public String message2() {
orderService.message();
return "message2";
}
}
3）禁止收敛URL的入口 context
从1.6.3 版本开始，Sentinel Web filter默认收敛所有URL的入口context，因此链路限流不生效。
1.7.0 版本开始(对应SCA的2.1.1.RELEASE)，官方在CommonFilter 引入了 WEB_CONTEXT_UNIFY 参数，用于控制是否收敛context。将其配置为 false 即可根据不同的URL 进行链路限流。
SCA 2.1.1.RELEASE之后的版本,可以通过配置spring.cloud.sentinel.web-context-unify=false即可关闭收敛我们当前使用的版本是SpringCloud Alibaba 2.1.0.RELEASE，无法实现链路限流。
目前官方还未发布SCA 2.1.2.RELEASE，所以我们只能使用2.1.1.RELEASE，需要写代码的形式实现
下面的修改，测试完毕之后要改回来；生产环境最好还是等2.1.2.RELEASE版本发布，配合Cloud Hoxton使用。
（1）将SpringCloud Alibaba的版本调整为2.1.1.RELEASE
<spring-cloud-alibaba.version>2.1.1.RELEASE</spring-cloud-alibaba.version>
（2）配置文件中关闭sentinel的CommonFilter实例化
spring:
cloud:
sentinel:
filter:
enabled: false
（3）手动注入CommonFilter的实例
@Configuration
public class FilterContextConfig {
@Bean
public FilterRegistrationBean sentinelFilterRegistration() {
FilterRegistrationBean registration = new FilterRegistrationBean();
registration.setFilter(new CommonFilter());
registration.addUrlPatterns("/*");
// 入口资源关闭聚合
registration.addInitParameter(CommonFilter.WEB_CONTEXT_UNIFY, "false");
registration.setName("sentinelFilter");
registration.setOrder(1);
return registration;
}
}
4）重启order微服务，访问http://127.0.0.1:8091/order/message1
5）配置链路限流
image
6）狂点刷新
image
3种流控效果
快速失败(默认)：直接失败，抛出异常，不做任何额外的处理，是最简单的效果
Warm Up：它从开始阈值到最大QPS阈值会有一个缓冲阶段，一开始的阈值是最大QPS阈值的1/3，然后慢慢增长，直到最大阈值，适用于将突然增大的流量转换为缓步增长的场景。
排队等待：让请求以均匀的速度通过，单机阈值为每秒通过数量，其余的排队等待; 它还会让设置一个超时时间，当请求超过超时间时间还未处理，则会被丢弃。
5.5.2 降级规则
降级规则就是设置当满足什么条件的时候，对服务进行降级。Sentinel提供了三个衡量条件:
平均响应时间（RT）
当资源的平均响应时间超过阈值（以 ms 为单位）之后，资源进入准降级状态。如果接下来 1s 内持续进入 5 个请求，它们的 RT都持续超过这个阈值，那么在接下的时间窗口（以 s 为单位)）之内，就会对这个方法进行服务降级。
image
注：注意 Sentinel 默认统计的 RT 上限是 4900 ms，超出此阈值的都会算作 4900 ms，若需要变更此上限可以通过启动配置项 -Dcsp.sentinel.statistic.max.rt=xxx 来配置。
异常比例
当资源的每秒异常总数占通过量的比值超过阈值之后，资源进入降级状态，即在接下的时间窗口(以 s 为单位)之内，对这个方法的调用都会自动地返回。异常比率的阈值范围是[0.0, 1.0]。
异常数
当资源近 1 分钟的异常数目超过阈值之后会进行服务降级。注意由于统计时间窗口是分钟级别的，若时间窗口小于 60s，则结束熔断状态后仍可能再进入熔断状态。
5.5.3 热点规则
热点参数流控规则是一种更细粒度的流控规则，它允许将规则具体到参数上。
1、在OrderController2中新增一个方法，记得添加@SentinelResource注解
@RequestMapping("/order/message3")
@SentinelResource("message3")
public String message3(String name, Integer age) {
return "message3" + name + age;
}
2、配置热点规则
image
单机阀值：每秒访问量进行限流
统计窗口时长：超过多长时间，恢复访问
image
5.5.4 授权规则
很多时候，我们需要根据调用来源来判断该次请求是否允许放行，例如知网会根据请求的refer来判断是爬虫还是正常的用户访问，从而返回不同的页面，这时候可以使用 Sentinel 的来源访问控制的功能。来源访问控制根据资源的请求来源(origin)限制资源是否通过：
- 若配置白名单，则只有请求来源位于白名单内时才可通过;
- 若配置黑名单，则请求来源位于黑名单时不通过，其余的请求通过。
1、OrderController中新增一个方法
@RequestMapping("/order/message4")
public String message4() {
return "message4";
}
2、实现RequestOriginParser，定义解析规则
@Component
public class RequestOriginParserDefinition implements RequestOriginParser {
//定义区分来源: 本质作用是通过request域获取到来源标识
//app pc
//然后 交给流控应用 位置进行匹配
@Override
public String parseOrigin(HttpServletRequest request) {
return request.getParameter("serviceName");
}
}
3、重启系统，访问 http://127.0.0.1:8091/order/message4
4、授权
image
5、当访问 http://127.0.0.1:8091/order/message4?serviceName=pc 可以正常访问，访问其他的会失败。
image
5.5.5 系统规则（一般运维配置）
系统保护规则是从应用级别的入口流量进行控制，从单台机器的总体 Load、RT、入口 QPS 、CPU 使用率和线程数五个维度监控应用数据，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。
系统保护规则是应用整体维度的，而不是资源维度的，并且仅对入口流量 (进入应用的流量)生效。
- Load(仅对 Linux/Unix-like 机器生效):当系统 load1（1min阈值）超过阈值，且系统当前的并发线程数超过系统容量时才会触发系统保护。系统容量由系统的 maxQps * minRt 计算得出。设定参考值一般 是 CPU cores * 2.5。
- RT:当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护，单位是毫秒。
- 线程数:当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。
- 入口 QPS:当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护。
- CPU使用率:当单台机器上所有入口流量的 CPU使用率达到阈值即触发系统保护。
扩展：自定义异常返回
问题：流控规则和降级规则返回的异常页面是一样的，我们怎么来区分到底是什么原因导致的呢?
//自定义异常返回页面
@Component
public class ExceptionHandlerPage implements UrlBlockHandler {
// BlockException是五种规则异常的父类
@Override
public void blocked(HttpServletRequest request, HttpServletResponse response, BlockException e) throws IOException {
response.setContentType("application/json;charset=utf-8");
ResponseData responseData = null;
//BlockException 异常接口,包含Sentinel的五个异常
// FlowException 限流异常
// DegradeException 降级异常
// ParamFlowException 参数限流异常
// AuthorityException 授权异常
// SystemBlockException 系统负载异常
if (e instanceof FlowException) {
responseData = new ResponseData(-1, "接口被限流了...");
} else if (e instanceof DegradeException) {
responseData = new ResponseData(-2, "接口被降级了...");
}
response.getWriter().write(JSON.toJSONString(responseData));
}
}
@Data
@AllArgsConstructor//全参构造
@NoArgsConstructor
//无参构造
class ResponseData {
private int code;
private String message;
}
5.6 @SentinelResource的使用
在定义了资源点之后，我们可以通过Dashboard来设置限流和降级策略来对资源点进行保护。同时还能通过@SentinelResource来指定出现异常时的处理策略。
| 属性 | 作用 | 是否必须 |
|---|---|---|
| value | 资源名称 | 是 |
| entryType | entry类型，标记流量的方向，取值IN/OUT，默认是OUT | 否 |
| blockHandler | 处理BlockException的函数名称。函数要求： 1. 必须是 public 2.返回类型与原方法一致 3. 参数类型需要和原方法相匹配，并在最后加 BlockException 类型的参数。 4. 默认需和原方法在同一个类中。若希望使用其他类的函数，可配置 blockHandlerClass ，并指定blockHandlerClass里面的方法。 |
否 |
| blockHandlerClass | 存放blockHandler的类。对应的处理函数必须static修饰，否则无法解析，其他要求：同blockHandler。 | 否 |
| fallback | 用于在抛出异常的时候提供fallback处理逻辑。fallback函数可以针对所有类型的异常（除了 exceptionsToIgnore 里面排除掉的异常类型）进行处理。函数要求： 1. 返回类型与原方法一致 2. 参数类型需要和原方法相匹配，Sentinel 1.6开始，也可在方法最后加 Throwable 类型的参数。 3.默认需和原方法在同一个类中。若希望使用其他类的函数，可配置 fallbackClass ，并指定fallbackClass里面的方法。 |
否 |
| fallbackClass【1.6】 | 存放fallback的类。对应的处理函数必须static修饰，否则无法解析，其他要求：同fallback。 | 否 |
| defaultFallback【1.6】 | 用于通用的 fallback 逻辑。默认fallback函数可以针对所有类型的异常（除了 exceptionsToIgnore 里面排除掉的异常类型）进行处理。若同时配置了 fallback 和 defaultFallback，以fallback为准。函数要求： 1. 返回类型与原方法一致 2. 方法参数列表为空，或者有一个 Throwable 类型的参数。 3. 默认需要和原方法在同一个类中。若希望使用其他类的函数，可配置 fallbackClass ，并指定 fallbackClass 里面的方法。 |
否 |
| exceptionsToIgnore【1.6】 | 指定排除掉哪些异常。排除的异常不会计入异常统计，也不会进入fallback逻辑，而是原样抛出。 | 否 |
| exceptionsToTrace | 需要trace的异常 | Throwable |
5.6.1 示例
1、修改OrderServiceImpl中message方法上的注解，添加几个参数
@Slf4j
@Service
public class OrderServiceImpl {
//定义一个资源
//定义当资源内部发生异常的时候的处理逻辑
//blockHandler 定义当资源内部发生了BlockException应该进入的方法[捕获的是Sentinel定义的异常]
//fallback 定义当资源内部发生了Throwable应该进入的方法
@SentinelResource(
value = "message",
blockHandler = "blockHandler",
fallback = "fallback"
)
public String message() {
return "message";
}
//blockHandler
//要求:
//1 当前方法的返回值和参数要跟原方法一致
//2 但是允许在参数列表的最后加入一个参数BlockException, 用来接收原方法中发生的异常
public String blockHandler(BlockException e) {
//自定义异常处理逻辑
log.error("触发了BlockException,内容为{}", e);
return "BlockException";
}
//fallback
//要求:
//1 当前方法的返回值和参数要跟原方法一致
//2 但是允许在参数列表的最后加入一个参数BlockException, 用来接收原方法中发生的异常
public String fallback(Throwable e) {
//自定义异常处理逻辑
log.error("触发了Throwable,内容为{}", e);
return "Throwable";
}
}
2、修改OrderController2中的message1()方法
@RequestMapping("/order/message1")
public String message1() {
return orderService.message();
}
3、去控制台添加流控规则
image
4、快速访问 http://127.0.0.1:8091/order/message1
image
5.6.2 将限流和降级方法外置到单独的类中
@Slf4j
@Service
public class OrderServiceImpl {
//定义一个资源
//定义当资源内部发生异常的时候的处理逻辑
//blockHandler 定义当资源内部发生了BlockException应该进入的方法[捕获的是Sentinel定义的异常]
//fallback 定义当资源内部发生了Throwable应该进入的方法
@SentinelResource(
value = "message",
blockHandlerClass = OrderServiceImpl3BlockHandler.class,
blockHandler = "blockHandler",
fallbackClass = OrderServiceImpl3Fallback.class,
fallback = "fallback"
)
public String message() {
return "message";
}
public static class OrderServiceImpl3BlockHandler {
//blockHandler
//要求:
//1 当前方法的返回值和参数要跟原方法一致
//2 但是允许在参数列表的最后加入一个参数BlockException, 用来接收原方法中发生的异常
public static String blockHandler(BlockException e) {
//自定义异常处理逻辑
log.error("触发了BlockException,内容为{}", e);
return "BlockException";
}
}
public static class OrderServiceImpl3Fallback {
//fallback
//要求:
//1 当前方法的返回值和参数要跟原方法一致
//2 但是允许在参数列表的最后加入一个参数BlockException, 用来接收原方法中发生的异常
public static String fallback(Throwable e) {
//自定义异常处理逻辑
log.error("触发了Throwable,内容为{}", e);
return "Throwable";
}
}
}
注：类中的方法必须是static的
5.7 Sentinel规则持久化
Sentinel规则默认是存放在内存中，极不稳定，所以需要将其持久化。
本地文件数据源会定时轮询文件的变更，读取规则。这样我们既可以在应用本地直接修改文件来更新规则，也可以通过 Sentinel 控制台推送规则。以本地文件数据源为例，推送过程如下图所示:
首先 Sentinel 控制台通过 API 将规则推送至客户端并更新到内存中，接着注册的写数据源会将新的规则保存到本地的文件中。
1、编写处理类
参见cn.x5456.order.config.FilePersistence
2、添加配置
在resources下创建配置目录 META-INF/services，然后添加文件
com.alibaba.csp.sentinel.init.InitFunc，文件内容为配置类的全路径
image
5.8 Feign整合Sentinel
1、开启Feign对Sentinel的支持
# 开启feign对sentinel的支持
feign:
sentinel:
enabled: true
2、创建容错类
//这是一个容错类
//它要求实现Feign所在接口,并实现里面的方法
//当feign调用出现问题的时候,就会进入到当前类中同名方法中
@Component
public class ProductServiceFallback implements ProductClient {
@Override
public Product findByPid(Integer pid) {
Product product = new Product();
product.setPid(-100);
product.setPname("商品微服务调用出现异常了,已经进入到了容错方法中");
return product;
}
}
3、修改ProductClient上的注解
//value用于指定调用nacos下哪个微服务
@FeignClient(value = "service-product", fallback = ProductServiceFallback.class)
public interface ProductClient {
//@FeignClient的value + @RequestMapping的value值 其实就是完成的请求地址 "http://service-product/product/" + pid
//指定请求的URI部分
@RequestMapping("/product/{pid}")
Product findByPid(@PathVariable("pid") Integer pid);
}
4、修改OrderController的order方法
//下单--fegin
@RequestMapping("/order/prod/{pid}")
public Order order(@PathVariable("pid") Integer pid) {
log.info("接收到{}号商品的下单请求,接下来调用商品微服务查询此商品信息", pid);
//调用商品微服务,查询商品信息
Product product = productClient.findByPid(pid);
if (product.getPid() == -100) {
Order order = new Order();
order.setOid(-100L);
order.setPname("下单失败");
return order;
}
log.info("查询到{}号商品的信息,内容是:{}", pid, JSON.toJSONString(product));
//下单(创建订单)
Order order = new Order();
order.setUid(1);
order.setUsername("测试用户");
order.setPid(pid);
order.setPname(product.getPname());
order.setPprice(product.getPprice());
order.setNumber(1);
orderDao.save(order);
log.info("创建订单成功,订单信息为{}", JSON.toJSONString(order));
return order;
}
5、启动服务，访问 http://127.0.0.1:8091/order/prod/1，由于商品微服务未开，所以会报错
image
6、采用这种方式，异常信息被隐藏了，所以可以采用另外一种方式
1）新建ProductServiceFallbackFactory类
//这是容错类,他要求我们要是实现一个FallbackFactory<要为哪个接口产生容错类>
@Slf4j
@Service
public class ProductServiceFallbackFactory implements FallbackFactory<ProductClient> {
//Throwable 这就是fegin在调用过程中产生异常
@Override
public ProductClient create(Throwable throwable) {
return new ProductClient() {
@Override
public Product findByPid(Integer pid) {
log.error("{}",throwable);
Product product = new Product();
product.setPid(-100);
product.setPname("商品微服务调用出现异常了,已经进入到了容错方法中");
return product;
}
};
}
}
2）修改ProductClient上的注解
//value用于指定调用nacos下哪个微服务
@FeignClient(value = "service-product", fallbackFactory = ProductServiceFallbackFactory.class)
public interface ProductClient {
//@FeignClient的value + @RequestMapping的value值 其实就是完成的请求地址 "http://service-product/product/" + pid
//指定请求的URI部分
@RequestMapping("/product/{pid}")
Product findByPid(@PathVariable("pid") Integer pid);
}
注：fallback和fallbackFactory只能使用其中一种方式
网友评论