早期的单机架构，即所有的服务部署在一台服务器的一个进程中国，随着互联网的发展，逐渐演化为分布式架构，多个服务分别部署在不同机器的不同进程中
rpc是远程过程调用，是一种进程间的通信，即像调用本地方法一样调用远程方法
Spring Cloud核心组件：服务注册中心、客户端负载均衡、声明式远程调用、网关路由、熔断器、统一配置中心
服务注册中心
服务提供者的消费者的注册中心，提供者每30秒向eureka发送心跳，保证了AP，最终一致性
客户端负载均衡器
提供多种负载策略 轮询（默认）、随机、权重、过滤、重试
服务发现中心，eureka的替代品
保证强一致性
健康检查 key/value存储 安全服务通信 多数据中心
agent:启动一个consul的守护进程
dev：开发者模式
client： consul的代理，和server交互
server：实现负责数据处理
Gossip协议：流感协议，将数据的以流感传染的模型同步到其他节点
Raft协议：
leader：唯一处理请求的
follower
获选人
声明式，模块化的http调用组件，整合了eureka、ribbon
服务熔断器
处理高并发的两种方法
1、线程池隔离
2、信号量(计数器)隔离
熔断降级：当下游服务因访问压力过大或者网络原因导致响应过慢，为了保证系统整体的可用性，暂时切断对下游服务的调用，这种牺牲局部，保护整体的措施叫熔断
所谓降级就是当某个服务熔断之后，服务将不可调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值
断路器有三种状态：closed、open、half_open
关闭状态：所有请求正常访问
开启状态：请求次数大于20，且存在百分之50的失败率，所有请求进入到降级方法中
半开启状态：维持open状态一段时间（5s），5s之后进入半开状态，尝试释放一个请求到远程微服务调用，如果正常访问，就会关闭断路器，如果不能访问，继续保持开启状态
阿里巴巴开发的流量卫兵，支持服务熔断降级，限流等高级功能，是hystrix的替代方案
微服务网关，是系统对外的唯一入口，所有客户端和消费端统一通过网关接入微服务
作用场景：如身份认证、负载均衡、监控、缓存、请求分片与管理、静态响应处理等
是netflix开源的微服务网关，可以和eureka、ribbon、hystrix等组件配合使用
-
路由
通过整合eureka实现动态路由
-
过滤
pre、routing、post过滤器
spring cloud 开发的网关，性能比zuul高，是基于reactor开发的，使用了webflux框架
- 路由
整合eureka实现动态路由
- 断言
根据条件判断路由
- 过滤
支持pre、post两种，提供单个路由器和全局路由器
-
网关限流
计数器算法
单位时间内最大的请求数量
令牌桶算法
Filter过滤器限流
Sentinel限流
-
spring cloud sleuth
在分布式系统系统中提供追踪的解决方案，并且通过zipkin收集、存储、查找、展现
trace：整个调用链路
span：链路执行的最小单元
消息收发的框架，它提供了一套标准，应用程序只需要按照它的标准进行消息的收发，而不用关注具体的实现机制，。具体的实现可以基于不同的消息中间件进行不同的实现，比如Kafka的实现、RabbitMQ的实现、RocketMQ的实现等
- spring cloud config
解决分布式系统配置的解决方案，包含server、client两个部分，server提供配置文件的存储，client通过接口获取配置
支持手动刷新和动态刷新
-
spring cloud bus
使用轻量级的消息代理来构建一个公用的消息主题来连接各个微服务实例，他广播的消息会被所有注册到注册中心的微服务实例监听的消费，也称消息总线，配置spring cloud config实现配置动态更新
-
Apollo（阿波罗）
在一个分布式系统中不可能同时满足一致性、可用性、分区容错性，最多满足两个，对于分布式系统而言，必须保证P，要么CP，要么AP
- 一致性 指强一致性，数据始终都是一致的
- 可用性 系统提供的服务一直处于可用状态，用户的操作请求在指定时间内响应请求，超出时间范围，认为系统不可用
- 分区容错性 分布式系统在遇到任何网络分区故障的时候，仍需要保证对外提供一致性和可用性，除非整个网络发生故障
网络分区 在分布系统中，可能由于故障导致节点之间无法连通，整个网络分成了几块区域
想zookeeper采用的CP架构，eureka是AP架构，Nacos支持CP、AP架构
在cap理论上权衡的一种结果，即使做不到强一致性，但是可以做到最终一致性
- 基本可用
- 软状态
- 最终一致性
- 阶段一 提交事务请求 1、协调者向所有参与者发送事务内容，询问是否可以执行事务，并等待参与者的反馈 2、各参与者执行本地事务，将执行结果返回各协调者
- 阶段二 事务提交 1、根据阶段一各参与者反馈的ack，如果所有参与者反馈ack，则执行事务提交，否则中断事务提交
事务提交: 1、协调者向所有参与者发送commit请求 2、参与者接收到commit请求，提交事务的提交操作，将执行结果返回给协调者 3、协调者收到所有参与者返回的ack，完成事务的commit 中断提交： 1、发送回滚请求 2、各个参与者回滚事务 3、反馈各协调者事务回滚结果 4、协调者接收各参与者节点ack后回滚事务
二阶段提交存在的问题:
- 同步阻塞 协调者要等待所有参与者反馈信息后才能继续执行
- 单点问题 协调者挂掉导致的事务一致性的问题
- 脑裂问题 网络分区问题，网络不好导致其中一个参与者挂掉事务不一致的问题
- 阶段一 canCommit 1、事务询问 2、各参与者反馈事务询问的响应
- 阶段二 preCommit 根据阶段一的反馈结果分为两种情况 1、 执行事务预提交 各参与者接收到预提交，执行事务操作，将执行结果反馈给协调者 中断事务
- 阶段三 doCommit 执行事务提交
3pc相较于2pc解决了阻塞和单点问题，但是还是无法解决脑裂问题
基于消息传递且具有高效容错性的一种算法，是目前公认的解决分布式一致问题的最有效的算法
- 解决问题: 在分布式系统中，如果产生宕机或网络故障时，快速的正确的在集群内部对某个数据的值达成一致，并且不管发生任何异常，都不会破坏整个系统的一致性
Poxos分为两个阶段
- prepare阶段 准备阶段
- accept阶段 同意阶段
zookeeper是一个开源的分布式协调分布，提供分布式数据一致性的解决方案，分布式应用程序可以实现数据发布订阅、负载均衡、命名服务、集群管理分布式锁、分布式队列等功能
轻量级、高性能、低延迟的RPC框架