08-16

架构设计

分布式事务实战：Outbox、Saga、TCC、幂等与补偿

# 分布式事务实战：Outbox、Saga、TCC、幂等与补偿 微服务把一次业务操作拆到了多个数据库：订单创建成功、库存扣减成功、支付却失败，系统就会进入不一致状态。分布式事务的目标不是让所有服务“像单库事务一样简单”，而是根据业务不变量选择正确的提交、重试和补偿方式。 ## 一、先判断是否真的需要

11

0

0

08-16

架构设计

分布式系统入门：CAP、BASE、一致性模型与工程取舍

# 分布式系统入门：CAP、BASE、一致性模型与工程取舍 单机系统变成分布式系统后，最大的变化不是“机器变多了”，而是失败变成常态：网络可能延迟、丢包或分区；节点可能宕机、暂停或重启；时钟也不一定一致。设计分布式系统的核心，是在这些不确定性下仍然给业务一个可解释、可恢复的结果。 ## 一、为什么需

11

0

0

08-09

架构设计

生产级容灾演练：RTO、RPO、故障注入、切换与回切完整流程

# 生产级容灾演练：RTO、RPO、故障注入、切换与回切完整流程 没有演练过的容灾方案，只能算文档。一次合格演练必须验证人员、流程、权限、数据、网络、应用和监控，而不只是证明备用机器可以启动。 ## 一、定义目标与边界 RTO 是允许恢复业务的最长时间，RPO 是允许丢失数据的最大时间窗口。应按业务

11

0

0

08-09

架构设计

生产系统容量规划：从业务指标、压测模型到扩容阈值

# 生产系统容量规划：从业务指标、压测模型到扩容阈值 容量规划不是简单地看 CPU 是否超过 80%，而是把业务增长、流量形态、依赖瓶颈和扩容提前量转化为可执行的资源计划。 ## 一、明确业务容量指标 先收集日活、订单量、峰值 QPS、并发连接、请求/响应大小、读写比例、数据日增量、保留周期和增长率

10

0

0

08-08

架构设计

架构评审流程：从申请、预审、正式评审到整改闭环

架构评审的目的不是证明方案“足够高级”，而是在投入大量研发和运维成本之前，尽早发现需求遗漏、单点故障、容量不足、安全风险、数据问题和不可运维设计。一套有效的评审流程必须有明确入口、固定材料、可追踪结论和整改闭环。 一、评审适用范围 出现以下情况时，应发起架构评审： 新系统、新平台或重要基础设施建设；

8

0

0

08-08

架构设计

一次完整的架构评审应该检查什么：从需求、可靠性到成本的实战清单

架构评审不是让几位专家对着架构图“挑问题”，而是在投入大量建设成本之前，系统性识别需求遗漏、单点风险、容量不足、安全缺陷和不可运维设计。好的评审结论应当能够转化为明确行动。 一、评审前需要哪些材料 业务背景、范围与关键用户流程； 功能需求和非功能需求； 系统上下文图、组件图、部署图与数据流图； 容量

9

0

0

08-08

架构设计

高可用、容灾、备份和双活有什么区别：架构设计与选型指南

高可用、容灾、备份和双活经常被混在一起讨论，但它们解决的问题并不相同。备份不能直接提供高可用，双活也不能代替备份。架构设计前必须先确定业务希望抵御哪类故障。 一、高可用 高可用关注局部组件故障时，业务能否继续提供服务。常见手段包括多实例、负载均衡、主从切换、健康检查和自动拉起。 例如两个应用实例部署

14

0

0

08-08

架构设计

架构师必须掌握的非功能需求：可靠性、性能、安全、成本与可运维性

很多系统功能都能正常演示，上线后却频繁超时、难以扩容、无法审计或成本失控，根本原因往往不是功能缺失，而是非功能需求没有被明确设计和验证。 一、什么是非功能需求 功能需求回答系统提供什么能力，非功能需求定义这些能力应达到的质量水平。它们必须可量化、可测试，并且与业务重要性一致。 二、可靠性与可用性 可

10

0

0

08-08

架构设计

如何从业务需求设计系统架构：从目标、约束到可落地方案

架构设计最常见的错误，是在需求还没有说清楚之前就开始选择数据库、消息队列或 Kubernetes。正确顺序应当是先理解业务，再确定质量目标和约束，最后选择能够满足目标的技术方案。 一、先确认业务目标 架构师首先要知道系统为谁服务、解决什么问题、怎样衡量成功。建议至少回答： 核心用户是谁，最重要的业务

9

0

0

08-08

架构设计

从运维工程师到架构师：思维方式、能力模型与成长路线

很多运维工程师已经能够熟练处理 Linux、网络、数据库、容器和监控，却仍然觉得自己距离“架构师”很远。差距通常不在工具数量，而在看问题的层次：运维关注系统能不能运行，架构师还要回答为什么这样设计、业务增长后如何演进、故障会影响多大范围，以及成本是否值得。 一、从执行任务转向解决业务问题 接到“建设

11

0

0