全球应用的三项职责（第2部分）

Source: Dev.to

在第 1 部分，我解释了在全球规模下，信任是架构的一部分——不是一种感觉，而是系统必须强制执行并加以证明的东西。
在本文中，我将描述使全球系统能够有机增长的三项不同职责。

---

职责 1 – 执行（业务逻辑）

它的作用

• 运行业务逻辑
• 处理请求
• 处理事件
• 推进工作流

常用 AWS 服务

• AWS Lambda
• Step Functions
• EventBridge
• DynamoDB
• SQS
• SNS

回答的核心问题

系统为业务做了什么？

优化目标

• 正确性
• 可扩展性
• 弹性
• 隔离性

成为问题的情形

• 将合规逻辑直接嵌入业务代码中
• 在各处随意添加“以防万一”的日志且没有结构
• 将运维关注点泄漏到领域逻辑中

执行代码应专注于完成工作，而不是解释或为其辩护。

---

职责 2 – 审计 / 证明

存在的原因

团队外部的人员会提出诸如：

• 谁拥有访问权限？
• 谁修改了生产环境？
• 哪些数据流向了哪里？
• 当时是否启用了日志记录？

这些问题关乎 证明，而不是调试。

表达此职责的 AWS 服务

• AWS CloudTrail
• IAM 配置和访问记录
• 配置历史与保留策略
• AWS Audit Manager

常见陷阱

• 重复使用执行或可观测性数据作为证据（日志格式会变，指标被聚合，仪表盘会被删除，开发者的记忆各不相同）。

证据必须具备

• 完整性
• 一致性
• 防篡改性

由于这些要求，审计必须与执行分离。

---

职责 3 – 运维 / 健康监控

回答的核心问题

系统当前是否健康？

（不是 “租户 X 发生了什么？” 或 “谁改动了这个？”）

常见关注点

• 错误是否在增加？
• 延迟是否在恶化？
• 问题是区域性的还是全局性的？

答案来源

• 指标
• 警报
• SLO
• 仪表盘

使用的 AWS 服务

• Amazon CloudWatch 指标与仪表盘
• Amazon Managed Prometheus
• 服务遥测与警报

这些服务在健康信号超过阈值时触发调查和行动。

---

将职责分离的好处

• 更清晰的对话

  • 与其问 “我们应该集中日志吗？” 不如问 “我们在满足哪项职责？”
  • 与其问 “为什么我不能直接在指标中添加 tenantId？” 不如问 “这是运营信号还是会计问题？”
  • 与其问 “治理为什么拖慢了我们？” 不如问 “我们在满足哪项职责？”

• 明确的权衡 – 决策时考虑相关职责，减少隐藏的复杂性。

• 在大规模下降低混乱 – 带租户 ID 的指标、审计仪表盘以及通过 CloudTrail 调试各自单独有意义，但混合使用会导致信号模糊。

从治理的角度来看，全球系统之所以失败，并不是因为它们是分布式的，而是因为我们让单一系统一次性承担所有职责。将执行、审计和运营健康分离，就把复杂性放在了应该放的位置。