前记
今天申通二面，竟然问我分布式，微服务的概念，我答的非常不好
什么是分布式，什么是微服务
项目架构的演变
- 单体架构：易于开发，部署，测试 成本低、模块耦合严重，容易互相影响
- 垂直架构：根据业务把项目垂直切割成多个项目 流量分担，解决了并发问题，可以针对不同系统进行优化，水平扩展方便，负载均衡，系统相互独立，互不影响。 服务之间调用硬编码，负载均衡比较复杂，监控不到位
- 分布式架构（SOA:Service Oriented Architecture）面向服务的架构，在垂直划分的基础上，将每个项目拆分出多个具备松耦合的服务，为了解决垂直架构的缺陷，引入dubbo：面向接口远程调用，只能容错和负载均衡，已经服务自动注册和发现。分为业务层，基础业务层，基础服务层，存储层。架构更加清晰，每个业务模块职责单一，服务应用无状态化。但是调用链路长，服务质量不可变化，下游抖动会影响上游业务
- 微服务架构 : 在SOA上做升华，粒度更加细致、服务注册和发现，负载均衡，熔断，链路追踪，API网关
Spring Cloud是什么
将各家公司开发的比较成熟的服务框架组合起来，通过springboot风格进行再封装，屏蔽掉了复杂的配置和实现原理
Dubbo：负载均衡 服务调用
熔断器： sentinel
网关：Spring cloud Gateway
配置中心： Nocos
为什么选择用dubbo而不是其他
目前市面上选择比较多的就是 dubbo 和 Feign
dubbo支持多种传输协议，默认是Netty Tcp，长连接，异步。负载均衡可以精确到某个服务的某个方法。自带容错机制
feign基于HTTP传输协议，短连接，不适合高并发。负载均衡是client级别的。利用熔断机制来实现容错
分布式环境下解决事务问题
如果A系统事务提交成功了，但是B系统在提交的时候网络波动或者其他原因失败了，就会有问题
第一个阶段协调者会等待所有参与者相应才会进行下一步操作，当然第一阶段的协调者有超时机制
2pc是一种尽量保证强一致性的分布式事务，是同步阻塞的，总体效率低
- 3PC
引入参与者超时机制。通过预提交阶段可以减少故障恢复时候的复杂性。只做了解即可
-
TCC
try - confirm - cancel
对业务的侵入较大和业务紧耦合，撤销和确认操作的执行可能需要重试，因此要保证幂等
- 消息事务
- 先给broker发送事务消息及半消息，对消费者不可见，然后发送成功后发送方再执行本地事务
- 再根据本地事务的结果broker发送commit或者rollback命令
- 发送方提供一个反查询接口，如果一段时间内没有收到任何操作请求，那么broker会通过反查接口判断
可以保证：
- 业务主动方本地事务提交失败，业务被动方不会受到消息的投递
- 只要业务主动方本地事务执行成功，那么消息服务一定会投递消息给下游的业务被动放，并且保证业务方一定能成功消费该消息（消费成功或者失败，即最终一定会有一个最终态）
