基础

单体架构：将业务全部功能集中到一个项目中，打成一个war包存储,部署在一台服务器中，只有一个数据库

优点：架构简单，部署成本低。适合小型项目

问题：高并发性能问题，开发时代码耦合问题，部署升级时停服的问题

垂直架构：拆分模块，每个模块使用自己的数据库，如果有模块需要其他模块数据时需要自己查对方模块数据库

问题：大量代码冗余，系统难以维护，性能问题，部署问题

分布式架构：根据业务功能对系统做拆分，每个业务功能作为独立项目开发，称为一个服务

服务之间相互调用，分布式多节点部署

优点：降低耦合，有利于服务升级和拓展适合大型互联网项目

缺点：服务调用关系错综复杂

服务拆分的粒度如何界定？

服务之间如何调用？

服务的调用关系如何管理？

SOA架构Service-Oriented Architecture，即面向服务的架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。

特点：分布式、可重用、扩展灵活、松耦合

解决的问题：

系统集成
企业系统不断发展过程中，会存在N多系统间相互调用，系统间的关系可能会是一个比较杂乱的网状结构。引入SOA来完成服务之间关系的有序化，这一步需要引入一些产品，比如 ESB、以及技术规范、服务管理规范

系统服务化
完成服务的复用。比如之前可能是各个系统都写了一套登录注册、发邮件、发短信等功能。现在可以将登录注册、发邮件、发短信等功能逻辑抽象成可复用、可组装的服务，通过合理的服务编排，实现业务功能的快速复用。

业务服务化
完成企业系统的对外服务能力。将业务单元（如：OA系统、财务系统等）封装成一项服务。

优点：

抽取公共的功能为服务,提高开发效率
对不同的服务进行集群化部署解决系统压力
基于ESB/DUBBO减少系统耦合
缺点：

抽取服务的粒度较大
服务提供方与调用方接口耦合度较高

微服务架构

微服务

微服务不是一种框架，而且一种架构思想。微服务架构的系统是个分布式系统，按业务领域划分为独立的服务单元，有自动化运维、容错、快速演进的特点，它能够解决传统单体架构系统的痛点，同时也能满足越来越复杂的业务需求。简而言之，微服务架构的风格，就是将单一程序开发成一个微服务，每个微服务运行在自己的进程中，并使用轻量级通信机制，通常是HTTP 、 RESTFUL 、API 。这些服务围绕业务能力来划分构建的，并通过完全自动化部署机制来独立部署这些服务，这些服务可以使用不同的编程语言，以及不同的数据存储技术，以保证最低限度的集中式管理。

理解：就是将一个大的应用拆分为多个小的模块，每个模块都有自己的功能和职责，每个模块可以进行交互，这就是微服务。

1.单一职责，每一个服务对应唯一的业务能力，做到单一职责

2.自治，团队独立，技术独立，数据独立，独立部署和交付

3.面向服务，服务提供统一的接口，与语言技术无关

4.隔离性强，服务调用做好隔离，容错，降级避免出现级联问题（级联故障是由于正反馈循环并且随着时间的增加所产生的故障。典型表现：最初由单个节点或子系统故障触发的连锁反应）

微服务进一步降低服务之间的耦合，提供服务的独立性和灵活性。微服务是一种经过良好架构设计的分布式架构方案。

背景

单体架构不足

1.业务越来越复杂，单体应用的代码量越来越大，代码的可读性、可维护性和可扩展性下降,新人接手代码所需的时间成倍增加，业务扩展带来的代价越来越大。
2.随着用户越来越多，程序承受的并发越来越高，单体应用的并发能力有限。
3.测试的难度越来越大，单体应用的业务都在同个程序中，随着业务的扩张、复杂度的增加，单体应用修改业务或者增加业务或许会给其他业务带来定的影响，导致测试难度增加。

微服务技术的对比

CAP 理论

