云上高可用系统-韧性设计模式

2024-01-29 05:28

本文主要是介绍云上高可用系统-韧性设计模式,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

一、走近韧性设计模式

(一)基本概念

韧性设计模式是一系列在软件工程中用于提高系统韧性的设计原则、策略、实践和模式。韧性(Resilience)在这里指的是系统对于各种故障、异常和压力的抵抗能力,以及在遭受这些挑战后能够快速自我恢复的能力。韧性设计模式旨在确保系统在面对不可避免的故障时,能够保持高可用性、可靠性和性能。

这些设计模式不仅关注系统的开发阶段,还包括系统的部署、运维和监控阶段,形成了一个全面的韧性设计理念。通过采用这些模式,可以降低系统遭受故障时的影响,并在出现问题时快速、自动地进行恢复。

一些常见的韧性设计模式整合如下:

模式描述应用场景
重试模式 (Retry Pattern)在面对临时性故障时,系统自动尝试重新执行失败的操作。网络问题、服务瞬时不可用等。
断路器模式 (Circuit Breaker Pattern)在系统检测到连续的失败请求时,断开对失败服务的请求,避免连锁故障。避免对故障服务的过度请求,提高整体系统稳定性。
超时模式 (Timeout Pattern)为每个操作设置最大执行时间,避免长时间等待导致资源浪费。防止系统在某个操作上无限期阻塞。
限流模式 (Rate Limiting Pattern)控制系统在一定时间内的请求速率,防止系统过载。防止大量请求导致系统资源耗尽。
负载均衡模式 (Load Balancer Pattern)将请求分发到多个相同的服务实例,提高系统的扩展性和稳定性。均衡系统负载,避免单一节点故障影响整体服务。
舱壁模式 (Bulkhead Pattern)将系统的不同模块隔离开来,避免一个模块的故障影响其他模块。确保故障在一个区域内隔离,不会波及整个系统。
异步消息模式 (Asynchronous Messaging Pattern)通过消息队列将系统的不同组件解耦,提高系统的弹性和可恢复性。降低组件之间的依赖,减少同步调用风险。
灾备模式 (Disaster Recovery Pattern)设计系统的备份和恢复策略,以应对灾难性故障。数据中心故障、自然灾害等情况下确保系统可用性。
自愈模式 (Self-Healing Pattern)系统能够自动检测并恢复从故障中恢复的能力。监控系统状态,自动修复故障。
版本控制模式 (Feature Toggling / Feature Flags Pattern)通过动态切换系统的特性,使得可以在运行时开启或关闭功能。灰度发布、紧急关闭某个功能等。

这些模式的综合应用能够帮助构建更具韧性的系统,提高系统的可用性和稳定性。在云上部署和运行的环境中,韧性设计尤为重要,因为这些环境更容易受到各种因素的影响。

(二)“拥抱故障”理念

对故障和事故的定义如下:

定义例子
故障(Failure):系统不能执行预期功能的状态。宕机、请求超时、内存溢出等。
事故(Accident):故障是系统最终用户可感知的,或者造成了业务损失的情况。下单服务不可用,导致订单损失约10万单。

在故障与事故的定义中,系统不能执行预期功能的状态被定义为故障,而当故障对系统最终用户可感知,或者造成了业务损失时被定义为事故。

在大规模系统中,故障是常态。尤其在管理数千个实例的大规模系统中,宕机、系统出现Bug、请求失败、网络中断等都是经常发生的情况,而不是例外。因此,一个具备韧性的系统需要在部分故障的情况下仍能够正常运行,即使面对较大规模的故障,系统也能够提供大部分的服务。

“拥抱故障”的理念强调了开发者需要在系统的全生命周期中考虑系统如何应对故障,确保系统在故障发生时的状态是符合预期的。这并不意味着构建一个能够抵御任何故障的完美系统,而是要知道并接受系统能够在哪些情况下抵御故障,在哪些情况下会降级,以及在哪些情况下无法抵御。

韧性和成本在大多数情况下是矛盾的。在不那么关键的系统中,为了保证在罕见的自然灾害下的可用性而花费数倍的成本可能得不偿失。因此,理性的做法是在“保证高可靠所花费的成本”和“因停服而造成的潜在损失”之间找到一个合理的平衡点。

(三)避免重大事故关键方向

理解故障和事故的不可避免性后,确实需要通过一系列工作来尽量减小事故的发生概率和降低事故造成的损失。

