原文链接：https://blog.csdn.net/u011863024/article/details/114298270
分布式前
单机单库没这个问题
从1:1 -> 1:N -> N:N
单体应用被拆分成微服务应用，原来的三个模块被拆分成三个独立的应用,分别使用三个独立的数据源，业务操作需要调用三三 个服务来完成。此时每个服务内部的数据一致性由本地事务来保证， 但是全局的数据一致性问题没法保证。
一句话：一次业务操作需要跨多个数据源或需要跨多个系统进行远程调用，就会产生分布式事务问题。
本文代码：下载
原文链接：https://blog.csdn.net/u011863024/article/details/114298270
官方Github: https://github.com/alibaba/Sentinel
官方文档: https://sentinelguard.io/zh-cn/docs/introduction.html
随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
Sentinel 具有以下特征:
**丰富的应用场景：**Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
**完备的实时监控：**Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。
**广泛的开源生态：**Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。
**完善的 SPI 扩展点：**Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。
本文代码：下载
原文链接：https://blog.csdn.net/u011863024/article/details/114298270
为什么叫Nacos
前四个字母分别为Naming和Configuration的前两个字母，最后的s为Service。
是什么
一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
Nacos: Dynamic Naming and Configuration Service
Nacos就是注册中心＋配置中心的组合 -> Nacos = Eureka+Config+Bus
能干嘛
替代Eureka做服务注册中心
替代Config做服务配置中心
去哪下
https://github.com/alibaba/nacos/releases
各中注册中心比较
| 服务注册与发现框架 | CAP模型 | 控制台管理 | 社区活跃度 |
|---|---|---|---|
| Eureka | AP | 支持 | 低(2.x版本闭源) |
| Zookeeper | CP | 不支持 | 中 |
| consul | CP | 支持 | 高 |
| Nacos | AP 或 CP | 支持 | 高 |
据说Nacos在阿里巴巴内部有超过10万的实例运行，已经过了类似双十一等各种大型流量的考验。
Spring Cloud Netflix项目进入维护模式
https://spring.io/blog/2018/12/12/spring-cloud-greenwich-rc1-available-now
什么是维护模式？
将模块置于维护模式，意味着Spring Cloud团队将不会再向模块添加新功能。
他们将修复block级别的 bug 以及安全问题，他们也会考虑并审查社区的小型pull request。
该篇文档，参考代码：下载
原文链接：https://blog.csdn.net/u011863024/article/details/114298270
为什么会出现这个技术？要解决哪些问题？
在微服务框架中，一个由客户端发起的请求在后端系统中会经过多个不同的的服务节点调用来协同产生最后的请求结果，每一个前段请求都会形成一条复杂的分布式服务调用链路，链路中的任何一环出现高延时或错误都会引起整个请求最后的失败。
该篇文档，前置代码下载：下载
该篇文档，全部完成后的代码下载：下载
原文链接：https://blog.csdn.net/u011863024/article/details/114298270
常见 MQ(消息中间件)：
ActiveMQ
RabbitMQ
RocketMQ
Kafka
有没有一种新的技术诞生，让我们不再关注具体MQ的细节，我们只需要用一种适配绑定的方式，自动的给我们在各种MQ内切换。（类似于Hibernate）
Cloud Stream 是什么？
屏蔽底层消息中间件的差异，降低切换成本，统一消息的编程模型。
该篇文档，前置代码下载：下载
该篇文档，全部完成后的代码下载：下载
原文链接：https://blog.csdn.net/u011863024/article/details/114298270
Spring Cloud Bus配合Spring Cloud Config使用可以实现配置的动态刷新。
Spring Cloud Bus 配合Spring Cloud Config 使用可以实现配置的动态刷新。
该篇文档，前置代码下载：下载
该篇文档，全部完成后的代码下载：下载
原文链接：https://blog.csdn.net/u011863024/article/details/114298270
SpringCloud: https://cloud.spring.io/spring-cloud-static/spring-cloud-config/2.2.1.RELEASE/reference/html/
微服务意味着要将单体应用中的业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行，所以一套集中式的、动态的配置管理设施是必不可少的。
SpringCloud 提供了 ConfigServer 来解决这个问题，我们每一个微服务自己带着一个 application.yml，上百个配置文件的管理.……
该篇文档，前置环境条件为：构建微服务架构(eureka篇)，需要单机版本eureka环境
该篇文档，前置代码下载：下载
该篇文档，全部完成后的代码下载：下载
原文链接：https://blog.csdn.net/u011863024/article/details/114298270
GitHub地址：https://github.com/Netflix/Hystrix/wiki/How-To-Use
SpringCloud: https://cloud.spring.io/spring-cloud-static/spring-cloud-gateway/2.2.1.RELEASE/reference/html/
概述
Cloud全家桶中有个很重要的组件就是网关，在1.x版本中都是采用的Zuul网关;
但在2.x版本中，zuul的升级一直跳票，SpringCloud最后自己研发了一个网关替代Zuul，那就是SpringCloud Gateway—句话：gateway是原zuul1.x版的替代
Gateway是在Spring生态系统之上构建的API网关服务，基于Spring 5，Spring Boot 2和Project Reactor等技术。
Gateway旨在提供一种简单而有效的方式来对API进行路由，以及提供一些强大的过滤器功能，例如:熔断、限流、重试等。
SpringCloud Gateway是Spring Cloud的一个全新项目，基于Spring 5.0+Spring Boot 2.0和Project Reactor等技术开发的网关，它旨在为微服务架构提供—种简单有效的统一的API路由管理方式。
SpringCloud Gateway作为Spring Cloud 生态系统中的网关，目标是替代Zuul，在Spring Cloud 2.0以上版本中，没有对新版本的Zul 2.0以上最新高性能版本进行集成，仍然还是使用的Zuul 1.x非Reactor模式的老版本。而为了提升网关的性能，SpringCloud Gateway是基于WebFlux框架实现的，而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。
Spring Cloud Gateway的目标提供统一的路由方式且基于 Filter链的方式提供了网关基本的功能，例如:安全，监控/指标，和限流。
该篇文档，前置环境条件为：构建微服务架构(eureka篇)，需要单机版本eureka环境
该篇文档，前置代码下载：下载
该篇文档，全部完成后的代码下载：下载
原文链接：https://blog.csdn.net/u011863024/article/details/114298270
GitHub 地址：https://github.com/Netflix/Hystrix/wiki/How-To-Use
分布式系统面临的问题
复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免地失败。
多个微服务之间调用的时候，假设微服务A调用微服务 B 和微服务 C，微服务 B 和微服务 C 又调用其它的微服务，这就是所谓的 “扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的 “雪崩效应”.
对于高流量的应用来说，单一的后避依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。
所以，通常当你发现一个模块下的某个实例失败后，这时候这个模块依然还会接收流量，然后这个有问题的模块还调用了其他的模块，这样就会发生级联故障，或者叫雪崩。