CAP 也就是 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性） 这三个单词首字母组合。

CAP 理论的提出者布鲁尔在提出 CAP 猜想的时候，并没有详细定义 Consistency、Availability、Partition Tolerance 三个单词的明确定义。

在理论计算机科学中，CAP 定理（CAP theorem）指出对于一个分布式系统来说，当设计读写操作时，只能同时满足以下三点中的两个：

一致性（Consistency） : 所有节点访问同一份最新的数据副本
可用性（Availability）: 非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。
分区容错性（Partition Tolerance） : 分布式系统出现网络分区的时候，仍然能够对外提供服务。

什么是网络分区？

分布式系统中，多个节点之前的网络本来是连通的，但是因为某些故障（比如部分节点网络出了问题）某些节点之间不连通了，整个网络就分成了几块区域，这就叫 网络分区。

当发生网络分区的时候，如果我们要继续服务，那么强一致性和可用性只能 2 选 1。也就是说当网络分区之后 P 是前提，决定了 P 之后才有 C 和 A 的选择。也就是说分区容错性（Partition tolerance）我们是必须要实现的。

简而言之就是：CAP 理论中分区容错性 P 是一定要满足的，在此基础上，只能满足可用性 A 或者一致性 C。

因此，分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。 比如 ZooKeeper、HBase 就是 CP 架构，Cassandra、Eureka 就是 AP 架构，Nacos 不仅支持 CP 架构也支持 AP 架构。

为啥不可能选择 CA 架构呢？ 举个例子：若系统出现“分区”，系统中的某个节点在进行写操作。为了保证 C，必须要禁止其他节点的读写操作，这就和 A 发生冲突了。如果为了保证 A，其他节点的读写操作正常的话，那就和 C 发生冲突了。

选择 CP 还是 AP 的关键在于当前的业务场景，没有定论，比如对于需要确保强一致性的场景如银行一般会选择保证 CP 。

另外，需要补充说明的一点是： 如果网络分区正常的话（系统在绝大部分时候所处的状态），也就说不需要保证 P 的时候，C 和 A 能够同时保证。

常见的可以作为注册中心的组件有：ZooKeeper、Eureka、Nacos...。

ZooKeeper 保证的是 CP。 任何时刻对 ZooKeeper 的读请求都能得到一致性的结果，但是， ZooKeeper 不保证每次请求的可用性比如在 Leader 选举过程中或者半数以上的机器不可用的时候服务就是不可用的。

Eureka 保证的则是 AP。 Eureka 在设计的时候就是优先保证 A （可用性）。在 Eureka 中不存在什么 Leader 节点，每个节点都是一样的、平等的。因此 Eureka 不会像 ZooKeeper 那样出现选举过程中或者半数以上的机器不可用的时候服务就是不可用的情况。 Eureka 保证即使大部分节点挂掉也不会影响正常提供服务，只要有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的。

Nacos 不仅支持 CP 也支持 AP。

总结

在进行分布式系统设计和开发时，我们不应该仅仅局限在 CAP 问题上，还要关注系统的扩展性、可用性等等

在系统发生“分区”的情况下，CAP 理论只能满足 CP 或者 AP。要注意的是，这里的前提是系统发生了“分区”

如果系统没有发生“分区”的话，节点间的网络连接通信正常的话，也就不存在 P 了。这个时候，我们就可以同时保证 C 和 A 了。

总结：如果系统发生“分区”，我们要考虑选择 CP 还是 AP。如果系统没有发生“分区”的话，我们要思考如何保证 CA

BASE理论

BASE 是 Basically Available（基本可用） 、Soft-state（软状态） 和 Eventually Consistent（最终一致性） 三个短语的缩写。BASE 理论是对 CAP 中一致性 C 和可用性 A 权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。

BASE 理论的核心思想

即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

也就是牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”。

BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充。

