任何旨在实现完全自动化和自给自足的系统都必须能够自我修复和自适应。 至少,它需要能够自我监控并在服务和基础结构级别上执行某些操作。
两个轴可以代表系统可能执行的一组动作。 通过基础架构和服务之间的差异来代表一组动作。 另一个轴可以通过活动的类型来解释,一端是自我修复,而另一端是自适应。
当应用于基础架构时,最常见的自我修复类型是重新创建故障节点或故障节点。 当基础架构需要适应变化的条件时,可以扩展节点。 自我修复主要是关于重新安排失败的服务。 当系统条件发生变化时,它应该通过扩展某些服务来自适应。
系统如何区分自适应和自我修复? 它什么时候应该选择执行另一项操作?
每个系统都有一个设计。 它可能会长时间保持不变,或者可以每隔几分钟重新设计一次。 系统设计变更的频率将静态系统与动态系统区分开。 在整个软件行业的短暂历史中,我们都倾向于持久的设计。 在实施该系统之前,我们将花费大量时间进行规划,甚至花费更长的时间来设计系统。 难怪我们并不急于花费数月甚至数年的时间来做所有的事情,只是在发布后的一周内进行更改。 我们使用瀑布模型工作,其中所有事情都预先计划并在很长的阶段执行。 在大多数情况下,结果将是失败的,但我们现在将不再进行讨论。 如果您在该行业工作了一段时间,您可能知道瀑布是什么。 希望您的公司改变了,或者您改变了公司。 瀑布已经死了,持久的静态设计也随之消失了。
动态系统的特点是设计的变化非常频繁,而不是连续。 我们将设计一种服务,该服务将运行五个副本,但仅在一周后将其更改为七个。 我们将设计由27个节点组成的基础架构,但稍后将其更改为30个。 每当我们有意识地决定更改系统内部的某些内容时,我们都会更改设计。 这些更改中的每一个都是由于初始错误计算或影响系统的外部条件的修改而导致的。 流量的稳定增长需要更改设计。 它要求我们扩展一个或多个服务的副本数量。 在其他所有条件都相同的情况下,增加副本数需要增加基础结构资源。 我们需要添加更多的节点来承载这一增长。 如果不是这种情况,我们将系统过度配置。 我们有空闲资源,可以在扩展服务时使用。
自适应是一种更改系统设计的自动化方法。 当我们(人类)更改它时,我们通过评估指标来做到这一点。 至少我们应该那样做。 否则,我们将咨询一个水晶球,聘请算命先生或纯粹猜测。 如果我们可以根据指标制定决策,那么系统也可以。 无论是谁更改系统,每次更改都是对设计的修改。 如果我们使过程自动化,则会获得自适应。
自我修复不会影响设计。 相反,它遵循。 如果设计要有五个副本,并且只有四个正在运行,则系统应尽力添加另一个副本。 而且这并不总是关于增加数量。 如果副本数量超出设计数量,则应删除其中一些副本。 相同的逻辑适用于系统的节点或任何其他可量化部分。 长话短说,自我修复就是要确保始终遵循设计。
T> 自适应是关于一种将更改应用于系统设计的自动化方法。 自我修复的目的是确保在任何给定时刻遵循设计。 当我们将自适应与自我修复相结合时,结果是一个真正的动态,有弹性且具有容错能力的系统,具有高可用性。
系统可以调整或修复服务或基础架构。 修复后最常见的动作是重新创建失败的事物,而适应通常是关于缩放。 它们是代表一个动态和自给自足的系统的四个象限。
翻译自: https://www.javacodegeeks.com/2017/06/four-quadrants-dynamic-self-sufficient-system.html