天天看点

工作十年,浅谈我的服务接口的高可用设计经验

作者:猿之生活JAVA技术学堂

工作十年,浅谈我的服务接口的高可用设计经验

#头条创作挑战赛#

工作十年,浅谈我的服务接口的高可用设计经验

软件开发的三高指标:高并发、高性能、高可用。本文主要围绕高可用展开叙述,希望对大家都有所帮助。

前言

随着计算机网络的不断普及,大规模软件应用成为每个公司考虑的指标,软件设计阶段需要考虑软件整体架构。提高软件的高可用,已经成为现阶段急需解决的事情。

那作为一名资深的后端研发人员需要具备哪些架构思维呢,首先来说,开发服务接口对程序员而言,是最基本的工作,在设计接口时候都绕不开一个共同的目标就是 “高可用”设计方案。那我们来看一下什么是高可用接口设计,以及需要考虑哪些指标。

工作十年,浅谈我的服务接口的高可用设计经验

高可用衡量标准

所谓的服务高可用主要是指服务正常运行的时间百分比,业界主要是用 N 个9来衡量。主要体现在服务的接口正确性以及延时上。

如果以一年拿365天计算(8760小时),具体计算如下:

工作十年,浅谈我的服务接口的高可用设计经验

到底什么是高可用

简单来说就是我们的设计的系统具不具备应对和规避风险的能力,会不会出现雪崩效应和链式效应。

高可用(High Availability)的定义

(From 维基百科)是 IT 术语,指系统无中断地执行其功能的能力,代表系统的可用性程度,是进行系统设计时的准则之一。

高可用系统设计思想

高可用系统的设计,主要从以下几个方面考量

  1. 产品
  2. 开发
  3. 运维
  4. 基建

等全方位去考量和设计

高可用系统的设计思想包括但不限于:

• 容量规划层面

• 服务层面

• 存储层面

• 运维层面

• 产品层面

• 应急预案处理层面

那为什么要做高可用呢

架构决定系统质量上限,代码决定系统质量下限。

为了应对这些在软件使用过程中产生不可控因素的发生,导致软件无法正常运作,所以我们必须要做高可用

高可用的关键点

高可用接口关键因素

Dependence(依赖)、Probability(概率)、Time(时长)、Scope(范围)

主要有以下方面考虑

1. 依赖的资源相对少,避免冗余

2. 风险的概率足够低,降低风险

3. 影响的范围足够小,降低风险

4. 影响时长足够短,提高用户体验

接口高可用整体框架

雪崩效应:请求量超过系统处理能力后导致系统性能螺旋快速下降

链式效应:某个故障引起后续一连串的故障

工作十年,浅谈我的服务接口的高可用设计经验

接口高可用设计的几个原则

1、控制依赖处理

能少依赖就少依赖,能不强依赖就不强依赖,如果依赖过多,某个环节出现问题,会导致服务宕掉,引起雪崩效应。

2、避免单点处理

避免单点故障的核心是通过备份或者冗余快速的进行容错,可以考虑主从复制,主主复制等进行备份,避免数据丢失。

3、负载均衡处理

将风险进行分摊避免分险扩散,如果某个服务宕机,不会引起服务不可用,更不会引起雪崩效应。

4、资源隔离处理

隔离的目的将风险控制在可控范围内,降低风险扩散,避免服务宕机

5、接口限流处理

首先来说,限流是保护服务的一种处理方式,目的是将风险控制在可控范围内。

限流是指对进入系统的请求进行限流处理,如果请求量超过了我们系统最大处理能力或者超过了我们指定的处理能力,那么直接拒绝请求,避免因并发量过高,导致服务宕掉。

工作十年,浅谈我的服务接口的高可用设计经验

6、服务熔断处理

和限流类似,熔断也是一种保护措施,目的是将风险控制在可控范围内,避免服务宕机。

熔断,断路(开路)的价值在于限制故障影响范围。

工作十年,浅谈我的服务接口的高可用设计经验

7、异步处理

将同步操作转为异步操作,减少并发量,提高软件的性能。

8、降级方案处理

服务降级属于一种问题发生后的补救措施,降级是指我们划分好系统的核心功能和非核心功能,然后当我们的系统超过最大处理能力之后,直接关闭掉非核心的功能,从而保障核心功能的可用。

9、灰度发布处理

通过灰度发布降低风险影响范围,避免因发布软件时带来影响

10、测试介入处理

通过测试人员提前对系统进行一些破坏性的手段,提前发现潜在问题

继续阅读