如果系统没有发生“分区”的话，节点间的网络连接通信正常的话，也就不存在 P 了。这个时候，我们就可以同时保证 C 和 A 了。因此，如果系统发生“分区”，我们要考虑选择 CP 还是 AP。如果系统没有发生“分区”的话，我们要思考如何保证 CA 。

因此，AP 方案只是在系统发生分区的时候放弃一致性，而不是永远放弃一致性。在分区故障恢复后，系统应该达到最终一致性。这一点其实就是 BASE 理论延伸的地方。

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。但是，这绝不等价于系统不可用。

什么叫允许损失部分可用性呢？

响应时间上的损失: 正常情况下，处理用户请求需要 0.5s 返回结果，但是由于系统出现故障，处理用户请求的时间变为 3 s。
系统功能上的损失：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的部分非核心功能无法使用。

软状态

软状态指允许系统中的数据存在中间状态（CAP 理论中的数据不一致），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

最终一致性

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

分布式一致性的 3 种级别：

强一致性 ：系统写入了什么，读出来的就是什么。

弱一致性 ：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态。

最终一致性 ：弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态。

业界比较推崇是最终一致性级别，但是某些对数据一致要求十分严格的场景比如银行转账还是要保证强一致性。

读时修复 : 在读取数据时，检测数据的不一致，进行修复。比如 Cassandra 的 Read Repair 实现，具体来说，在向 Cassandra 系统查询数据的时候，如果检测到不同节点的副本数据不一致，系统就自动修复数据。

写时修复 : 在写入数据，检测数据的不一致时，进行修复。比如 Cassandra 的 Hinted Handoff 实现。具体来说，Cassandra 集群的节点之间远程写数据的时候，如果写失败就将数据缓存下来，然后定时重传，修复数据的不一致性。

异步修复 : 这个是最常用的方式，通过定时对账检测副本数据的一致性，并修复。

比较推荐 写时修复，这种方式对性能消耗比较低。

总结

ACID 是数据库事务完整性的理论，CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸。

SpringCloud

SpringCloud（微服务框架）集成了各种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用体验。

版本对应：https://start.spring.io/actuator/info

①Spring Cloud 是一系列框架的有序集合。

②Spring Cloud 并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来。

netflix eureka 1.1,alibaba 2.2

③通过 Spring Boot 风格进行再封装,屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

④它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。

⑤Spring Cloud项目官方网址：https://spring.io/projects/spring-cloud

⑥Spring Cloud 版本命名方式采用了伦敦地铁站的名称，同时根据字母表的顺序来对应版本时间顺序，比如：最早的Release版本：Angel，第二个Release版本：Brixton，然后是Camden、Dalston、Edgware，Finchley，Greenwich，Hoxton

springcloud组件：

红色不维护。绿色是alibaba一套，推荐使用。

统一网管路由

SpringCloudGateway，Zuul

服务链路监控
Zipkin，Sleuth

注册发现

服务发现：通过服务的应用名称找到服务的具体实例的过程

根据服务名称发现服务的实例过程
客户端会在本地缓存服务端的列表
拉取列表是有间隔周期的（导致服务上线客户端不能第一时间感知到（可以容忍））
其实每次做服务发现都是从本地的列表来进行的

Redis 怎么清除过期的 key LRU(热点 key)
                1 定时（k-thread）
                2 惰性（在再次访问该 key 时有作用）
                3 定期（使用一个线程来完成清除任务）
定期（实时性差） + 惰性

Eureka-Server

Eureka-Server 不仅提供让别人注册的功能，它也能注册到别人里面，自己注册自己，默认会注册自己，我们也可以关掉这个功能。

常用配置文件设置

服务端常用

