弹力设计
1认识故障
故障产生的原因可以分为以下几大类
- 网络问题：网络链接出现问题、宽带出现堵塞
- 性能问题：数据库慢SQL、Java full gc、硬盘IO过大、CPU飙高、内存不足
- 安全问题：被网络攻击，如DDoS
- 运维问题：系统不断进行更新和修改
- 管理问题：没有梳理出关键服务及服务依赖关系
- 硬件问题：硬盘损坏、网卡故障、机房掉电
故障是正常的，而且是常见的，"Everything will fails"
不要尝试着去避免故障，而是把处理故障的代码当成正常的功能做在架构里写在代码中
ps:四个9一年宕机时间约为53分钟，五个9一年宕机时间约为5分钟
2隔离设计
使用隔板(Bulkheads)技术，优点一是当故障蔓延开来，将架构分隔成多个模块隔离故障，即使部分机器故障了，只是影响部分用户;优点二为可以快速恢复，当某个环境出现故障，可以迅速下发配置，改变用户请求的路由方向，实现秒级故障恢复
一般有以下两种隔离思想：
-
按服务的种类来做分离：比如评论服务、用户服务、商品服务，不同服务使用不同的域名、服务器和数据库，做到接入层到应用层再到数据层三层完全隔离，每一个服务暴露出去，也就是微服务架构。通常引入大量异步处理模型
-
按用户来做分离：所谓多租户模型，对于比较大的客户，可以设置专门独立服务实例，对于比较小的用户，可以让他们共享一个服务实例。1、完全独立的设计；2、独立的数据分区，共享的服务；3、共享的服务，共享的数据分区。虚拟化技术KVM、Linux Container、Docker使实现物理资源的共享和成本节约
隔离设计的重点：
- 隔离业务的大小和粒度，分析业务的需求和系统
- 系统的复杂性、成本、性能、资源使用
- 隔离模式需要配置一些高可用、重试、异步、消息中间件，流控、熔断等设计模式
- 看到所有服务非常完整的监控系统
3异步通讯设计
同步：打电话，需要实时响应
异步：发邮件，不需要马上回复
当系统读写文件时，操作系统并不会真正同步地去读操作硬盘，而是把硬盘读写请求先在内存中停留一会，然后对这些读写请求做merge和sort，对相同的读请求只读一次，对相同的写操作，只写最后一次
TCP协议向网络发包的时候，会把我们要发送的数据先在缓冲区中进行囤积，当囤积到一定尺寸后(MTU)才向网络发送，极大化利用网络带宽
**异步处理让系统可以统一调度，异步处理系统的实质是把被动的任务处理变成主动地任务处理，实质是对任务进行调度和统筹管理，**对于大吞吐量的场景，异步通讯比同步通讯有更大优势：
同步调用的缺点：
- 同步调用要求被调用方的吞吐不低于调用方的吞吐，否则导致调用方因为性能不足而拖死调用方。
- 整个同步调用链的性能由最慢的那个服务决定，且如果被调用方有问题，调用方也会跟着出现问题，出现多米诺效应。
- 同步调用只能是一对一，很难做到一对多。
- 同步调用会导致调用方一直等待被调用方完成，若一层一层等待，所有参与方有相同的等待时间，这会非常消耗调用方的资源。
异步通讯的三种方式：
-
请求响应式：第一种发送方时不时轮询，问一下接收方是否完成；第二种发送方注册一个回调方法，接收方处理完回调请求方，存在一定的耦合，发送发依赖于接收方，并且要把自己的回调发送给接收方，处理完后回调。
-
通过订阅式：接收方订阅发送方的消息，发送方把相关消息或数据放到接收方所订阅队列中，而接收方从队列中获取数据，发送方只是告诉接收方有事要干，收完消息给个ACK就好了，这样服务是无状态的，分布式系统的服务设计需要向无状态服务考虑的。
-
通过Broker式（中间人）：发送方和接收方互相看不到对方，发送方通过Broker发送消息，接收方从Broker接受消息，这样完全解耦，所有服务都不需要相互依赖，而是依赖一个中间件Broker。就要求Broker 必须高可用、可水平扩展、持久化不丢数据
其中第二、三条为事件驱动(服务间是平等的、服务间高度隔离、服务间吞吐速度解耦)缺点是：
- 业务流程不那么明显和好管理，整个架构比较复杂，需要有相关的服务消息跟踪机制
- 事件可能会乱序，需要管理一个状态机的控制
- 事务处理变得复杂，需要使用两阶段提交保证强一致性或最终一致性
怎么处理任务：
- 前台系统，把用户发来的请求意义记录下来，类似请求日志，操作在数据库或是存储上只会追加操作
- 任务处理系统处理收到的请求，需要一个任务派发器，一般使用推拉结合的系统，push端做一定的任务调度，比如把相同商品的订单合并起来，pull端订阅push端发出来的异步消息
- 异步处理可能一些故障导致任务没有被处理(消息丢失，没有通知，或通知到了却没有处理)，任务处理方处理完成后给任务发起方回传状态，确保不会有漏掉；发起方需要有个定时任务，把一些超时没有回传状态的任务再重新做一遍
4幂等性设计
所谓幂等性设计，一次请求和多次请求某个资源应该具有同样的副作用，可以用f(x)=f(f(x))表示
系统解耦隔离后，服务间调用状态可能会有三个状态：Success、Failed、Timeout，前两个是明确状态，而超时有可能多种原因造成
举个栗子：
订单创建接口，第一次调用超时了，然后调用方重试一次，是否会多创建一笔订单？
解决方案是下游的系统提供支持幂等性的交易接口
首先需要一个全局唯一ID：UUID字符串占用空间较大，索引效率低；可采用分布式ID生成算法snowflake/leaf，产生一个long型的ID，41bits作为毫秒数，10bits作为机器编号，12bits作为毫秒内序列号
5服务的状态
所谓的状态，就是为了保留程序的一些数据或是上下文
无状态的服务就像一个一个函数一样，对于给定的输入，会给出唯一确定的输出，好处是很容易运维和伸缩，但需要底层有分布式的数据支持
有状态服务
- 数据本地化，状态和数据是本机保存的，这方面不但有更低的延时
- 更高的可用性和更强的一致性，CAP中的CA
对于客户端传来的请求，都必须保证其落在同一个实例上(Sticky Session)，可通过持久化的长连接，HTTP长连接或hash算法走一致性哈希，这样带来的问题是结点负载和数据并不会很均匀，而无状态的服务需要我们把数据同步到不同的结点上
6补偿事务
由于分布式一个明显的问题就是一个业务流程需要组合一组服务，比如一个步骤失败了，那么要么回滚到以前的服务调用，要么不断重试保证所有的步骤都成功
- A，原子性，整个事务中所有操作，要么全部成功，要么全部失败，不可能停留在中间的某个环节
- C，一致性，事务开始之前和事务结束之后，数据库的完整性约束没有被破坏
- I，隔离性，两个事务的执行是互不干扰的
- D，持久性，事务完成之后，该事务对数据库所做的更改便持久保存到数据库中
事务的ACID属性保证了数据库的一致性，比如大家都去买一本书过程中，每个用户的购买请求都需要把库存锁住，等减完库存后再把锁释放出来，后续的人才能进行购买，这样就不可能做出性能比较高的系统出来
- B Basic Availability，基本可用
- S Soft-state，软状态，是处于有状态和无状态的服务一种中间状态，为了提高性能，可以让服务暂时保存一些状态或数据，这些状态和数据不是强一致性的
- E Eventual Consistency ，最终一致性
类似亚马逊买商品，大家会先收到一封邮件说系统收到你的订单了，然后过一会你会收到你的订单被确认的邮件，这时候才真正的分配库存，有的时候也会收到没有库存的邮件(
标签：降级,左耳,服务,请求,听风,重试,调用,专栏,限流 来源： https://blog.csdn.net/m0_37578675/article/details/116843454
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。