布式应用是现代软件开发行业的主食。它们是云存储服务的关键，并允许大规模的Web应用来保持反应。随着程序员构建这些系统，它们需要基本构建块，它们可以用作起点并在共享词汇中通信。
这是分布式系统设计模式变得非常宝贵的地方。虽然它们有时过度使用，但了解如何使用它们是一个关键的技能招聘人员正在寻找，并且在先进的系统设计访谈中脱颖而出至关重要。
今天，我们将探讨五个优秀分布式系统设计模式，以帮助您了解其优缺点，何时使用它们。
什么是分布式系统设计模式?
设计模式是验证的，并测试了每个符合特定用例的系统的方法。它们不是实现，而是抽象的结构化系统。多年来，许多不同的开发人员已经开发和更新了大多数设计模式，这意味着它们通常是非常有效的起点。
设计模式是构建块，允许程序员从现有知识中拉出，而不是从每个系统开始从头开始。他们还为系统设计创建了一组标准模型，帮助其他开发人员看到其项目如何与给定系统接口。
创造设计模式在构建新对象时提供基准。结构图案定义了解决方案的整体结构。行为模式描述了对象以及它们如何互相通信。
分布式系统设计模式是开发分布式系统时使用的设计模式，这些系统基本上是计算机和数据中心的集合，充当最终用户的一台计算机。这些分布式设计模式概述了一个软件架构，了解不同的节点如何彼此通信，节点处理每个任务，以及用于不同任务的过程流程。
在设计大规模云计算和可扩展的微服务软件系统的分布式系统架构时广泛使用这些模式。
分布式设计模式的类型
大多数分布式的设计模式基于与他们一起工作的功能的三个类别之一：
- 对象通信：描述要通信的系统的不同组件的消息传递协议和权限。
- 安全性：处理机密性，完整性和可用性问题，以确保系统从未经授权的访问中获得安全。
- 事件驱动：描述生产，检测，消费和对系统事件的响应的模式。
1. 命令和查询责任分离(CQRS)
CQRS模式侧重于分离分布式系统的读写操作以提高可扩展性和安全性。此模型使用命令将数据写入持久存储和查询以定位和获取数据。
这些由从用户接收请求的命令中心处理。然后命令中心获取数据并进行必要的修改，保存数据，并通知读取服务。然后，读取服务更新读取模型以显示对用户的更改。
好处：
- 通过委派任务来降低系统复杂性。
- 在业务逻辑和验证之间执行明确的分离。
- 帮助通过他们的工作进行分类。
- 减少共享数据的意外更改的数量。
- 减少具有修改对数据访问的实体数。
缺点：
- 在命令和读取模型之间需要恒定的前后通信。
- 发送高吞吐量查询时会导致延迟增加。
- 没有沟通服务进程之间的手段。
用例：
CQRS最适合像SQL或NoSQL数据库管理系统等数据密集型应用程序。它对数据沉重的微服务架构也有助于。对于处理有状态申请非常重要，因为作者/读者区别有助于不可变态。
2. 两阶段提交(2PC)
2PC与CQR类似于其交易方法和依赖核心命令，但分区由它们的类型处理，并且它们的完成阶段。这两个阶段是准备阶段(中央控制告诉服务准备数据)和提交阶段(其向服务发送服务发送准备的数据)。
默认情况下，2PC系统中的所有服务都被锁定，这意味着它们无法发送数据。锁定时，服务填写准备阶段，因此他们已准备好发送一次解锁。协调器逐个解锁服务并请求其数据。如果服务未准备好提交其数据，则协调器将继续进行另一个服务。一旦发送了所有准备的数据，所有服务都会解锁以等待协调员的新任务。
2PC基本上确保只有一个服务可以一次操作，这使得该过程更具抵抗和始终如一的CQRS。
好处：
- 由于缺乏并发请求而持续和抵抗错误。
- 可扩展 - 可以轻松处理大数据池，因为它可以从单个机器处理数据。
- 允许同时隔离和数据共享。
缺点：
- 由于其同步性质，不容易容易容易出现瓶颈和阻塞。
- 需要比其他设计模式更多的资源。
用例：
2PC最适合分布式系统，该系统处理高赌注交易操作，以满足资源效率的准确性。它是抵抗错误，即使在比例下也很容易跟踪错误。
3. SAGA
SAGA是一种异步模式，不使用中央控制器，而是完全在服务之间进行通信。这克服了先前覆盖了同步模式的一些缺点。
SAGA使用活动总线允许服务在微服务系统中彼此通信。总线发送和接收服务之间的请求，每个参与服务都会创建本地事务。然后，参与服务每次都会发出其他服务的活动。其他服务所有人都听事件。接收该活动的第一个服务将执行所需的操作。如果该服务无法完成操作，则会发送到其他服务。
这种结构类似于2PC设计，因为如果一个人无法完成任务，则服务是循环的。但是，Saga删除了中央控制元素，以更好地管理流量并减少所需的前后通信量。
好处：
- 个人服务可以处理更长的交易。
- 伟大的分布式系统由于分散化。
- 由于服务与服务之间的对等通信减少了瓶颈。
缺点：
- 异步自主权使得难以跟踪哪些服务正在进行各个任务。
- 由于复杂的编排难以调试。
- 比以前的模式更少的服务隔离。
用例：
SAGA的分散方法非常适合可扩展的无服务器功能，可立即处理许多并行请求。AWS在许多功能中使用基于SAGA的设计，如步骤和LAMBDA函数。
4. 复制负载平衡服务(RLB)
RLBS模式是最简单，最常用的设计模式。在最基本的级别，它由多个相同的服务组成所有向中央负载均衡器报告。每个服务都能够处理任务，如果失败，可以复制。负载均衡器从最终用户接收请求，并以循环方式或有时使用更复杂的路由算法将其分发给服务。
重复的服务确保应用程序为用户请求维护高可用性，并且如果服务的一个实例应该失败，则可以重新分发工作。
RLBS通常与Azure Kubernetes一起使用，它是Microsoft的开源容器编排技术，提供基于工作流程的自动服务缩放。
好处：
- 来自最终用户的视图的一致性。
- 可以快速从失败的服务中恢复。
- 高度可扩展，提供更多服务。
- 非常适合并发。
缺点：
- 基于负载均衡器算法的不一致性能。
- 资源密集型管理服务。
用例：
RLBS非常适合全面的工作负载不一致，但必须保持低延迟，例如Netflix或亚马逊Prime等娱乐Web应用程序。
5. 分片服务
基于副本的设计的替代方案是创建各种服务，每个服务只能完成某种请求。这被称为“分片”，因为您将请求流拆分为多个不相等的部分。例如，您可能有一个接受所有缓存请求的碎片服务，并且另一个仅处理高优先级请求。负载平衡器在进入并将其分发到适当的碎片时，请评估每个请求。
分叉服务通常用于构建状态服务，因为状态的大小通常太大，对于单个无状态容器通常太大。分片允许您缩放单个碎片以满足国家的大小。
分叉服务还允许您更快地处理高优先级请求。致力于高优先级请求的碎片始终可用于处理它们进入的那一刻而不是将它们放在队列中的请求。
好处：
- 允许您为公共请求进行分级碎片。
- 易于优先考虑请求。
- 由于自然排序而调试简单。
缺点：
- 可以是资源密集的，以维护许多碎片。
- 如果碎片不成比例地使用碎片，则会导致性能损失。
用例：
当系统在请求类型中收到可预测的不平衡时，碎片服务是最好的，但有些请求有优先级。