server:port: 8761 # 为什么是 8761(默认)，其他端口就报错spring:application:name: eureka-server # 服务名称
#eureka 的配置分为三类，客服端client，服务端server和实例instance
eureka:client:service-url: #eureka 服务端和客户端的交互地址 , 集群用 , 隔开defaultZone: http://localhost:8761/eurekafetch-registry: true # 是否拉取服务列表register-with-eureka: true # 是否注册自己（单机 eureka 一般关闭注册自己 , 集群注意打开）server:eviction-interval-timer-in-ms: 30000 # 清除无效节点的频率 ( 毫秒 )-- 定期删除enable-self-preservation: true #server 的自我保护机制，避免因为网络原因造成误剔除 , 生产环境建议打开renewal-percent-threshold: 0.85 #85% ，如果在一个机房的 client 端， 15 分钟内有 85% 的 client 没有续约，那么则可能是网络原因，认为服务实例没有问题，不会剔除他们，宁可放过一万，不可错杀一个，确保高可用instance:hostname: localhost # 服务主机名称instance-id: ${eureka.instance.hostname}:${spring.application.name}:${server.port} # 实例 idprefer-ip-address: true # 服务列表以 ip 的形式展示lease-renewal-interval-in-seconds: 10 # 表示 eureka client 发送心跳给 server 端的频率lease-expiration-duration-in-seconds: 20 # 表示 eureka server 至上一次收到 client 的心跳之后，等待下一次心跳的超时时间，在这个时间内若没收到下一次心跳，则将移除该实例

客户端常用

server:port: 8080 #可以随便写
spring:application:name: eureka-client
eureka:client:service-url: #eureka 服务端和客户端的交互地址 , 集群用 , 隔开defaultZone: http://localhost:8761/eurekaregister-with-eureka: true # 注册自己fetch-registry: true # 拉取服务列表registry-fetch-interval-seconds: 5 # 表示 eureka-client 间隔多久去拉取服务注册信息instance:hostname: localhost # 服务主机名称instance-id: ${eureka.instance.hostname}:${spring.application.name}:${server.port} # 实例 idprefer-ip-address: true # 服务列表以 ip 的形式展示lease-renewal-interval-in-seconds: 10 # 表示 eureka client 发送心跳给 server 端的频率lease-expiration-duration-in-seconds: 20 # 表示 eureka server 至上一次收到 client 的心跳之后，等待下一次心跳的超时时间，在这个时间内若没收到下一次心跳，则将移除该实例

原理

Eureka-server 对外提供的是 restful 风格的服务
以 http 动词的形式对 url 资源进行操作 get post put delete

http 服务 + 特定的请求方式 + 特定的 url 地址
只要利用这些 restful 我们就能对项目实现注册和发现。只不过，eureka 已经帮我们使用 java 语言写了 client，让我们的项目只要依赖 client 就能实现注册和发现！只要你会发起 Http 请求，那你就有可能自己实现服务的注册和发现。不管你是什么语言！

集群

nacos

负载均衡

负载均衡（Load Balance，简称 LB）是高并发、高可用系统必不可少的关键组件，目标是尽力将网络流量平均分发到多个服务器上，以提高系统整体的响应速度和可用性。什么是负载均衡，看完文章秒懂_爱铭网络的博客-CSDN博客_负载均衡

高并发：负载均衡通过算法调整负载，尽力均匀的分配应用集群中各节点的工作量，以此提高应用集群的并发处理能力（吞吐量）。

伸缩性：添加或减少服务器数量，然后由负载均衡进行分发控制。这使得应用集群具备伸缩性。

高可用：负载均衡器可以监控候选服务器，当服务器不可用时，自动跳过，将请求分发给可用的服务器。这使得应用集群具备高可用的特性。

安全防护：有些负载均衡软件或硬件提供了安全性功能，如：黑白名单处理、防火墙，防 DDos 攻击等。

常见算法

