文章目录

1.系统拆分

微服务架构,将一个复杂的业务域按DDD的思想拆分成若干子系统,每个子系统负责专属的业务功能,做好垂直化建设,各个子系统之间做好边界隔离,降低风险蔓延。

2.解耦

高内聚、低耦合。小到接口抽象、MVC 分层,大到 SOLID 原则、23种设计模式。核心都是降低不同模块间的耦合度,避免一处错误改动影响到整个系统。

就以开闭原则为例,对扩展是开放的,对修改是关闭的。随着业务功能迭代,如何做到每次改动不对原来的旧代码产生影响。

Spring 框架给我们提供了一个很好的思路,里面有个重要设计 ​​AOP​​ ,全称(Aspect Oriented Programming),面向切面编程。

核心就是采用动态代理技术,通过对字节码进行增强,在方法调用的时候进行拦截,以便于在方法调用前后,增加我们需要的额外处理逻辑。

当然还有一个重要思路就是​​事件机制​​,通过发布订阅模式,新增的需求,只需要订阅对应的事件通知,针对性消费即可。不会对原来的代码侵入性修改,是不是会好很多。

3.异步

如果是非实时响应的动作可以采用异步来完成,线程不需要一直等待,而是继续执行后面的逻辑。

如:线程池(ThreadPoolExecutor)、消息队列 等都是这个原理

高可用的技巧_java
比如一个用户在淘宝下了一笔购物订单,关心的是订单是否创建成功,能否进行后续的付款流程

至于其他业务动作,如短信通知、邮件通知、生成订单快照、创建超时任务记录,这些非核心动作用户并不是特别关心。

我们可以采用消息队列的发布/订阅 机制,数据库插入订单记录后,发布一条消息到 MQ,然后就可以告知用户下单成功。

其他事情,由不同的 Task 任务订阅消息异步处理,彼此间互不干扰。

4.重试

重试主要是体现在远程的RPC调用,受 网络抖动、线程资源阻塞 等因素影响,请求无法及时响应。

为了提升用户体验,调用方可以通过 重试 方式再次发送请求,尝试获取结果。比过:浏览器的 F5 刷新机制就是类似道理。

接口重试是一把双刃剑,虽然客户端收到了响应超时结果,但是我们无法确定,服务端是否已经执行完成。如果盲目地重试,可能会带来严重后果。比如:银行转账。

重试通常跟幂等组合使用,如果一个接口支持了 幂等,那你就可以随便重试

关于的 幂等 的解决方案

  • 插入前先执行查询操作,看是否存在,再决定是否插入
  • 增加唯一索引
  • 建防重表
  • 引入状态机,比如付款后,订单状态调整为已付款,SQL 更新记录前 增加条件判断
  • 增加分布式锁
  • 采用 Token 机制,服务端增加 token 校验,只有第一次请求是合法的

5.补偿

我们知道不是所有的请求都能收到成功响应。除了上面的 重试 机制外,我们还可以采用补偿玩法,实现数据最终一致性。

业务补偿根据处理的方向分为两部分:

  1. 正向。多个操作构成一个分布式事务,如果部分成功、部分失败,我们会通过最大努力机制将失败的任务推进到成功状态
  2. 逆向。同上道理,我们也可以采用反向操作,将部分成功任务恢复到初始状态

补偿操作有个重要前提,业务能接受短时间内的数据不一致。

实现方式:

  1. 本地建表方式,存储相关数据,然后通过定时任务扫描提取,并借助反射机制触发执行
  2. 也可以采用简单的消息中间件,构建业务消息体,由下游的的消费任务执行。如果失败,可以借助MQ的重试机制,多次重试

6.备份

任何服务器都有宕机的可能性,一旦存储了数据,带上状态,如果发生故障,数据丢失,后果是我们无法承受的。

所以,容灾备份也就变成了互联网的基本能力。

高可用的技巧_可用性测试_02
Redis 借助 RDB 和 AOF 来实现两台服务器间的数据同步

  • RDB,全量数据同步
  • AOF,增量数据同步,回放日志

