文章目录
Spring Cloud 笔记
学习一个框架，最重要的是先弄懂他的思想。
| 名称 | Spring Cloud 第一代 | Spring Cloud 第二代 |
|---|---|---|
| 网关 | Spring Cloud Zuul | Spring Cloud Gateway |
| 注册中心 | Eureka(不再更新)，Consul，Zk | 阿里Nacos，拍拍贷radar等可选 |
| 配置中心 | SpringCloud Config | 阿里Nacos，携程Apollo，随行付Config |
| 客户端软负载均衡 | Ribbon | Spring-cloud-loadb，ancer |
| 熔断器 | Hystrix | spring-cloud-r4j，阿里Sentinel |
SpringCloud第二代（自己研发）和优秀的组件组合：
Spring Cloud Gateway 网关
Spring Cloud Loadbalancer 客户端负载均衡器
Spring Cloud r4j(Resilience4J) 服务保护
Spring Cloud Alibaba Nacos 服务注册
Spring Cloud Alibaba Nacos 分布式配置中心
Spring Cloud Alibaba Sentinel服务保护
SpringCloud Alibaba Seata分布式事务解决框架
Alibaba Cloud OSS 阿里云存储
Alibaba Cloud SchedulerX 分布式任务调度平台
Alibaba Cloud SMS 分布式短信系统
Nacos 分布式配置中心和分布式服务注册中心
Nacos产生的背景
产生背景rpc远程调用中，服务的url的治理
EPC（Remote Procedure Call）远程过程调用，简单的理解是一个节点请求另一个节点提供的服务。
Rpc的远程调用框架 HttpClient、gprc、dubbo、rest、openfeign等。
传统的rpc远程调用中会存在的问题
- 超时的问题
客户端已经发送请求到达了服务器端，服务器端没有及时的响应请求给客户端，防止客户端一直阻塞等待。 - 安全的问题
加密，https，令牌传输数据等，限流，服务保护等。 - 服务于服务之间URL地址管理
在分布式和微服务中，服务于服务之间依赖关系非常复杂的，接口调用如果写死的情况下，后期接口地址发生变化的情况下，需要人工刷新地址。
微服务架构通讯，服务之间依赖关系非常大，如果通过传统的方式管理我们服务的url地址的情况下，一旦地址发生变化的情况下，还需要人工修改rpc远程调用地址。
注册中心：实际上就是存放接口的调用地址。 IP和端口号
接口地址：IP和端口/接口名称。接口名称一般不会改变
知名注册中心有：Dubbo依赖Zookeeper，Eureka，Consul，Nacos，Redis，数据库。
最大特性：能够实现动态感知。
- 微服务架构设计常用名称
生产者：提供接口被其他服务调用
消费者：调用别人写好的接口
注册中心：存放调用接口地址和动态感知
下载nacos之后，启动失败：
java.lang.IllegalArgumentException: db.num is null //报错信息
是因为默认集群模式启动，但是只有一个nacos。需要修改成单机模式启动。在这个startup.cmd文件里修改
rem set MODE = "cluster" %集群模式% 修改前
set MODE=“standalone” %单机模式%
本地负载均衡器 负载均衡算法都是在本地实现
依赖于注册中心
应用场景：Dubbo、feign客户端/rpc远程调用框架
框架：客户端Ribbon
服务器负载均衡器 负载均衡算法都是服务器端实现
依赖于：nginx
场景：tomcat负载均衡
框架：nginx | vs
OpenFeign客户端
OpenFeign是一个Web声明式的Http客户端调用工具，提供接口和注解形式调用。
Nacos作为分布式配置中心属于轻量级，部署和运维学习成本都非常简单。
导入依赖：
加上注解：
如果报Feign客户端没有找到的情况下，就是少了下面这个注解@EnableFeignClients
OpenFeign客户端默认会自带一个负载均衡
Nacos配置中心
分布式配置中心原理：
- 管理人员发布配置文件，需要配置文件持久化到硬盘
- 分布式配置中心服务器端，监听，客户端连接
- 本地项目发送连接到分布式配置中心服务端，分布式配置中心服务端读取配置文件返回给 本地项目（客户端）
- 如果分布式配置中心服务端发现配置文件发生变化的情况下，通知本地项目刷新配置文件。
Data id = 服务名称-版本.结尾
bootstrap.yml 加载优先级比 application.yml 要高。
默认配置格式是：file-extension:Properties
所以需要设置：file-extension: yaml
动态配置属性加上这个注解
@RefreshScope
多版本：名字后面加上版本
IDES：Internet Demonstration and Evaluation System 交互式演示与评估系统
DEV：Development System，开发系统
QAS：Quality Assurance System，质量保证系统
UAT：User Acceptance Test 用户验收测试
PRD：Production System，生产系统
配置文件里加上需要的版本
寻址原理 就是根据服务名称application.name-prd.yaml查询的
高可用
如果时集群模式的化，就没办法一起用本地的配置信息
所以可以保存到数据库里。
先用这个sql导入数据库
然后在配置数据源：然后重启就可以了
连接到数据库后，配置信息就会储存到数据库里了。
nacos集群配置
修改这个cluster.conf.example文件去掉后缀，cluster.conf再加上集群ip和端口号
再修改每个nacos的端口号
事务的定义
对我们的业务逻辑可以实现提交或者回滚，保证数据的一致性的情况。
所以要么提交，要么回滚。
- 原子性a 要么提交，要么回滚
- 一致性c
- 隔离性i 多个事务在一起执行的时候，互不影响
- 持久性d 事务一旦提交或者回滚后，不会在对该结果有任何影响
CAP原则：
CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
主流：Nacos，Eureka，Zookeeper注册中心有哪些区别
ZK 底层采用zab协议 保证每个节点之间数据一致性 模型：cp保证数据一致性 如果我们的zk在选举的过程中，zk集群的坏境暂时可能无法访问，也可能客户端无法读取到最新的接口地址，zk集群可用节点必须满足过半机质，如果没有满足过半机质的情况下，整个zk集群节点也暂时无法访问,目的就是为了保证数据一致性的问题。
在zk中整个集群必须选举一个领导和从节点的角色，没有实现中心化思想。
注册中心的情况下：建议使用ap Eureka
中心化思想 选举领导和从节点
去中心化思想 人人都是平等的
Nacos 1.0 版本开始支持cp和ap 默认是ap模式
Eureka支持ap保证可用性
Zk cp保证数据一致性
ap：保证可用性
cp：保证数据一致性
zookeeper选举机质：
- 判断zxid是否相等
- 在比较myid
zk中心化集群 选举领导（leader）和从节点（follower3）只能有一个leader角色，多个从节点。