分布式系统的复杂性是工程师和开发人员面临的重要挑战。复杂性往往会随着系统的发展而增加，因此积极主动非常重要。让我们来谈谈您可能会遇到哪些类型的复杂性以及在工作中应对它的有效策略。
分布式系统和复杂性
在开发中，分布式系统是相互连接并执行单个任务的计算机网络。每台计算机或节点都有自己的本地内存和处理器，并运行自己的进程。但是，它们使用公共网络进行协调和集中。分布式系统非常可靠；一个组件发生故障不会破坏整个网络。
在集中式计算系统中，一台配备一个处理器和一个内存的计算机负责解决问题。在集中式系统中，虽然有节点，但它们访问中央节点，这可能会导致网络拥塞和速度变慢。集中式系统存在单点故障 — 这是它的一个重要缺点。
复杂
复杂性可以从不同的角度和方面来定义。有两个主要定义比较重要。
在系统理论中，复杂性描述了系统的不同独立部分如何相互作用和通信：它们如何定义彼此之间的交互，它们如何相互依赖，它们有多少依赖关系，以及它们如何在整体内相互作用。
从软件和技术角度来看，复杂性是指软件架构的细节，例如组件的数量。
单体架构
单片架构是集中式系统的一个很好的例子。它表示为单个可部署和单个可执行组件。例如，此类组件可能包含一个用户界面和位于一个位置的不同模块。
虽然这种架构是构建软件的传统架构，但它有几个重要的缺点：
- 无法独立扩展模块
- 越来越难以控制日益复杂的情况
- 缺乏模块独立部署
- 维护庞大的代码数据库具有挑战性
- 技术和供应商的耦合
微服务架构
微服务架构是一种架构风格，也是面向服务架构的一种变体，它将系统构建为松散耦合的服务集合。例如，公司、账户、客户和 UI 表示为部署在多个节点上的单独进程。
所有这些服务都有自己的时时共享数据库，但这可能是一种不好的做法或反模式。
这种架构有一些优点。
- 水平可扩展性是改变游戏规则的关键！您可以水平扩展数据库，也可以水平扩展服务。从技术上讲，任何基础设施组件都可以通过克隆进行水平扩展，但必须解决许多挑战。
- 高可用性和容忍度：当您有多个克隆时，您可以组织一些技术来帮助您避免在崩溃、内存泄漏或断电时出现任何停机。
- 地理分布：如果我们在美国、欧洲或亚洲都有客户，并且我们也希望为客户带来最佳体验，我们就需要在世界各地分发这些服务，并组织更复杂的数据复制技术。
- 技术选择：您可以自由选择您的解决方案。
品质属性
任何系统在某种程度上都具有三个主要质量属性：
- 可靠性：尽管面临挑战，仍能继续正常运行，这意味着具有容错能力或弹性；即使系统现在运行可靠，也不能保证未来的可靠性。性能下降的一个常见原因是负载增加：例如，系统可能从 10,000 个并发用户扩展到 100,000 个，或从 100 万扩展到 1000 万。
- 可扩展性是我们用来描述系统处理增加的负载的能力的术语。需要注意的是，整个系统的可扩展性弱点是由其最薄弱的组件决定的。
- 可维护性是为了让需要使用系统的工程和运营团队的生活更轻松。良好且稳定的抽象有助于降低复杂性，并使系统更易于修改和适应新的使用功能。
主要问题是什么？
“任何可能出错的事情都会出错，而且是在最糟糕的时候。”
——墨菲定律
不可靠的网络
网络不可靠的原因有很多，例如：
- 您的请求可能已丢失。
- 您的请求可能正在队列中等待，稍后将会送达。
- 远程节点可能已发生故障（可能崩溃或断电）。
- 远程节点可能暂时停止响应。
- 远程节点可能已经处理了您的请求，但是响应已在网络上丢失。
- 远程节点可能已经处理了您的请求，但响应已被延迟，将稍后传送。
策略：暂停
解决该问题最简单的方法是在调用方端应用超时逻辑。例如，如果调用方在超时后未收到响应，则它只会抛出错误并向用户显示错误。
策略：重试
在规模化的情况下，我们不能为每个网络问题抛出异常，从而让用户感到不快或延迟系统执行。因此，如果响应表明出现问题，只需重试即可。但如果服务器处理了请求，但只有响应丢失了怎么办？在这种情况下，重试可能会导致严重后果，例如多个订单、付款、交易等。
策略：幂等性
为了避免这种情况，我们可以使用一种名为幂等性的技术。
幂等性的概念是指多次执行同一操作与仅执行一次具有相同的效果。为了实现精确一次语义的属性，可以采用一种解决方案，将幂等性密钥附加到请求中。在使用相同的幂等性密钥重试同一请求时，服务器将验证具有此类密钥的请求是否已被处理，并将仅返回先前的响应。因此，使用相同密钥重试任何次数都不会对系统的行为产生有害影响。
策略：熔断机制
另一种可能有助于防止过载并在发生故障时彻底压垮服务器的模式是断路器。
断路器充当代理，以防止正在维护的调用系统发生故障或现在发生严重故障。 导致它出错的原因有很多：内存泄漏、代码中的错误或出现故障的外部依赖项。 在这种情况下，最好快速失败，而不是冒着连锁故障的风险。
并发和丢失写入
并发是分布式系统中最复杂的挑战之一。并发意味着同时发生多个计算。
因此，当尝试通过不同的操作同时更新帐户余额时会发生什么？如果没有防御机制，很可能会出现竞争条件，这将不可避免地导致写入丢失和数据不一致。在此示例中，两个操作试图同时更新帐户余额。由于它们是并行运行的，因此最后一个完成的操作将获胜，从而导致一个重大问题。为了解决这个问题，可以采用各种技术。
策略：快照隔离
ACID 的首字母缩写代表原子性、一致性、隔离性和持久性。所有流行的 SQL 数据库都实现了这些属性。
- 原子性指定操作无论在哪个阶段发生，要么完全执行，要么失败。它使我们能够确保另一个线程无法看到操作的未完成结果。
- 一致性意味着在成功提交事务并改变状态之前，所有不变量都已定义并且将得到满足。
- ACID 意义上的隔离性是指并发执行的事务彼此隔离。有一种最严格的可序列化隔离级别，即按顺序处理所有事务，但流行的数据库中主要使用另一种称为快照隔离的级别。
- 持久性保证一旦事务提交，所有数据都会被安全存储。
这一级别的关键思想是数据库跟踪记录的版本，并且无法提交当前事务之外已修改的事务。
策略：比较并设置
大多数 NoSQL 数据库不提供 ACID 属性，而是选择 BASE，此类数据库会进行比较并使用集合。此操作的目的是避免丢失更新，方法是仅当值自上次读取后未发生更改时才允许更新。如果当前值与您之前读取的值不匹配，则更新无效，必须重试读取-修改-写入循环。
例如，Cassandra 提供轻量级事务，允许您利用各种IF、IF NOT EXISTS和IF EXISTS条件来防止并发问题。
策略：租赁
另一个潜在的解决方案是租约模式。为了说明这一点，请考虑必须以独占方式更新资源的场景。租约模式需要首先获取具有资源到期期限的租约，然后更新它，最后归还租约。
如果发生故障，租约将自动到期，从而允许另一个线程访问资源。虽然这种技术非常有益，但存在进程暂停和时钟不同步的风险，这可能会导致并行资源访问出现问题。
双重写入问题
双重写入问题是分布式系统中出现的一个挑战，特别是当必须保持多个数据源或数据库同步时。为了说明这一点，请考虑这样一种情况：必须将新数据存储在数据库中，并将消息发送到 Kafka。由于这两个操作不是原子的，因此在发布新消息时可能会失败。
如果在发送消息时尝试进行事务，则会导致更麻烦的情况。如果事务提交失败，外部系统可能已经被告知实际上并未发生的更改。
策略：交易发件箱
一个潜在的解决方案是实现事务性发件箱。这涉及将事件存储在与操作本身相同的事务中的“OutboxEvents”表中。由于该过程的原子性，如果事务失败，则不会存储任何数据。
另一个必要的组件是 Relay，它会定期轮询 OutboxEvents 表并将消息发送到目的地。这种方法可以实现至少一次交付保证。不过，这并不是问题，因为由于网络不可靠，所有消费者都必须是幂等的。
策略：日志跟踪
构建自定义事务发件箱的替代解决方案是利用数据库事务日志和自定义连接器直接从该日志读取并将更改发送到目的地。
这种方法有其优点和缺点。例如，它需要与数据库解决方案耦合，但允许在应用程序中编写较少的代码。
不可靠的时钟
时间跟踪是任何软件或基础设施的一个基本方面，因为它可以实现超时、到期和指标收集。然而，时钟的可靠性在分布式系统中是一个重大挑战，因为时间的准确性取决于各个计算机的性能，而这些计算机的时钟可能比其他计算机快或慢。
计算机使用的时钟主要有两种类型：日历时钟和单调时钟。日历时钟根据特定日历返回日期和时间，并且通常与网络时间协议 (NTP) 同步。但是，延迟和网络问题可能会影响同步过程，导致时钟不同步。单调时钟不断前进，使其适合测量持续时间。
然而，单调增加的值对于每台计算机都是唯一的，这限制了它们在多服务器日期和时间比较中的使用。实现高精度时钟同步是一项具有挑战性的任务。在大多数情况下，这种解决方案的必要性并不明显。然而，在遵守法规需要使用精确时间协议的情况下，可以使用精确时间协议，尽管这将需要大量投资。
可用性和一致性
CAP定理 认为，任何分布式数据存储只能满足三个保证中的两个。然而，由于网络不可靠性并不是一个可以显著影响的因素，因此在网络分区的情况下，唯一可行的选择是在可用性或一致性之间做出选择。
考虑这样一种情况：两个客户端从不同的节点读取数据：一个从主节点读取数据，另一个从跟随节点读取数据。复制配置为在领导者更改后更新跟随节点。但是，如果由于某种原因，领导者停止响应，会发生什么情况？
这可能是崩溃、网络分区或其他问题。在高可用性系统中，必须指定新的领导者，但我们如何在现有的追随者之间进行选择？为了解决这个问题，必须采用分布式共识算法。然而，在深入研究该算法的细节之前，必须全面了解各种类型的一致性。
一致性类型
用于描述保证的一致性主要有两类。
- 弱一致性，或者最终是一致性，意味着如果您停止对领导者进行更改，则一段时间后数据将在所有跟随者上同步。
- 强一致性是一种属性，它确保系统中的所有节点同时看到相同的数据，无论它们访问的是哪个节点。
策略：分布式共识算法（例如 Raft）
回到领导者崩溃的问题，需要选举新的领导者。这个问题乍一看很容易，但实际上，在选择适当的方法时，必须考虑很多条件和权衡。
根据 Raft 协议，如果跟随者在指定时间内未从领导者收到数据或心跳，则将开始新的领导者选举过程。每个复制单元（整体写入节点或多个分片）都与一组 Raft 日志和操作系统进程相关联，这些进程维护日志并将更改从领导者复制到跟随者。
Raft 协议保证跟随者按照领导者生成日志记录的顺序接收日志记录。只要一半的跟随者确认收到提交记录并将其写入 Raft 日志，就会在领导者上提交用户事务。
策略：从领导者那里读出
一种可能有效且简单的策略是，由刚刚保存新数据的用户从关注者那里读取，以避免复制滞后。
而不是结论
从单体架构到微服务，每种方法都有各自的优势和挑战。虽然单体架构提供了简单性，但它们往往在可扩展性和可维护性方面存在问题，因此开发人员倾向于采用更模块化、更可扩展的微服务架构。
讨论的核心是复杂性的管理，复杂性表现为各种形式，从网络不可靠性到并发问题和双重写入问题。超时、重试、幂等性和断路器等策略提供了有效的工具来减轻与不可靠网络相关的风险，而快照隔离、比较和设置以及租约等技术则解决了并发和丢失写入的挑战。
此外，时钟不可靠这一关键问题凸显了分布式系统中精确时间同步的重要性，解决方案包括从 NTP 同步到精确时间协议。此外，CAP 定理提醒我们可用性和一致性之间的固有权衡，因此需要彻底了解 Raft 等分布式共识算法。
总之，掌握分布式系统中的复杂性迷宫需要采取多方面的方法，将理论知识与实践策略相结合。通过采用这些策略并不断适应分布式计算不断发展的格局，工程师和开发人员可以满怀信心地应对复杂性，确保其系统在不断变化的挑战面前具有可靠性、可扩展性和可维护性。
