系统架构设计：从子系统到服务的深度剖析

### 系统架构设计：从子系统到服务的深度剖析 #### 1. 基于数据生命周期划分架构边界 在寻找系统架构边界时，数据生命周期是一个重要的考量维度。在数据的整个生命周期中，与之交互的参与者及其需求会不断变化。引入数据生命周期的概念有助于发现一些容易被忽视的子系统，这些子系统通常位于数据生命周期的起始和结束阶段。这实际上是将单一职责原则（SRP）应用到了数据库层面，目的是找出所有与数据交互的参与者，并将这些变化源隔离到各自的有界上下文中，即形成自主子系统。 从事件优先的思维出发，我们先关注领域聚合（名词），进而发现更多的领域事件（动词）以及产生这些事件的参与者。这有助于我们找到所谓的“慢数据”，而我们通常更关注“快数据”，即系统中参与者持续创建的事务性数据。事务性数据往往依赖参考数据，并且政府法规可能对事务性数据的保留时长有记录管理要求。我们需要将这些变化源解耦，以免影响事务性和分析性数据的灵活性和性能。 从数据生命周期的角度来看，系统可能包含以下子系统： - **上游子系统**：拥有主数据模型，为下游子系统提供参考数据。 - **中间的事务性子系统**：提供系统的核心功能。 - **下游子系统**：包括分析子系统和记录管理子系统。 此外，对于遗留系统，也需要将其划分为独立的子系统。 #### 2. 遗留系统的处理 遗留系统是一个特殊情况。我们可以采用事件优先的迁移模式——绞杀者模式来集成遗留系统。具体做法是在遗留系统周围创建一个防腐层，使其能够通过产生和消费领域事件与新系统进行交互。这样可以创建一个渐进式的迁移路径，在迁移完成之前保持遗留系统的运行和同步，从而降低风险。完成迁移后，我们可以直接移除遗留子系统，这将替换原则扩展到了子系统层面。 我们将遗留系统视为一个具有隔离舱的自主子系统，通过设计隔离舱来消除新旧系统之间的耦合，并通过控制攻击面和提供背压来保护遗留基础设施。我们可以使用与其他子系统相同的隔离舱技术，即分离的云账户和外部领域事件。 #### 3. 创建子系统隔离舱 在系统中，并非所有子系统都具有相同的重要性。对于许多企业来说，面向客户的部分通常是最重要的子系统。我们的目标是强化系统中的所有架构边界，使自主团队能够放心地进行实验，因为即使团队犯错，影响范围也能得到控制。在子系统层面，我们要让自主组织能够独立管理其自主子系统。以下是创建子系统隔离舱的两种方法： ##### 3.1 分离的云账户 云账户天然具有隔离作用，我们应充分利用这一点来保护系统。很多时候，我们会在一个云账户中加载过多不相关的工作负载，这会使所有工作负载面临风险。至少，开发和生产环境应该使用不同的账户。更好的做法是为每个子系统的每个环境都设置单独的账户，这样可以在某个账户出现故障时控制影响范围。使用多个账户有以下好处： | 好处 | 说明 | | ---- | ---- | | 控制技术债务 | 随着账户内资源数量的增加，技术债务会自然积累。当一个账户中有过多工作负载时，很难看清整体情况，学习曲线也会增加。标记资源虽然有帮助，但容易遗漏。工程师可能会因为犯错风险高而抗拒进行更改，系统发生灾难性故障的可能性也会增加。 | | 提高安全性 | 通过限制每个账户的攻击面来改善安全状况。只需将团队成员分配到正确账户的正确角色，就能轻松限制访问。如果发生安全漏洞，影响范围也仅限于该账户内的资源。对于遗留系统，我们可以尽量减少能够访问企业网络的账户数量，每个环境最好只设一个。 | | 减少资源竞争 | 许多云资源在账户层面有软限制，当事务量超过阈值时会限制访问。工作负载数量增加会提高达到这些限制的可能性，一次拒绝服务攻击或一个工作负载的失控错误可能会使其他工作负载资源匮乏。虽然我们可以请求提高这些限制，但这需要时间。而将账户分配给各个子系统后，默认限制可能就有足够的空间。 | | 简化成本分配 | 我们可以将一个账户内的所有资源分配到一个成本桶中，无需标记，这样可以避免标记不完整时出现未分配成本的情况。同时，也更容易识别孤立资源，从而减少隐藏成本。 | | 增强可观测性和治理 | 监控工具会按账户标记所有指标，这使得按子系统进行过滤和警报成为可能。发生故障时，有限的影响范围也有助于进行根本原因分析，并缩短平均恢复时间。 | ##### 3.2 外部领域事件 我们已经讨论过使用事件作为契约的好处、向后兼容性的重要性，以及通过事件进行异步通信如何在架构边界上形成隔离舱。现在我们需要区分内部和外部领域事件。 在子系统内部，服务之间通过内部领域事件进行通信。这些事件的定义相对容易更改，因为拥有这些服务的自主团队在同一个自主组织中协同工作。随着子系统的成熟，事件定义会从混乱逐渐稳定下来。我们可以利用健壮性原则来促进这种变化。这些事件还会包含用于审计目的的原始信息，但这些信息在子系统外部并无重要意义。 而在子系统边界之间，我们需要更规范的团队沟通和协调来促进这些契约的更改。这种沟通会增加前置时间，这与我们的目标相悖。我们希望限制其对内部前置时间的影响，以便在自主子系统内自由创新。因此，我们通过外部领域事件（有时称为集成事件）进行所有子系统间的通信。这些外部事件的契约更加稳定，对向后兼容性有更高的要求，其契约变化缓慢，有助于在子系统之间形成隔离舱。在六边形架构术语中，外部事件代表子系统的端口。 以下是子系统通信的 mermaid 流程图： ```mermaid graph LR A[ ```