Feign

面对互联网的高并发过载流量，为了保证系统的稳定性，我们一般会对过载流量进行限流。 1、什么是 sentinel：在基于 SpringCloud 构建的微服务体系中，服务间的调用链路会随着系统的演进变得越来越长，这无疑会增加了整个系统的不可靠因素。 在并发流量比较高的情况下，由于网络调用之间存在一定的超时时间，链路中的某个服务出现宕机都会大大增加整个调用链路的响应时间，而瞬间的流量洪峰则会导致这条链路上所有服务的可用线程资源被打满，从而造成整体服务的不可用，这也就是我们常说的 “雪崩效应”。 而在微服务系统设计的过程中，为了应对这样的糟糕情况，最常用的手段就是进行 ”流量控制“ 以及对网络服务的调用实现“熔断降级”。因此，Sentinel 就应运而生了。 Sentinel 是一款面向分布式服务架构的轻量级流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统自适应保护等多个维度来保障服务的稳定性，核心思想是：根据对应资源配置的规则来为资源执行相应的流控/降级/系统保护策略，Sentinel 的主要特性如下图： 2、主流限流熔断组件对比： 从三者的...

规则持久化-代码仓库地址 现在，sentinel的所有规则都是内存存储，重启后所有规则都会丢失。在生产环境下，我们必须确保这些规则的持久化，避免丢失。 1.规则管理模式规则是否能持久化，取决于规则管理模式，sentinel支持三种规则管理模式： 原始模式：Sentinel的默认模式，将规则保存在内存，重启服务会丢失。 pull模式 push模式 1.1.pull模式pull模式：控制台将配置的规则推送到Sentinel客户端，而客户端会将配置规则保存在本地文件或数据库中。以后会定时去本地文件或数据库中查询，更新本地规则。 1.2.push模式push模式：控制台将配置规则推送到远程配置中心，例如Nacos。Sentinel客户端监听Nacos，获取配置变更的推送消息，完成本地配置更新。 2.实现push模式1.引入依赖引入sentinel监听nacos的依赖： 1234<dependency> <groupId>com.alibaba.csp</groupId> <artifactId>se...

单体, 微服务, 分布式 1.1 单体架构单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署。 单体架构的优缺点如下： 优点： 架构简单 部署成本低 缺点： 耦合度高（维护困难、升级困难） 1.2 分布式架构分布式架构：根据业务功能对系统做拆分，每个业务功能模块作为独立项目开发，称为一个服务。 分布式架构的优缺点： 优点： 降低服务耦合 有利于服务升级和拓展 缺点： 服务调用关系错综复杂 分布式架构虽然降低了服务耦合，但是服务拆分时也有很多问题需要思考： 服务拆分的粒度如何界定？ 服务之间如何调用？ 服务的调用关系如何管理？ 人们需要制定一套行之有效的标准来约束分布式架构。 1.3 微服务微服务的架构特征： 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责 自治：团队独立、技术独立、数据独立，独立部署和交付 面向服务：服务提供统一标准的接口，与语言和技术无关 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题 微服务的上述特性其实是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的...

1.初识Sentinel1.1.雪崩问题及解决方案1.1.1.雪崩问题微服务中，服务间调用关系错综复杂，一个微服务往往依赖于多个其它微服务。 如图，如果服务提供者I发生了故障，当前的应用的部分业务因为依赖于服务I，因此也会被阻塞。此时，其它不依赖于服务I的业务似乎不受影响。 但是，依赖服务I的业务请求被阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞： 服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，那么当前服务也就不可用了。 那么，依赖于当前服务的其它服务随着时间的推移，最终也都会变的不可用，形成级联失败，雪崩就发生了： 1.1.2.超时处理解决雪崩问题的常见方式有四种： •超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待 1.1.3.仓壁模式方案2：仓壁模式 仓壁模式来源于船舱的设计： 船舱都会被隔板分离为多个独立空间，当船体破损时，只会导致部分空间进入，将故障控制在一定范围内，避免整个船体都被淹没。...