1.RoundRobinRule--轮询请求次数 % 机器数量。把每个请求轮流发送到每个服务器上。
2.RandomRule--随机。该算法比较适合服务器性能差不多的场景。
3.加权轮询（Weighted Round Robbin）加权轮询是在轮询的基础上，根据服务器的性能差异，为服务器赋予一定的权值。
4. 源地址哈希（IP Hash） 根据请求源 IP，通过哈希计算得到一个数值，用该数值在候选服务器列表的进行取模运算，得到的结果便是选中的服务器。
3.最小活跃数（Least Active）算法将请求分发到连接数/请求数最少的候选服务器（目前处理请求最少的服务器）。
4.Weighted ResponseTimeRule--根据平均响应时间计算所有服务的权重，响应时间越快服务权重越大被选中的概率越大。刚启动时如果同统计信息不足，则使用轮询的策略，等统计信息足够会切换到自身规则
5.RetryRule-- 先按照轮询的策略获取服务，如果获取服务失败则在指定的时间内会进行重试，获取可用的服务
6.BestAvailableRule --会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务，然后选择一个并发量小的服务
7.ZoneAvoidanceRule -- 默认规则，复合判断 Server 所在区域的性能和 Server 的可用行选择服务器。

8.一致性哈希（Consistent Hash）算法的目标是：相同的请求尽可能落到同一个服务器上。

9.AvailabilityFilteringRule --会先过滤掉由于多次访问故障处于断路器跳闸状态的服务，还有并发的连接数量超过阈值的服务，然后对于剩余的服务列表按照轮询的策略进行访问

Ribbon 默认使用哪一个负载均衡算法：
ZoneAvoidanceRule ：区间内亲和轮询的算法！通过一个 key 来区分

常见的负载均衡方式：

服务端负载均衡
客户端负载均衡

服务端负载均衡

需要建立一个独立的负载均衡服务器。
负载均衡是在客户端发送请求后进行的，因此客户端并不知道到底是哪个服务端提供的服务。
可用服务端清单存储在负载均衡服务器上。

客户端负载均衡：相较于服务端负载均衡，客户端服务在均衡则是一个比较小众的概念。
客户端负载均衡也需要心跳机制去维护服务端清单的有效性，这个过程需要配合服务注册中心一起完成。

负载均衡器位于客户端，不需要单独搭建一个负载均衡服务器。
负载均衡是在客户端发送请求前进行的，因此客户端清楚地知道是哪个服务端提供的服务。
客户端都维护了一份可用服务清单，而这份清单都是从服务注册中心获取的。

Ribbon 就是一个基于 HTTP 和 TCP 的客户端负载均衡器，当我们将 Ribbon 和 Eureka 一起使用时，Ribbon 会从 Eureka Server（服务注册中心）中获取服务端列表，然后通过负载均衡策略将请求分摊给多个服务提供者，从而达到负载均衡的目的。

ribbon