为了预防主节点挂了的情况。这里引入哨兵机制。哨兵机制可以实现主从库的自动切换,有效解决了故障转移。整个过程分为三个阶段:监控、选主、通知。

除了 Redis 中间件外,其他常见的​​MySQL​​​、​​Kafka​​​ 消息中间件、​​HBase​​​ 、​​ES​​​ 等 ,凡是涉及到​​数据存储的介质​​​,都有​​备份机制​​​,一旦主节点挂了,会启用备份节点,保证​​数据不会丢失​​。

7.多活策略

有了备份不一定可以达到高可用

在一些极端情况,如:机房断电、机房火灾、地震、山洪等不可抗力因素,所有的服务器都可能出现故障,无法对外提供服务,导致整体业务瘫痪。

为了降低风险,保证服务的24小时可用性,我们会采用 ​​多活策略​​。

常见的多活方案有,​​同城双活​​​、​​两地三中心​​​、​​三地五中心​​​、​​异地双活​​​、​​异地多活​

不同的方案技术要求、建设成本、运维成本也都不一样。

8.隔离

隔离属于​​物理层面​​的分割,将若干的系统低耦合设计,独立部署,从物理上隔开。

每个子系统有自己独立的代码库,独立开发,独立发布。一旦出现故障,也不会相互干扰。当然如果不同子系统间有相互依赖,这种情况比较特殊,需要有默认值或者异常特殊处理,这属于​​业务层面​​解决方案。

隔离属于分布式技术的衍生产物,我们最常见的​​微服务​​解决方案。

将一个大型的复杂系统拆分成若干个微服务系统,这些微服务子系统通常由不同的团队开发、维护,独立部署,服务之间通过 ​​RPC​​ 远程调用。

​隔离​​​使得系统间边界更加​​清晰​​​,故障可以更加隔离开来,问题的发现与解决也更加快速,​​系统的可用性也更高​​。

9.限流

高并发系统,如果遇到流量洪峰,超过了当前系统的承载能力。我们要怎么办?

一种方案,照单全收,CPU、内存、Load负载飚的很高,最后处理不过来,所有请求都超时无法正常响应。

另一种解决方案,“舍得,有舍有得”,多余的流量我们直接丢弃。

限流分为单机版限流、分布式限流

10.熔断

熔断,其实是对调用链路中某个资源出现不稳定状态时(如:调用超时或异常比例升高),对这个资源的调用进行限制,让请求快速失败,避免影响到其它的资源而导致级联错误。

熔断的主要方式是使用断路器阻断对故障服务器的调用

断路器有三种状态,关闭、打开、半打开。

状态机:

高可用的技巧_微服务_03

  • 关闭(Closed)状态:在这个状态下,请求都会被转发给后端服务。同时会记录请求失败的次数,当请求失败次数在一段时间超过一定次数就会进入打开状态。
  • 打开(Open)状态:在这个状态下,熔断器会直接拒绝请求,返回错误,而不去调用后端服务。同时,会有一个定时器,时间到的时候会变成半打开状态。目的是假设服务会在一段时间内恢复正常。
  • 半打开(Half Open)状态:在这个状态下,熔断器会尝试把部分请求转发给后端服务,目的是为了探测后端服务是否恢复。如果请求失败会进入打开状态,成功情况下会进入关闭状态,同时重置计数。

11.降级

降级是系统保护的一种重要手段。

正如 “好钢用在刀刃上”,为了使有限资源发挥最大价值,我们会临时关闭一些非核心功能,减轻系统压力,并将有限资源留给核心业务。

比如​​电商大促​​​,业务在峰值时刻,系统抵挡不住全部的流量时,系统的负载、CPU 的使用率都超过了预警水位,可以对一些非核心的功能进行降级,降低系统压力,比如把​​商品评价​​​、​​成交记录​​​等功能临时关掉。弃车保帅,保证 ​​创建订单​​​、​​订单支付​​ 等核心功能的正常使用。

降级是通过暂时关闭某些非核心服务或者组件从而保护核心系统的可用性。