主要的关键方向如下:

  1. 降低事故发生的概率: 通过健康检查、冗余、负载均衡等手段,预防已知故障的发生,提高系统的可用性。这是一种常见的做法,可以有效降低系统出现常见故障的概率。

  2. 减少故障时长: 在故障发生时,关键是尽快恢复系统的正常状态。快速检测故障、自动切换到备用系统、采用断路器模式等手段都有助于减少故障时长,从而降低损失。

  3. 减小故障影响范围: 在大规模系统中,故障可能只影响系统的一部分。通过设计系统的舱壁模式、服务隔离等,可以限制故障的影响范围,避免故障在整个系统中扩散。

以上三个方向共同作用,有助于降低事故的发生概率,缩短故障时长,减小故障造成的损失。另外,在大规模系统中,事故定级是一个常见的做法,通过事故定级,可以更有针对性地采取措施,提高系统的韧性。

二、保持简单的架构

KISS原则(Keep It Simple and Stupid,或者Keep It Simple, Stupid)是一项设计原则,强调在设计和开发中应保持简单性。这个原则的核心思想是,大多数系统如果保持简单而不是变得复杂,则效果最佳。KISS原则起源于美国海军,在20世纪60年代提出,并后来在计算机科学和软件工程领域广泛应用。

无论采用哪种表述,“保持简单”是KISS原则的核心含义。原则强调设计和实现应该简明直观,避免引入不必要的复杂性。这并不是要求完全排斥复杂性,而是要在确保必要功能的同时,尽量避免使系统变得难以理解、维护和扩展的复杂性。

(一)同质化部署

同质化部署是一种部署策略,它指的是在部署时将系统的所有组件集成在一起,然后部署到系统的每个实例上。这意味着系统的每个实例上运行的应用是完全一样的,所有组件被打包成一个整体。这种部署方式的集成方式一般包括一起编译打包成二进制程序或JAR包,也可以封装成包含所有组件的镜像。

同质化部署的好处在于简化了部署和运行时系统的复杂度。在部署时,不需要为每个组件准备不同的构建和部署脚本,也不必关注不同组件在启动过程中的依赖关系。在运行时,由于所有实例都是相同的,处理问题实例的替代变得更加容易。如果某个实例宕机或者出现容量问题,可以使用其他的实例来替代,而且这个热切换过程不需要拉起新的实例,速度很快,也更容易做到无感知切换。

(二)最少关键依赖原则

最少关键依赖原则是软件设计中的一项原则,强调在设计和实现系统时,应该尽量减少系统对外部组件、服务或库的依赖。核心思想是降低系统受到外部变化的影响,提高系统的稳定性和可维护性。

假设我们正在设计一个健身软件,用户可以通过该软件制定训练计划、记录健身数据等。健身软件中的用户数据直接依赖外部身体数据传感器和第三方社交媒体平台。软件在用户训练时,直接获取身体数据传感器的数据,并将健身记录分享到第三方社交媒体平台。

问题分析:

  • 系统直接依赖外部身体数据传感器和第三方社交媒体平台,增加了软件对这两个外部组件的耦合性。
  • 如果身体数据传感器或社交媒体平台发生变化,需要修改健身软件,可能导致软件其他部分的不稳定性。

应用最少关键依赖原则:

  • 重新设计健身软件,引入中间层或者服务代理。
  • 软件不再直接依赖外部身体数据传感器和第三方社交媒体平台,而是通过中间层或服务代理来与这两个服务通信。
  • 中间层或服务代理负责与外部服务进行交互,并将结果传递给健身软件。

具体实现方案:

  • 引入数据同步服务:通过引入数据同步服务,将身体数据传感器的数据同步到软件的数据存储中。健身软件直接从数据存储中获取用户的身体数据,降低了对传感器的直接依赖。

  • 使用社交媒体 API:通过引入社交媒体 API,软件通过 API 与社交媒体平台通信,将用户的健身记录分享到平台。这样,软件不再直接依赖特定的社交媒体平台实现。

(三)简化部署

在很多系统中,启动新实例时的初始化配置脚本、安装动态链接库以及从外部服务获取初始化配置等操作会导致启动速度变慢,且容易出错。这种做法在容器化部署的环境下可以通过简化部署来优化。

具体实践中,可以将这些初始化操作从首次启动阶段迁移到更早期的构建阶段,使用 Dockerfiles 或 Docker Compose 在构建镜像的过程中完成初始化工作。这种方式可以显著提高启动速度,尤其是在扩容和故障恢复的场景下。

三、冗余、无状态和幂等

冗余、无状态和幂等这三个基础的韧性模式是在设计可靠系统时的重要原则,通常被视为基础或必要条件。

(一)冗余:普适基础

冗余是提升系统可用性的一种最简单且有效的方法。在高可用架构的设计中,采用冗余设计意味着引入多个相同或相似的系统组件实例,以降低单点故障的影响,提升系统的整体可用性。冗余的方式可以涵盖硬件层面、软件层面、数据层面等。

