为什么使用将系统进行拆分
- 后期维护困难。
- 每次发布都是发布都是一个巨大的系统
- 不用dubbo的话,需要自己维护服务接口通信,考虑超时重试负载均衡等等。
dubbo的工作原理
- provider – 注册中心 – 注册服务信息
- 用户 – consumer – 注册中心 – 调用
- 代理 – 监听网络端口和网络请求 – 负载均衡 – 找到服务
分布式事务
两阶段提交方案
- 询问
- 执行
- 违反微服务架构的规范
TCC方案
- 先检查再确认再确认回滚,耦合度大
- Try阶段:这个阶段说的是对各个服务的资源做检测以及对资源进行锁定或者预留
- Confirm阶段:这个阶段说的是在各个服务中执行实际的操作
- Cancel阶段:如果任何一个服务的业务方法执行出错,那么这里就需要进行补偿,就是执行已经执行成功的业务逻辑的回滚操作
本地消息表方案
- 严重依赖于数据库的消息表来管理事务
可靠消息最终一致性方案
- 保证幂等性
公司如何处理分布式事务
- 你找一个严格资金要求绝对不能错的场景,你可以说你是用的TCC方案。
- 如果是一般的分布式事务场景,订单插入之后要调用库存服务更新库存,库存数据没有资金那么的敏感,可以用可靠消息最终一致性方案
hystrix是什么
- 框架,提供了高可用相关的各种各样的功能,然后再hystrix的保存下,整个系统可以长期处于高可用的状态。
- 限流
- 熔断
- 降级
- 运维监控 监控+报警+优化