网站建设又叫什么软件,网站空间有哪些,直播app开发多少钱,渐变配色网站一、走近韧性设计模式
#xff08;一#xff09;基本概念
韧性设计模式是一系列在软件工程中用于提高系统韧性的设计原则、策略、实践和模式。韧性#xff08;Resilience#xff09;在这里指的是系统对于各种故障、异常和压力的抵抗能力#xff0c;以及在遭受这些挑战后…
一、走近韧性设计模式
一基本概念
韧性设计模式是一系列在软件工程中用于提高系统韧性的设计原则、策略、实践和模式。韧性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、请求失败、网络中断等都是经常发生的情况而不是例外。因此一个具备韧性的系统需要在部分故障的情况下仍能够正常运行即使面对较大规模的故障系统也能够提供大部分的服务。
“拥抱故障”的理念强调了开发者需要在系统的全生命周期中考虑系统如何应对故障确保系统在故障发生时的状态是符合预期的。这并不意味着构建一个能够抵御任何故障的完美系统而是要知道并接受系统能够在哪些情况下抵御故障在哪些情况下会降级以及在哪些情况下无法抵御。
韧性和成本在大多数情况下是矛盾的。在不那么关键的系统中为了保证在罕见的自然灾害下的可用性而花费数倍的成本可能得不偿失。因此理性的做法是在“保证高可靠所花费的成本”和“因停服而造成的潜在损失”之间找到一个合理的平衡点。
三避免重大事故关键方向
理解故障和事故的不可避免性后确实需要通过一系列工作来尽量减小事故的发生概率和降低事故造成的损失。 主要的关键方向如下 降低事故发生的概率 通过健康检查、冗余、负载均衡等手段预防已知故障的发生提高系统的可用性。这是一种常见的做法可以有效降低系统出现常见故障的概率。 减少故障时长 在故障发生时关键是尽快恢复系统的正常状态。快速检测故障、自动切换到备用系统、采用断路器模式等手段都有助于减少故障时长从而降低损失。 减小故障影响范围 在大规模系统中故障可能只影响系统的一部分。通过设计系统的舱壁模式、服务隔离等可以限制故障的影响范围避免故障在整个系统中扩散。
以上三个方向共同作用有助于降低事故的发生概率缩短故障时长减小故障造成的损失。另外在大规模系统中事故定级是一个常见的做法通过事故定级可以更有针对性地采取措施提高系统的韧性。
二、保持简单的架构
KISS原则Keep It Simple and Stupid或者Keep It Simple, Stupid是一项设计原则强调在设计和开发中应保持简单性。这个原则的核心思想是大多数系统如果保持简单而不是变得复杂则效果最佳。KISS原则起源于美国海军在20世纪60年代提出并后来在计算机科学和软件工程领域广泛应用。
无论采用哪种表述“保持简单”是KISS原则的核心含义。原则强调设计和实现应该简明直观避免引入不必要的复杂性。这并不是要求完全排斥复杂性而是要在确保必要功能的同时尽量避免使系统变得难以理解、维护和扩展的复杂性。
一同质化部署
同质化部署是一种部署策略它指的是在部署时将系统的所有组件集成在一起然后部署到系统的每个实例上。这意味着系统的每个实例上运行的应用是完全一样的所有组件被打包成一个整体。这种部署方式的集成方式一般包括一起编译打包成二进制程序或JAR包也可以封装成包含所有组件的镜像。 同质化部署的好处在于简化了部署和运行时系统的复杂度。在部署时不需要为每个组件准备不同的构建和部署脚本也不必关注不同组件在启动过程中的依赖关系。在运行时由于所有实例都是相同的处理问题实例的替代变得更加容易。如果某个实例宕机或者出现容量问题可以使用其他的实例来替代而且这个热切换过程不需要拉起新的实例速度很快也更容易做到无感知切换。
二最少关键依赖原则
最少关键依赖原则是软件设计中的一项原则强调在设计和实现系统时应该尽量减少系统对外部组件、服务或库的依赖。核心思想是降低系统受到外部变化的影响提高系统的稳定性和可维护性。
假设我们正在设计一个健身软件用户可以通过该软件制定训练计划、记录健身数据等。健身软件中的用户数据直接依赖外部身体数据传感器和第三方社交媒体平台。软件在用户训练时直接获取身体数据传感器的数据并将健身记录分享到第三方社交媒体平台。
问题分析
系统直接依赖外部身体数据传感器和第三方社交媒体平台增加了软件对这两个外部组件的耦合性。如果身体数据传感器或社交媒体平台发生变化需要修改健身软件可能导致软件其他部分的不稳定性。
应用最少关键依赖原则
重新设计健身软件引入中间层或者服务代理。软件不再直接依赖外部身体数据传感器和第三方社交媒体平台而是通过中间层或服务代理来与这两个服务通信。中间层或服务代理负责与外部服务进行交互并将结果传递给健身软件。
具体实现方案 引入数据同步服务通过引入数据同步服务将身体数据传感器的数据同步到软件的数据存储中。健身软件直接从数据存储中获取用户的身体数据降低了对传感器的直接依赖。 使用社交媒体 API通过引入社交媒体 API软件通过 API 与社交媒体平台通信将用户的健身记录分享到平台。这样软件不再直接依赖特定的社交媒体平台实现。
三简化部署
在很多系统中启动新实例时的初始化配置脚本、安装动态链接库以及从外部服务获取初始化配置等操作会导致启动速度变慢且容易出错。这种做法在容器化部署的环境下可以通过简化部署来优化。
具体实践中可以将这些初始化操作从首次启动阶段迁移到更早期的构建阶段使用 Dockerfiles 或 Docker Compose 在构建镜像的过程中完成初始化工作。这种方式可以显著提高启动速度尤其是在扩容和故障恢复的场景下。
三、冗余、无状态和幂等
冗余、无状态和幂等这三个基础的韧性模式是在设计可靠系统时的重要原则通常被视为基础或必要条件。
一冗余普适基础
冗余是提升系统可用性的一种最简单且有效的方法。在高可用架构的设计中采用冗余设计意味着引入多个相同或相似的系统组件实例以降低单点故障的影响提升系统的整体可用性。冗余的方式可以涵盖硬件层面、软件层面、数据层面等。
二无状态服务
无状态服务是指服务在处理请求时不依赖于本地存储数据而是通过外部存储或其他服务获取所需的信息。这种设计模式对单次请求的处理不依赖于其他请求每个请求都包含处理所需的全部信息或者可以从外部获取。 不依赖本地存储 无状态服务不在本地存储数据而是从外部获取所需的信息。这使得服务可以更容易水平扩展因为每个服务实例都是相同的而不需要考虑本地数据的同步和共享问题。 独立请求处理 单次请求的处理不依赖于其他请求的状态每个请求都是独立的。这样的设计适用于绝大部分在线业务服务特别是那些数据保存在远程数据库中且请求之间没有明显关联的场景。 存储计算分离 无状态服务的状态数据被下沉到外部存储系统实现了存储和计算的分离。这使得集群管理和调度更加简单支持更灵活的负载均衡和水平扩展。
考虑一个健身软件的案例该软件需要记录用户的运动数据。在传统有状态的设计中每个服务实例可能会维护用户的运动数据状态而在无状态设计中用户的运动数据被存储在外部的分布式数据库中服务实例通过API从数据库获取用户的运动数据。这样设计可以实现水平扩展任意服务实例都可以处理任意用户的请求而不依赖于本地存储数据。同时用户的运动数据可以被多个服务实例同时访问需要注意并发控制的问题。
三幂等性
在计算机科学中幂等性是指一个操作的多次执行和一次执行具有相同的效果。换句话说无论操作执行多少次系统的状态都与执行一次时的状态相同。这个概念对于分布式系统和网络通信中的操作非常重要因为在这些场景下由于各种原因可能会导致请求的重复执行。
为什么需要幂等性
在负载均衡和分布式系统中由于网络不稳定性、超时、重试等原因同一个请求可能被发送到不同的服务实例上。如果某个操作不是幂等的那么在请求失败后的重试可能会导致系统状态的变化进而引起不一致的问题。幂等性的设计可以确保即使请求被重复执行对系统状态的影响也是相同的从而防止因为重试而引发的副作用。
幂等性的实现方法 业务逻辑设计 最好的方式是从业务逻辑上入手设计具备天然幂等性的操作。这意味着无论执行多少次结果都是相同的。例如创建订单服务可以设计成只有在订单号不存在时才创建订单如果订单号已存在则返回已存在的订单这样无论多次执行都只会有一个订单记录。 唯一标识和检查 使用唯一标识来防止重复操作。每个请求可以携带一个唯一标识服务在处理请求时先检查该标识是否已经处理过如果处理过则直接返回结果避免重复执行。 幂等键 引入幂等键Idempotence Key客户端在每次请求时都携带一个唯一的键服务端通过这个键来判断请求是否已经处理过。这样即使同一个请求被发送多次服务端通过幂等键就能够判断出重复请求并进行幂等性处理。
通过保证操作的幂等性系统可以更好地适应分布式环境和不稳定的网络条件确保在各种情况下都能够维持一致的状态。
四、松耦合设计
在软件设计中耦合度是指两个模块之间相互依赖的程度。松耦合Low Coupling是一种设计原则旨在降低系统内部组件之间的依赖关系从而提高系统的灵活性和可维护性。低耦合的系统中一个模块的变化不太可能影响到其他模块模块之间的关联性较弱。 五、Event Sourcing全异步架构模式 六、最终一致