Ribbon 要做什么事情？
先通过 "http://" + serviceId + "/info" 我们思考 ribbon 在真正调用之前需要做什么？
restTemplate.getForObject(“http://provider/info”, String.class);
1. 拦截该请求；
2. 获取该请求的 URL 地址:http://provider/info
3. 截取 URL 地址中的 provider
4. 从服务列表中找到 key 为 provider 的服务实例的集合(服务发现)
5. 根据负载均衡算法选出一个符合的实例
6. 拿到该实例的 host 和 port，重构原来 URL 中的 provider
7. 真正的发送 restTemplate.getForObject(“http://ip:port/info”，String.class)

Ribbon 源码核心：
         ILoadBalancer 接口：起到承上启下的作用
                1. 承上：从 eureka 拉取服务列表
                2. 启下：使用 IRule 算法实现客户端调用的负载均衡
        设计思想：每一个服务提供者都有自己的 ILoadBalancer
                userService---》客户端有自己的 ILoadBalancer
                TeacherService---》客户端有自己的 ILoadBalancer
                在客户端里面就是 Map<String,ILoadBalancer> iLoadBalancers
                Map<String,ILoadBalancer> iLoadBalancers 消费者端
                服务提供者的名称 value （服务列表算法规则）
如何实现负载均衡的呢？

iloadBalancer loadbalance = iloadBalancers.get(“user-service”)
List<Server> servers = Loadbalance.getReachableServers();//缓存起来
Server server = loadbalance .chooseServer(key) //key 是区 id，--》IRule 算法
chooseServer 下面有一个 IRule 算法
IRule 下面有很多实现的负载均衡算法

负载均衡之前的服务列表是从何而来呢？从 eureka 来
Ribbon 里面有没有服务列表？Ribbon 有一个核心接口 ILoadBalance（承上(eureka)启下（Rule））
Ribbon 只做负载均衡和远程调用
我们发现在负载均衡之前，服务列表已经有数据了

loadbalance

服务接口调用

OpenFeign

Feign 的英文表意为“假装，伪装，变形”，是一个http请求调用的轻量级框架，是以Java接口注解的方式调用Http请求，而不用像Java中通过封装HTTP请求报文的方式直接调用。Feign通过处理注解，将请求模板化，当实际调用的时候，传入参数，根据参数再应用到请求上，进而转化成真正的请求，这种请求相对而言比较直观。

Feign 是一个声明式的 REST 客户端，它用了基于接口的注解方式，很方便实现客户端像调用本地接口方法一样，进行远程调用。

Feign 最初由 Netflix 公司提供，但不支持SpringMVC注解，后由 SpringCloud 对其封装，支持了SpringMVC注解，让使用者更易于接受。

Spring Cloud 常见的集成方式是使用Feign+Ribbon技术来完成服务间远程调用及负载均衡的

其实Feign的一个机制就是使用了动态代理：

首先，如果你对某个接口定义了@FeignClient注解，Feign就会针对这个接口创建一个动态代理
接着你要是调用那个接口，本质就是会调用 Feign创建的动态代理，这是核心中的核心
Feign的动态代理会根据你在接口上的@RequestMapping等注解，来动态构造出你要请求的服务的地址
最后针对这个地址，发起请求、解析响应

流程：

在微服务启动时，会向注册中心注册自身实例信息；
微服务会定时向服务发现中心获取服务实例列表，保存到本地；
当ServiceA调用ServiceB时，ribbon组件从本地服务实例列表中查找serviceB实例，如获取了多个实例如：Instance1、Instance2。这时ribbon会通过用户所配置的负载均衡策略从中选择一个实例。
最终，Feign组件会通过ribbon选取的实例发送http请求。

采用Feign+Ribbon的整合方式，是由Feign完成远程调用的整个流程。而Feign集成了Ribbon，Feign使用Ribbon

1. OpenFeign 用过吗？它是如何运作的？
在主启动类上加上@EnableFeignClients 注解后，启动会进行包扫描，把所有加了@FeignClient(value=”xxx-service”)注解的接口进行创建代理对象通过代理对象，使用ribbon 做了负载均衡和远程调用

2. 如何创建的代理对象？
当项目在启动时，先扫描，然后拿到标记了@FeignClient 注解的接口信息，由ReflectiveFeign 类的 newInstance 方法创建了代理对象JDK代理

3. OpenFeign 到底是用什么做的远程调用？
使用的是 HttpURLConnection （java.net）

4. OpenFeign 怎么和 ribbon 整合的？
在代理对象执行调用的时候

断路器 -保险丝

三板斧：服务降级、服务熔断、服务限流

服务降级

通常原因为服务器的资源是有限的，而请求是无限的。在用户使用即并发高峰期，会影响整体服务的性能，严重的话会导致宕机，以至于某些重要服务不可用。故高峰期为了保证核心功能服务的可用性，就需要对某些服务降级处理。可以理解为舍小保大，通常处理为不让客户端等待而是立即返回一个友好的提示。
服务降级是从整个系统的负荷情况出发和考虑的，对某些负荷会比较高的情况，为了预防某些功能（业务场景）出现负荷过载或者响应慢的情况，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的fallback（兜底处理）错误处理信息。这样，虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性。

服务熔断

在微服务架构中，微服务是完成一个单一的业务功能，这样做的好处是可以做到解耦，每个微服务可以独立演进。但是，一个应用可能会有多个微服务组成，微服务之间的数据交互通过远程过程调用完成。这就带来一个问题，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。

线程没有及时回收

熔断机制是应对雪崩效应的一种微服务链路保护机制。我们在各种场景下都会接触到熔断这两个字。高压电路中，如果某个地方的电压过高，熔断器就会熔断，对电路进行保护。同样，在微服务架构中，熔断机制也是起着类似的作用。当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。

服务熔断和服务降级的区别

这里主要从三个原因分开进行比较，最后

触发原因：服务熔断由链路上某个服务引起的，也就是说，服务熔断一般是某个服务（下游服务）故障引起的，而服务降级是从整体的负载考虑。服务熔断是应对系统服务雪崩的一种保险措施，给出的一种特殊降级措施。而服务降级则是更加宽泛的概念，主要是对系统整体资源的合理分配以应对压力。
管理目标层次：服务熔断是一个框架层次的处理，服务降级是业务层次的处理。
实现方式：服务熔断一般是自我熔断恢复，调用的降级处理是在客户端进行降级处理（编写相应的兜底方法），而服务降级相当于是在服务端进行的兜底方案控制。

总的来说：

服务熔断是服务降级的一种特殊情况，是防止服务雪崩而采取的措施。系统发生异常或者延迟或者流量太大，都会触发该服务的服务熔断措施，链路熔断，返回兜底方法。这是对局部的一种保险措施。
服务降级是对系统整体资源的合理分配。区分核心服务和非核心服务。对某个服务的访问延迟时间、异常等情况做出预估并给出兜底方法。这是一种全局性的考量，对系统整体负荷进行管理。

服务限流

在上述两种方式中，最终服务的确可以使用，但是访问的却是缺省的服务，比如服务熔断和服务降级最终都会调用相应的兜底方案返回，也就是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉，待高峰或者问题解决后再打开；而有些场景并不能用熔断和降级来解决，比如稀缺资源（秒杀、抢购）、写服务（如评论、下单）、频繁的复杂查询（评论的最后几页），因此需有一种手段来限制这些场景的并发/请求量，即限流。

限流的目的是通过对并发请求进行限速或者一个时间窗口内的的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务（定向到错误页或告知资源没有了）、排队或等待（比如秒杀、评论、下单）、降级（返回兜底数据或默认数据，如商品详情页库存默认有货）。

一般开发高并发系统常见的限流有：限制总并发数（比如数据库连接池、线程池）、限制瞬时并发数（如nginx的limit_conn模块，用来限制瞬时并发连接数）、限制时间窗口内的平均速率（如Guava的RateLimiter、nginx的limit_req模块，限制每秒的平均速率）；其他还有如限制远程接口调用速率、限制MQ的消费速率。另外还可以根据网络连接数、网络流量、CPU或内存负载等来限流。

常见的限流算法有：令牌桶、漏桶（Sentinel采用的）。计数器也可以进行简单的限流实现。

Hystrix（豪猪）

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

Hystrix是隔离、熔断以及降级的一个框架，说白了就是Hystrix会搞很多小线程池然后让这些小线程池去请求服务，返回结果，Hystrix相当于是个中间过滤区，如果我们的积分服务挂了，那我们请求积分服务直接就返回了，不需要等待超时时间结束抛出异常，这就是所谓的熔断，但是也不能啥都不干就返回啊，不然我们之后手动加积分咋整啊，那我们每次调用积分服务就在数据库里记录一条消息，这就是所谓的降级，Hystrix隔离、熔断和降级的全流程如下：

Sentinel（哨兵）

网关

• 网关旨在为微服务架构提供一种简单而有效的统一的API路由管理方式。

• 在微服务架构中，不同的微服务可以有不同的网络地址，各个微服务之间通过互相调用完成用户请求，客户端可能通过调用N个微服务的接口完成一个用户请求。

• 网关就是系统的入口，封装了应用程序的内部结构，为客户端提供统一服务，一些与业务本身功能无关的公共逻辑可以在这里实现，诸如认证、鉴权、监控、缓存、负载均衡、流量管控、路由转发等

• 在目前的网关解决方案里，有Nginx+ Lua、Netflix Zuul/zuul2 、Spring Cloud Gateway等等

微服务背景下，一个系统被拆分为多个服务，但是像安全认证，流量控制，日志，监控等功能是每个服务都需要的，没有网关的话，我们就需要在每个服务中单独实现，这使得我们做了很多重复的事情并且没有一个全局的视图来统一管理这些功能。

一般情况下，网关可以为我们提供请求转发、安全认证（身份/权限认证）、流量控制、负载均衡、降级熔断、日志、监控等功能。

网关主要做了一件事情：请求过滤 。

常见网关

Netflix Zuul

Zuul 是 Netflix 开发的一款提供动态路由、监控、弹性、安全的网关服务。

Zuul 主要通过过滤器（类似于 AOP）来过滤请求，从而实现网关必备的各种功能。

微服务框架springcloud相关推荐

微服务框架 SpringCloud微服务架构 27 自动补全 27.2 自定义分词器
微服务框架 [SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式,系统详解springcloud微服务技术栈课程|黑马程序员Java微服务] SpringCloud微服务 ...
微服务框架 SpringCloud微服务架构 25 黑马旅游案例 25.5 排序和搜索关键字高亮
微服务框架 [SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式,系统详解springcloud微服务技术栈课程|黑马程序员Java微服务] SpringCloud微服务 ...
微服务框架 SpringCloud微服务架构 25 黑马旅游案例 25.4 广告置顶
微服务框架 [SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式,系统详解springcloud微服务技术栈课程|黑马程序员Java微服务] SpringCloud微服务 ...
微服务框架 SpringCloud微服务架构 26 数据聚合 26.5 多条件聚合
微服务框架 [SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式,系统详解springcloud微服务技术栈课程|黑马程序员Java微服务] SpringCloud微服务 ...
java微服务项目简历_微服务框架-SpringCloud简介
前面一篇文章谈到微服务基础框架,而Netflix的多个开源组件一起正好可以提供完整的分布式微服务基础架构环境,而对于Spring Cloud正是对Netflix的多个开源组件进一步的封装而成,同时又实 ...
最新微服务框架SpringCloud Alibaba介绍，搭建
微服务和SpringCloud Alibaba详细介绍(一),手把手搭建微服务框架 PS:本博客是本人参照B站博主:JAVA阿伟如是说的视频讲解手敲整理的笔记跟着一起手动搭建的框架供大家一起学习 ...
微服务框架 SpringCloud微服务架构服务异步通讯 51 死信交换机 51.3 延迟队列 51.3.1 延迟队列 51.3.2 延迟队列插件
微服务框架 [SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式,系统详解springcloud微服务技术栈课程|黑马程序员Java微服务] 服务异步通讯文章目录微服 ...
JavaEE 企业级分布式高级架构师（十三）微服务框架 SpringCloud (H 版)（1）
Spring Cloud学习笔记 Spring Cloud入门分布式技术图谱 Spring Cloud简介官网介绍百度百科总结 Spring Cloud的国内使用情况 Spring Cloud ...
微服务框架 SpringCloud微服务架构分布式事务 38 动手实践 38.2 实现XA 模式
微服务框架 [SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式,系统详解springcloud微服务技术栈课程|黑马程序员Java微服务] 分布式事务文章目录微服务 ...

微服务框架springcloud

基础

微服务

背景