(二)无状态服务

无状态服务是指服务在处理请求时不依赖于本地存储数据,而是通过外部存储或其他服务获取所需的信息。这种设计模式对单次请求的处理不依赖于其他请求,每个请求都包含处理所需的全部信息,或者可以从外部获取。

  • 不依赖本地存储: 无状态服务不在本地存储数据,而是从外部获取所需的信息。这使得服务可以更容易水平扩展,因为每个服务实例都是相同的,而不需要考虑本地数据的同步和共享问题。

  • 独立请求处理: 单次请求的处理不依赖于其他请求的状态,每个请求都是独立的。这样的设计适用于绝大部分在线业务服务,特别是那些数据保存在远程数据库中且请求之间没有明显关联的场景。

  • 存储计算分离: 无状态服务的状态数据被下沉到外部存储系统,实现了存储和计算的分离。这使得集群管理和调度更加简单,支持更灵活的负载均衡和水平扩展。

考虑一个健身软件的案例,该软件需要记录用户的运动数据。在传统有状态的设计中,每个服务实例可能会维护用户的运动数据状态,而在无状态设计中,用户的运动数据被存储在外部的分布式数据库中,服务实例通过API从数据库获取用户的运动数据。这样设计可以实现水平扩展,任意服务实例都可以处理任意用户的请求,而不依赖于本地存储数据。同时,用户的运动数据可以被多个服务实例同时访问,需要注意并发控制的问题。

(三)幂等性

在计算机科学中,幂等性是指一个操作的多次执行和一次执行具有相同的效果。换句话说,无论操作执行多少次,系统的状态都与执行一次时的状态相同。这个概念对于分布式系统和网络通信中的操作非常重要,因为在这些场景下,由于各种原因可能会导致请求的重复执行。

为什么需要幂等性:

在负载均衡和分布式系统中,由于网络不稳定性、超时、重试等原因,同一个请求可能被发送到不同的服务实例上。如果某个操作不是幂等的,那么在请求失败后的重试可能会导致系统状态的变化,进而引起不一致的问题。幂等性的设计可以确保即使请求被重复执行,对系统状态的影响也是相同的,从而防止因为重试而引发的副作用。

幂等性的实现方法:

  1. 业务逻辑设计: 最好的方式是从业务逻辑上入手,设计具备天然幂等性的操作。这意味着无论执行多少次,结果都是相同的。例如,创建订单服务可以设计成只有在订单号不存在时才创建订单,如果订单号已存在,则返回已存在的订单,这样无论多次执行都只会有一个订单记录。

  2. 唯一标识和检查: 使用唯一标识来防止重复操作。每个请求可以携带一个唯一标识,服务在处理请求时先检查该标识是否已经处理过,如果处理过则直接返回结果,避免重复执行。

  3. 幂等键: 引入幂等键(Idempotence Key),客户端在每次请求时都携带一个唯一的键,服务端通过这个键来判断请求是否已经处理过。这样,即使同一个请求被发送多次,服务端通过幂等键就能够判断出重复请求并进行幂等性处理。

通过保证操作的幂等性,系统可以更好地适应分布式环境和不稳定的网络条件,确保在各种情况下都能够维持一致的状态。

四、松耦合设计

在软件设计中,耦合度是指两个模块之间相互依赖的程度。松耦合(Low Coupling)是一种设计原则,旨在降低系统内部组件之间的依赖关系,从而提高系统的灵活性和可维护性。低耦合的系统中,一个模块的变化不太可能影响到其他模块,模块之间的关联性较弱。

五、Event Sourcing:全异步架构模式

六、最终一致

这篇关于云上高可用系统-韧性设计模式的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/655846

相关文章

不懂推荐算法也能设计推荐系统

本文以商业化应用推荐为例,告诉我们不懂推荐算法的产品,也能从产品侧出发, 设计出一款不错的推荐系统。 相信很多新手产品,看到算法二字,多是懵圈的。 什么排序算法、最短路径等都是相对传统的算法(注:传统是指科班出身的产品都会接触过)。但对于推荐算法,多数产品对着网上搜到的资源,都会无从下手。特别当某些推荐算法 和 “AI”扯上关系后,更是加大了理解的难度。 但,不了解推荐算法,就无法做推荐系

基于人工智能的图像分类系统

目录 引言项目背景环境准备 硬件要求软件安装与配置系统设计 系统架构关键技术代码示例 数据预处理模型训练模型预测应用场景结论 1. 引言 图像分类是计算机视觉中的一个重要任务,目标是自动识别图像中的对象类别。通过卷积神经网络(CNN)等深度学习技术,我们可以构建高效的图像分类系统,广泛应用于自动驾驶、医疗影像诊断、监控分析等领域。本文将介绍如何构建一个基于人工智能的图像分类系统,包括环境

