architecture-paradigm-space-based

基于空间的架构范式

适用场景

• 需要弹性扩展的高流量应用
• 需要内存数据网格的系统

不适用场景

• 分布式缓存属于过度设计的低流量应用
• 强一致性优先于可用性的系统

采用此范式的时机

• 流量或状态数据量超过单个数据库节点的承载能力时。
• 延迟要求需要使用靠近处理单元的内存数据网格时。
• 需要线性扩展时，可通过将工作负载分区到多个相同且可独立运行的单元来实现。

采用步骤

1. 划分工作负载：将流量和数据划分为多个处理单元，每个单元由一个复制的数据缓存提供支持。
2. 设计数据网格：选择合适的缓存技术、复制策略（同步或异步）和数据淘汰策略。
3. 协调持久化：实现向持久化数据存储写入的直写或后写策略，包括对账流程。
4. 实现故障转移处理：设计领导者选举或心跳机制，以便在节点丢失时验证恢复过程且不丢失数据。
5. 验证可扩展性：开展负载和混沌测试，确认系统的弹性和自愈能力。

关键交付成果

• 一份架构决策记录（ADR），详细说明所选网格技术、分区方案和持久性策略。
• 用于扩展处理单元以及从“脑裂”场景中恢复的运行手册。
• 一套监控工具，用于跟踪缓存命中率、复制延迟和故障转移事件。

风险与缓解措施

• 最终一致性问题：
  • 缓解措施：正式记录数据新鲜度服务等级协议（SLA），并为无法立即保持一致的数据实现补偿逻辑。
• 运维复杂性：
  • 缓解措施：数据网格的编排需要成熟的自动化能力。尽早投入生产级工具和自动化。
• 成本：
  • 缓解措施：内存网格可能消耗大量资源。实施严格的利用率监控和自动扩缩策略，以有效控制成本。

具体组件

此范式的实现通常包含的工具和抽象的术语。它们不是依赖项，也不是 tools: frontmatter。

• data-grid-platform：Hazelcast、Apache Ignite 或类似工具；内存分区式数据存储
• replication-manager：将写入异步传输到持久化存储和其他区域
• load-tester：让网格负载超过单区域上限，以验证横向扩展能力

退出标准

• 在部署任何处理单元之前，ADR 已记录所选网格技术、分区方案、复制策略 （同步或异步）、数据淘汰策略和持久性 SLA。
• 已编写用于扩展处理单元以及从脑裂场景中恢复的运行手册，并已在非生产环境中 演练。
• 负载和混沌测试确认系统能够处理 >= 2 倍预期峰值流量且不丢失数据，并在 晋升至生产环境之前完成测量。
• 一套监控工具能够跟踪缓存命中率、复制延迟和故障转移事件，并在系统接收实时流量 之前设置好告警阈值。