隔离设计
按服务种类隔离
按用户隔离
异步通讯设计
异步通讯的三种方式
- 请求响应式
- 通过订阅的方式(接收方依赖于发送方)
- 通过 Broker 的方式(完全解耦,mq)
幂等性设计
- 一种是需要下游系统提供相应的查询接口。上游系统在 timeout 后去查询一下
- 另一种是通过幂等性的方式。我上游系统只管重试,下游系统保证一次和多次的请求结果是一样的。
需要有一个唯一的标识(id),来标志交易是同一笔交易(Snowflake), 用一个存储来记录收到的交易。
服务的状态(继续看)
状态:第三方的存储,session等
无状态的服务都被当作分布式服务设计的最佳实践和铁律,无状态服务在程序 Bug 上和水平扩展上有非常优秀的表现,但是增加了网络开销
补偿事务
为了提高性能,出现了 ACID 的一个变种 BASE
事务的ACID ,但是对于分布式系统来说,尤其是微服务来说,这样的方式是很难满足高性能要求的。我们都很熟悉 CAP 理论,ACID 的一个变种 BASE(Basic Availability,Soft-state,Eventual Consistency)
业务补偿的设计重点
服务方支持幂等性。并且在上游有重试机制。
重试设计
“重试”的语义是我们认为这个故障是暂时的,而不是永久的,所以,我们会去重试。
重试的时间和重试的次数,幂等,重试的代码比较简单也比较通用(@Retryable,service mesh)
熔断设计
需要实现三个状态:闭合、断开和半开(允许应用程序一定数量的请求去调用服务),分别对应于正常、故障和故障后检测故障是否已被修复的场景
限流设计
限流的策略
拒绝服务
服务降级(部分返回)
特权请求(高V)
延时处理(队列,应对短暂的峰刺请求)
实现方式(计数器,队列)
降级设计
降级需要牺牲掉的东西有:
降低一致性:最终一致性(简化流程,异步,降低数据一致性)
简化流程,异步:
降低数据一致性:
简化功能,停止次要功能