水位雨量在线监测系统概述及应用介绍

在当今社会,随着科技的飞速发展,各种智能监测系统已成为保障公共安全、促进资源管理和环境保护的重要工具。其中,水位雨量在线监测系统作为自然灾害预警、水资源管理及水利工程运行的关键技术,其重要性不言而喻。 一、水位雨量在线监测系统的基本原理 水位雨量在线监测系统主要由数据采集单元、数据传输网络、数据处理中心及用户终端四大部分构成,形成了一个完整的闭环系统。 数据采集单元:这是系统的“眼睛”,

嵌入式QT开发:构建高效智能的嵌入式系统

摘要: 本文深入探讨了嵌入式 QT 相关的各个方面。从 QT 框架的基础架构和核心概念出发,详细阐述了其在嵌入式环境中的优势与特点。文中分析了嵌入式 QT 的开发环境搭建过程,包括交叉编译工具链的配置等关键步骤。进一步探讨了嵌入式 QT 的界面设计与开发,涵盖了从基本控件的使用到复杂界面布局的构建。同时也深入研究了信号与槽机制在嵌入式系统中的应用,以及嵌入式 QT 与硬件设备的交互,包括输入输出设

JAVA智听未来一站式有声阅读平台听书系统小程序源码

智听未来,一站式有声阅读平台听书系统 🌟 开篇:遇见未来,从“智听”开始 在这个快节奏的时代,你是否渴望在忙碌的间隙,找到一片属于自己的宁静角落?是否梦想着能随时随地,沉浸在知识的海洋,或是故事的奇幻世界里?今天,就让我带你一起探索“智听未来”——这一站式有声阅读平台听书系统,它正悄悄改变着我们的阅读方式,让未来触手可及! 📚 第一站:海量资源,应有尽有 走进“智听

在JS中的设计模式的单例模式、策略模式、代理模式、原型模式浅讲

1. 单例模式(Singleton Pattern) 确保一个类只有一个实例,并提供一个全局访问点。 示例代码: class Singleton {constructor() {if (Singleton.instance) {return Singleton.instance;}Singleton.instance = this;this.data = [];}addData(value)

【区块链 + 人才服务】可信教育区块链治理系统 | FISCO BCOS应用案例

伴随着区块链技术的不断完善,其在教育信息化中的应用也在持续发展。利用区块链数据共识、不可篡改的特性, 将与教育相关的数据要素在区块链上进行存证确权,在确保数据可信的前提下,促进教育的公平、透明、开放,为教育教学质量提升赋能,实现教育数据的安全共享、高等教育体系的智慧治理。 可信教育区块链治理系统的顶层治理架构由教育部、高校、企业、学生等多方角色共同参与建设、维护,支撑教育资源共享、教学质量评估、

软考系统规划与管理师考试证书含金量高吗?

2024年软考系统规划与管理师考试报名时间节点: 报名时间:2024年上半年软考将于3月中旬陆续开始报名 考试时间:上半年5月25日到28日,下半年11月9日到12日 分数线:所有科目成绩均须达到45分以上(包括45分)方可通过考试 成绩查询:可在“中国计算机技术职业资格网”上查询软考成绩 出成绩时间:预计在11月左右 证书领取时间:一般在考试成绩公布后3~4个月,各地领取时间有所不同

系统架构师考试学习笔记第三篇——架构设计高级知识(20)通信系统架构设计理论与实践

本章知识考点:         第20课时主要学习通信系统架构设计的理论和工作中的实践。根据新版考试大纲,本课时知识点会涉及案例分析题(25分),而在历年考试中,案例题对该部分内容的考查并不多,虽在综合知识选择题目中经常考查,但分值也不高。本课时内容侧重于对知识点的记忆和理解,按照以往的出题规律,通信系统架构设计基础知识点多来源于教材内的基础网络设备、网络架构和教材外最新时事热点技术。本课时知识

计算机毕业设计 大学志愿填报系统 Java+SpringBoot+Vue 前后端分离 文档报告 代码讲解 安装调试

🍊作者:计算机编程-吉哥 🍊简介:专业从事JavaWeb程序开发,微信小程序开发,定制化项目、 源码、代码讲解、文档撰写、ppt制作。做自己喜欢的事,生活就是快乐的。 🍊心愿:点赞 👍 收藏 ⭐评论 📝 🍅 文末获取源码联系 👇🏻 精彩专栏推荐订阅 👇🏻 不然下次找不到哟~Java毕业设计项目~热门选题推荐《1000套》 目录 1.技术选型 2.开发工具 3.功能