系统分析与架构设计速查
需求分析与 UML、架构风格与模式、分布式与高可用、API 与集成、容量与性能设计、技术选型：系统设计速查。
需求分析与建模61 条
用例、UML 与需求规格要点
功能需求与非功能需求
需求分两类：功能需求描述系统做什么，非功能需求描述系统做得怎么样（性能、可用性、安全、可维护性等质量属性与外部约束），两类都需可验证、可度量。
用户故事三段式写法
用户故事用“作为某角色，我希望完成某目标，以便获得某价值”的句式表达需求，强调卡片、对话、确认三要素，细节在沟通与验收标准中沉淀。
验收标准与 Given-When-Then
验收标准描述故事在什么条件下算完成，常用 Given 前置条件、When 动作、Then 可观察结果的格式，是开发、测试与业务对齐的判定依据。
顺序图（Sequence Diagram）
按时间顺序展示对象间的消息交互：生命线表示参与者实例，激活条表示执行期，实心箭头为同步消息、开放箭头为异步消息、虚线开放箭头为返回消息。
聚合与聚合根（Aggregate）
聚合是一致性边界：外部只能通过聚合根访问内部实体与值对象，一次事务只修改一个聚合；跨聚合一致性通过领域事件实现最终一致。
用例与用例描述模板
用例描述参与者为达成目标与系统的一次完整交互，常用要素包括参与者、目标层级、前置条件、主成功场景、扩展场景与后置条件。
类图（Class Diagram）
描述类、属性、操作与类之间的关系，是结构建模的基础图；可见性符号 + 公开、- 私有、# 受保护、~ 包内可见，静态成员加下划线。
限界上下文（Bounded Context）
限界上下文是模型一致性的边界：边界内术语与模型含义唯一，边界外允许同名不同义；它通常与服务/团队的边界对齐。
用例图（UML Use Case Diagram）
用例图展示参与者、用例与系统边界的关系，用于划定系统范围并对齐功能清单；它不表达交互顺序，顺序需由描述或顺序图补充。
状态机图（State Machine Diagram）
描述对象在生命周期内的状态与转换：转换由事件触发、可带守卫条件与动作，含初始伪状态与终止状态，适合订单、工单、设备等有明确状态的领域。
IEEE/ISO 29148 需求工程标准
ISO/IEC/IEEE 29148 是需求工程的过程与文档标准，给出需求规格说明应具备的质量特征（必要、无歧义、完整、一致、可行、可验证、可追踪等）与文档结构参考。
实体与值对象（Entity / Value Object）
实体由身份标识区分（订单号相同即同一订单），值对象由属性值区分且不可变（金额、地址、时间区间）；值对象不可变可安全共享并简化并发。
C4 模型（Context/Container/Component/Code）
按抽象层级递进描述软件架构：上下文层看系统与外部关系，容器层看可独立运行单元，组件层看容器内部划分，代码层按需展开，服务不同读者。
UML 2.5.1 图分类与用途
UML 2.5.1 定义 14 种图：7 种结构图与 7 种行为图。选图依据“要表达什么信息”，而不是团队习惯或工具默认。
ISO/IEC 25010 软件质量模型
软件产品质量模型，把质量属性分为功能适合性、性能效率、兼容性、易用性、可靠性、安全性、可维护性、可移植性八个特性，常用于整理非功能需求清单。
需求获取方法与技巧
需求获取常用技术包括访谈、引导式工作坊、现场观察、问卷、文档分析与原型演示；不同技术适合不同信息类型，组合使用可降低遗漏。
领域事件（Domain Event）
领域事件表示领域中已经发生的事实，命名用过去时（订单已提交）；它用于解耦聚合间协作，与对外发布的集成事件在用途与结构上有所区别。
实体关系图（ERD）
用实体、属性与关系描述数据模型，主流记法有 Chen 记法与鸦脚（Crow's Foot）记法；关系基数包括一对一、一对多与多对多，多对多通常需拆解为关联实体。
干系人分析与影响力矩阵
识别受系统影响的角色，按影响力与关注度分类并制定沟通策略；干系人遗漏会直接变成后期的需求变更与验收风险。
MoSCoW 优先级划分
把需求分为 Must have、Should have、Could have、Won't have 四档，Must 通常控制在总量的六成上下，用于范围谈判与发布切片。
通用语言（Ubiquitous Language）
在限界上下文内，业务人员与开发人员使用同一套术语，代码类名、接口字段与文档用词保持一致，减少翻译损耗与理解偏差。
质量属性场景（六要素）
把非功能需求写成可测试场景，包含刺激源、刺激、环境、制品、响应与响应度量六个要素，是 ATAM 评估与性能需求澄清的通用表达方式。
活动图（Activity Diagram）
描述流程与并发：动作节点、控制流、决策与合并（菱形）、分叉与汇合（粗线）、对象节点与泳道；语义上以令牌流动驱动执行。
INVEST 用户故事质量检查
INVEST 是评估用户故事质量的六条准则：Independent 独立、Negotiable 可协商、Valuable 有价值、Estimable 可估算、Small 小、Testable 可测试。
用户故事地图
沿用户活动的时间顺序铺开任务与故事，形成骨架与故事两层视图，用于检查需求覆盖、划分发布切片并对齐范围。
事件风暴（Event Storming）
Alberto Brandolini 提出的协作建模工作坊：用便签铺开领域事件、命令、聚合、策略与热点，快速对齐业务流程并识别限界上下文。
领域服务与应用服务
领域服务承载跨聚合的领域规则且无状态；应用服务负责编排用例：加载聚合、调用领域逻辑、提交事务、发布事件与权限校验，二者职责不应混同。
Example Mapping 需求澄清会
用四种颜色卡片澄清一个故事：黄=故事、蓝=规则、绿=示例、红=待确认问题；通常控制在 25 分钟左右，卡片过多说明故事需要拆分。
Gherkin 语法与实例化需求
Gherkin 用 Feature、Scenario、Given、When、Then、Background、Scenario Outline 与 Examples 描述可执行的需求示例，既是沟通语言也是自动化测试入口。
4+1 视图模型
Kruchten 提出的架构视图方法：逻辑视图、进程视图、开发视图、物理视图，再加场景视图串联与验证，用于多受众分视角描述架构。
类关系：泛化、实现、聚合与组合
类之间常见六种关系：泛化、实现、关联、聚合、组合、依赖；聚合与组合的区别在于部分能否脱离整体独立存在，菱形画在整体一侧。
影响地图（Why-Who-How-What）
影响地图从目标出发逐层展开：Why 为什么做、Who 影响谁、How 如何影响其行为、What 交付什么功能，用于避免直接跳到功能清单。
仓储（Repository）
仓储为聚合提供持久化的领域视角：按聚合根存取、隐藏存储细节，让领域层不依赖具体数据库与 ORM。
软件需求规格说明书（SRS）
SRS 是需求基线的正式载体，通常包含范围与目标、总体描述、功能需求、外部接口需求、质量属性、约束与验证方法；现代实践常用轻量模板加需求工具替代长篇文档。
用例关系：include 与 extend
include 表示基础用例必然执行被包含的公共行为；extend 表示在满足条件时把可选行为插入基础用例。两者箭头方向相反，语义常被混用。
部署图（Deployment Diagram）
描述运行期物理与逻辑部署：节点（«device»、«executionEnvironment»）、制品、部署规格与通信路径，用于评审服务器、容器与网络拓扑。
Kano 模型与需求分类
Kano 模型按用户满意度把需求分为基本型、期望型、兴奋型、无差异与反向型，通过正反向问卷归类，帮助区分必须做好与超出预期的部分。
上下文映射（Context Map）
描述限界上下文之间的关系模式：合作关系、共享内核、客户-供应商、遵奉者、防腐层、开放主机服务、发布语言、各行其道等，用于管理跨边界依赖。
需求追踪矩阵
建立需求到设计、实现与测试的双向追踪，用于评估变更影响、检查覆盖率与支撑审计；常见形式是需求 ID 与工作项、用例、测试用例的对照表。
顺序图组合片段（alt/opt/loop/par）
组合片段把顺序图分块并标注交互类型：alt 条件分支、opt 可选、loop 循环、par 并行、break 中断、critical 临界区、neg 无效交互，条件写在方括号内。
组件图（Component Diagram）
按可替换部件描述系统结构：组件、端口、提供接口（棒棒糖符号）、需求接口（插座符号）与装配连接件，适合表达模块边界与依赖方向。
WSJF 加权最短作业优先排序
WSJF 用（用户价值 + 时间紧迫性 + 风险降低与机会使能）除以工作规模得到排序分值，规模越大分值越低，促使团队拆分大颗粒需求。
业务规则与决策表
业务规则是“在什么条件做什么决定”的约束，散落在代码里会难以变更；用决策表或决策树把条件与动作显式列出来，便于与业务逐格确认。
需求基线与变更控制
需求基线是评审通过的稳定版本，后续变更需走影响分析、评估与审批流程；基线的作用是让范围变化可见、可管理，而不是冻结需求。
BPMN 2.0 业务流程建模
面向业务流程的建模符号：池与泳道、任务、网关、事件与子流程；网关区分排他、并行、包含等语义，适合跨部门流程梳理与流程引擎落地。
多重性（Multiplicity）标注
多重性表示关联某一端可对应的实例数量范围，常见写法 1、0..1、*、1..*、n..m；标注在靠近对应类的一端，读法从一端读到另一端。
RICE 评分排序法
RICE 用触达人数、影响程度、信心度与投入成本计算优先级：RICE = Reach × Impact × Confidence ÷ Effort，适合增长类需求排序。
领域术语表（Glossary）
术语表汇总业务概念、英文名、定义、别名与禁用叫法，是通用语言的落地载体；它让需求、接口与代码使用同一套词。
包图（Package Diagram）
用包与包间依赖组织模型元素，支持 «import» 与 «access» 等关系；常用于检查分层依赖方向与循环依赖。
用户旅程地图（User Journey Map）
按时间顺序描述用户达成目标的阶段、触点、行为、情绪与痛点，用于发现需求缺口与体验断点，是需求发现阶段的常用工具。
数据流图（DFD）
结构化分析方法的核心图型：用外部实体、处理过程、数据存储与数据流四类元素描述数据流动，按上下文图、0 层、1 层逐级分解。
arc42 架构文档模板
arc42 是开源的架构文档模板，按目标与约束、上下文、策略、构建块、运行时、部署、横切概念、决策、质量、风险、术语等章节组织，适合中小团队裁剪使用。
复合状态与历史伪状态
复合状态内部嵌套子状态机，可划分多个区域并行运行；浅历史 H 记住最近子状态，深历史 H* 恢复嵌套层次；用于复杂流程的分层建模。
原型与线框（Prototype / Wireframe）
低保真线框用于快速讨论信息结构与流程，高保真原型用于可用性测试与需求确认；原型的目标是澄清需求，不是提前交付承诺。
对象图（Object Diagram）
对象图是某一时刻的实例快照：对象、对象间的链接与属性取值，常用于构造测试数据、解释类图中的复杂结构。
领域故事讲述（Domain Storytelling）
用图形符号加口头叙事描述领域：谁（角色）对什么（工作对象）做了什么（活动），边画边讲，快速暴露术语歧义与流程断点。
通信图（Communication Diagram）
UML 2 之前的协作图，语义与顺序图等价：以对象链接为中心，消息用序号标注顺序，如 1、1.1、2，适合展示对等对象间的多轮交互。
时序图（Timing Diagram）
以时间轴与状态轴展示单个或多个对象的状态取值随时间的变化，可标注持续时间约束与消息，常用于实时、嵌入式与协议时序建模。
交互概览图（Interaction Overview Diagram）
把活动图与交互图结合：节点可以是交互引用（ref）或内联交互，控制流表达分支与并发，用于概览一个场景由哪些交互组成。
组合结构图（Composite Structure Diagram）
展示类或组件内部由哪些部件构成、端口如何连接，把内部装配关系显式化，适合表达复杂组件的内聚结构。
剖面图与构造型（Profile / Stereotype）
剖面图定义 UML 的扩展机制：通过构造型 «stereotype»、标记值与约束为特定领域（如 SysML、实时系统）定制建模语言。
架构风格与模式58 条
分层、微服务、事件驱动与 CQRS
微服务架构风格
按业务能力把系统拆成可独立部署的小服务，各自拥有数据存储并通过轻量协议通信；带来独立演进与弹性收益，同时引入分布式事务、运维与治理成本。
分层架构（Layered Architecture）
按技术职责分层（表现层、业务层、持久层、数据库层），上层依赖下层；封闭层要求请求逐层经过，开放层允许跨层访问以换取性能。
架构风格总览
架构风格是一组经过验证的结构组织方式：单体类包括分层、管道、微内核、面向服务，分布式类包括服务化、事件驱动、空间型、编排驱动 SOA 与微服务；选型即取舍。
事件驱动架构（EDA）
组件通过事件的产生与消费协作，生产者不直接调用消费者；吞吐与解耦能力突出，但可观测性、错误处理与一致性复杂度显著上升。
架构特征（-ilities）与取舍
架构特征是非功能维度的设计目标：可用性、可伸缩性、弹性、性能、安全性、可部署性、可测试性与可维护性等；它们相互制约，必须排出优先级。
CQRS 命令查询职责分离
把写模型（命令）与读模型（查询）分离，各自可采用不同结构与存储；读侧可针对查询优化，写侧专注于一致性与业务规则，代价是最终一致与复杂度。
发布-订阅模式
发布者把消息发送到主题，多个订阅者各自消费；解耦生产者与消费者，支持一对多广播与异步削峰，代价是消息顺序、重复消费与积压治理。
依赖注入与控制反转
依赖注入把依赖的创建与使用分离：对象声明所需依赖，由外部（容器或组合根）注入；它是实现依赖倒置原则的常用手段，利于测试与替换实现。
SOLID 五原则
面向对象设计的五条原则：单一职责、开闭、里氏替换、接口隔离与依赖倒置；用于指导类与模块的职责划分和依赖方向。
事件溯源（Event Sourcing）
以事件序列作为状态的事实来源，当前状态由事件重放得到；配合快照控制重放成本，事件需版本化并可兼容演进。
GoF 设计模式分类
经典设计模式分为创建型、结构型与行为型共 23 种；模式是交流词汇与重构目标，引入前应先确认存在对应变化点，避免为模式而模式。
六边形架构（端口与适配器）
领域核心通过端口定义所需与所提供的能力，适配器实现具体技术（HTTP、数据库、消息）；应用核心不依赖框架与基础设施，便于替换与测试。
表现层模式：MVC / MVP / MVVM
三种经典表现层模式的区别在于视图与逻辑的耦合方式：MVC 由控制器处理输入，MVP 通过呈现器与被动视图交互，MVVM 借助数据绑定自动同步视图与视图模型。
服务化架构（粗粒度服务）
把系统拆为数量较少、边界清晰的粗粒度服务（如按业务域划分），共享数据库或按服务分库均可；复杂度低于微服务，适合多数中型系统起步。
单体到微服务的演进路径
常见路径是先把单体模块化、识别稳定边界，再按变更频率与伸缩需求逐步外移服务；一次性重写往往风险高于渐进式拆分。
整洁架构（Clean Architecture）
用依赖规则组织代码：越内层越稳定、越抽象，越外层越具体；用例（Use Case）承载应用逻辑，框架、数据库与交付机制都是可替换细节。
绞杀者模式（Strangler Fig）
在旧系统外围逐步长出新实现，通过路由把流量从旧系统分批迁移到新系统，旧部分随迁移完成逐步退役；适合无法停机重写的遗留系统改造。
DRY、KISS 与 YAGNI
三条通用设计原则：DRY 指知识的唯一来源（不是禁止任何重复代码），KISS 指优先选择简单方案，YAGNI 指不实现当前不需要的能力。
n 层架构与物理分层
n 层指物理部署分层（如 Web 层、应用层、数据库层各自独立部署），与逻辑分层是两个维度；分层部署便于按层扩容与隔离故障。
服务粒度判定
服务粒度按事务边界、团队边界、变更频率与数据耦合综合判断；过粗则失去独立演进价值，过细则出现大量跨服务调用与协调成本。
边车模式（Sidecar）
把日志采集、代理、配置注入等横切能力放到与主应用并行的辅助进程或容器中，二者共享生命周期与网络命名空间，主应用保持技术无关。
依赖倒置原则（DIP）
高层模块与低层模块都依赖抽象；抽象不依赖细节，细节依赖抽象。它约束的是依赖方向，常被与依赖注入（一种实现手段）混为一谈。
模块化单体（Modular Monolith）
一个部署单元内按业务模块划分，模块之间通过显式接口通信并禁止跨模块访问内部实现；保留单体部署的简单性，同时获得清晰边界。
请求-响应模式
调用方发起请求并等待响应，是最直观的交互方式；实现简单、语义清晰，但调用双方在时间与可用性上耦合，需要超时、重试与熔断配套。
Serverless 与函数计算
以事件触发的函数为部署单元，平台负责伸缩与计费；适合突发流量、胶水集成与低频任务，需接受冷启动、执行时长限制与状态外置。
多租户架构模型
多租户按隔离程度分档：共享数据库共享 schema、共享数据库独立 schema、独立数据库（甚至独立实例）；隔离越强成本越高，需结合合规与噪声邻居评估。
组合优于继承
优先通过对象组合与委托复用行为，而非继承：继承在编译期绑定、破坏封装且层级僵化；当类型关系稳定且确实存在 is-a 语义时才考虑继承。
管道-过滤器架构
数据依次流经多个独立过滤器，过滤器之间通过管道传递数据；适合 ETL、编译器、图像与日志处理等可分解为独立步骤的场景。
事件通知与事件携带状态转移
事件驱动有三种常见用法：事件通知（薄事件，只告知发生了什么）、事件携带状态转移（事件内含所需数据）、事件溯源（事件即事实来源）；耦合度与信息量递增。
扩展-收缩（并行变更）
兼容性变更的标准手法：先扩展（新增字段/接口并双写、回填历史数据），迁移消费方后再收缩（删除旧结构）；数据库与接口演进都适用。
工作流与编排引擎
把长流程的状态、重试、超时与补偿交给引擎管理，业务代码只实现步骤逻辑；代表实现包括 Temporal、Camunda、Airflow 等，需评估引擎自身的高可用与升级成本。
耦合（Coupling）与其类型
耦合衡量模块间依赖强度，从数据耦合、标记耦合、控制耦合到公共耦合、内容耦合逐级增强；架构设计追求低耦合但需与内聚权衡。
微内核架构（插件化）
核心系统只承载通用能力与插件契约，可变规则以插件形式扩展；适合规则多变的平台型产品，如工作流、IDE、规则引擎。
物化视图与读模型
把复杂查询结果预先计算并存储，查询时直接读取；刷新方式有全量重建、增量更新与事件驱动更新，适用于报表、搜索与分析型读场景。
微前端（Micro Frontends）
按业务域把前端拆为可独立构建与发布的应用，由不同团队负责；集成方式包括构建时依赖、运行时模块加载、iframe 与 Web Components，需权衡一致性、性能与自治。
关注点分离（Separation of Concerns）
把系统按不同关注点（业务规则、持久化、展示、安全等）划分，使各部分可独立理解与修改；它是分层、模块化、AOP 等方法的共同基础。
事件驱动拓扑：Broker 与 Mediator
Broker 拓扑中事件在组件间链式流转、无中心编排；Mediator 拓扑由中心编排器协调步骤与错误处理，两者在耦合度与可观测性上取向相反。
无共享架构（Shared-Nothing）
节点之间不共享内存与磁盘，各自处理一部分数据与请求；是水平扩展与故障隔离的基础假设，数据分片与再平衡是其核心配套。
里氏替换原则（LSP）
子类型必须能替换父类型而不破坏调用方依赖的行为契约：前置条件不加强、后置条件不减弱、不变量保持；典型违反是正方形继承矩形。
内聚（Cohesion）与其等级
内聚衡量模块内部元素的相关程度，从偶然、逻辑、时间、过程、通信、顺序到功能内聚逐级增强；模块设计以功能内聚为目标。
Actor 模型
每个 Actor 拥有私有状态与邮箱，按顺序处理消息；Actor 之间只通过消息交互，可形成监督树实现故障隔离，适合高并发有状态场景。
抽象分支（Branch By Abstraction）
在同一代码库中引入抽象层，把旧实现替换为抽象调用，再并行开发新实现并切换，最后清理抽象；避免长期存在的合并分支。
工作单元（Unit of Work）
跟踪一次业务操作期间的对象变更，在提交时统一计算变更集并写入数据库，保证事务边界清晰且减少重复写操作；常与仓储、标识映射配合使用。
信息隐藏（Information Hiding）
Parnas 提出：模块划分应隐藏“可能变化的决策”，接口只暴露稳定信息；与按处理步骤划分相比，更利于应对变化与独立开发。
洋葱架构（Onion Architecture）
以领域模型为中心向外分层：领域模型 → 领域服务 → 应用服务 → 基础设施，依赖只指向内层，外层实现内层定义的接口。
流程管理器（Process Manager）
集成模式中的有状态协调者：接收事件、维护流程状态并决定后续发送命令或继续等待；适合需要多步、跨系统且有补偿逻辑的业务流程。
迪米特法则（Law of Demeter）
对象只与直接协作者通信，避免 a.getB().getC().doSomething() 这类链式穿越；减少对内部结构的依赖，降低改动传播范围。
规约模式（Specification）
把业务规则封装为可命名、可组合（与/或/非）的规约对象，既可用于校验，也可用于构造查询条件，让规则复用且保持业务语义。
大泥球（Big Ball of Mud）反模式
缺乏清晰架构的系统形态：边界模糊、依赖纠缠、补丁叠加，短期能运行但修改风险随规模上升；识别信号包括改动一处牵连多处、无人知晓完整调用关系。
编排驱动 SOA 与 ESB
传统 SOA 通过企业服务总线集中做路由、转换与流程编排，服务粒度粗；集成能力强但总线容易成为单点与瓶颈，现代实践倾向轻量网关加消息替代。
Lambda 架构
批处理层提供全量准确视图，速度层提供低延迟近似视图，服务层合并两者结果；以两套计算逻辑换取准确性与时效性的平衡。
大使模式（Ambassador）
为主应用代理出站连接：统一处理服务发现、重试、TLS、分片路由与限流；与边车方向相反（边车多处理入站与横切，大使专注出站）。
纳米服务（Nanoservices）反模式
把服务拆得过细，导致一次业务请求需要数十次跨服务调用：调用风暴、跨服务事务频繁、部署与监控对象数量急剧上升，运维复杂度超过收益。
空间型架构（Space-Based）
处理单元加内存数据网格，业务数据尽量驻留内存并通过异步复制持久化；面向突发高并发场景，代价是数据一致性与持久化窗口的设计复杂度。
Kappa 架构
只用一条流处理链路处理全部数据，历史重算通过重放日志实现；依赖可持久化、可重放的日志系统，减少两套逻辑的维护成本。
数据网格（Data Mesh）
面向分析数据的组织与架构原则：按业务域划分数据所有权、把数据作为产品交付、提供自助式数据平台、以联邦方式治理；强调组织与架构协同。
共变（Connascence）
比耦合更细致的依赖判断工具：共变指“修改一处必须同步修改另一处”。静态共变包括名称、类型、语义、位置、算法；动态共变包括执行、时序、值、身份。
架构量子（Architecture Quantum）
架构量子是可独立部署、且具有高功能内聚的最小单元：量子内部的组件需要一起发布，量子之间通过明确定义的接口交互，用于划分服务与部署边界。
分布式与高可用50 条
CAP、一致性、容灾与限流熔断
CAP 定理
在网络分区发生时，分布式系统只能在一致性（C，linearizability 语义）与可用性（A）之间取舍；无分区时两者都可满足，因此“三选二”是简化说法。
幂等性
幂等操作重复执行与执行一次的效果相同；HTTP 中 GET、PUT、DELETE 定义为幂等方法，POST 通常不是，因此关键写操作需要额外设计幂等机制。
事务隔离级别与异常现象
SQL 标准定义四个隔离级别：读未提交、读已提交、可重复读、可串行化，用于控制脏读、不可重复读与幻读；各数据库的具体实现与标准描述存在差异。
ACID 与 BASE
ACID 强调原子、一致、隔离与持久；BASE 强调基本可用、软状态与最终一致。两者对应不同的业务容忍度，同一系统内也可按业务分区分别选择。
Saga 编排式实现
由中心协调器按状态机依次调用各服务，并在失败时触发补偿；流程逻辑集中、可观测性好，但协调器成为重要组件，需保证其高可用与幂等。
Raft 共识算法
Raft 通过领导者选举、日志复制与安全性约束实现共识：客户端请求由领导者追加日志，复制到多数派后提交；任期号与投票约束保证同一任期只有一个领导者。
一致性模型谱系
一致性模型描述并发读写时可观察到的保证强度，从线性一致、顺序一致、因果一致到最终一致逐级放宽；模型越弱，可用性与延迟表现通常越好。
MVCC 多版本并发控制
通过保存数据的历史版本让读操作不阻塞写、写不阻塞读；不同隔离级别对应不同快照规则，长事务与热点更新会造成版本堆积，需要清理机制。
两阶段提交（2PC）
两阶段提交先由协调者询问所有参与者能否提交（准备阶段），全部同意后再统一提交；任一阶段失败或协调者宕机都可能造成资源长期锁定。
数据分片
把数据按分片键拆分到多个节点，突破单机存储与写入上限；关键是分片键选择与再均衡方案，跨分片查询与事务的复杂度会明显上升。
并发异常与处理手段
常见并发异常包括丢失更新、写偏斜、幻读与脏写；处理手段有乐观锁（版本号）、悲观锁（行锁或 SELECT FOR UPDATE）与提高隔离级别。
发件箱模式（Transactional Outbox）
在本地事务中同时写业务数据与发件箱记录，再由独立中继把发件箱内容发布到消息系统；避免“数据库已提交但消息未发出”的不一致。
单主复制
所有写入经主节点，副本异步或同步复制；实现简单、冲突少，是多数关系型数据库的默认形态，限制是写扩展能力与主节点故障切换风险。
重试与退避
对可重试的瞬时故障按延迟递增策略再次尝试；指数退避叠加随机抖动可避免同步重试风暴，必须配合超时、次数上限与幂等设计。
容灾与 RTO/RPO
RTO 是故障后恢复服务的目标时长，RPO 是可接受的数据丢失时间窗；两者共同决定容灾架构形态（备份、冷备、温备、热备）与成本量级。
幂等键（Idempotency Key）
客户端为每次业务操作生成唯一键，服务端首次执行后缓存结果，重复请求返回同一结果；适用于支付、下单等不可重复的写操作。
复制延迟
从库落后主库的时间差；业务表现包括读到旧数据、统计口径偏差与故障切换数据丢失；需要监控延迟指标并设计读写路由策略。
故障转移
主节点故障后由副本接管写入的过程；涉及故障检测、选主、切换与客户端重连，切换期间常伴随短暂不可写与数据回退风险，需要演练验证。
限流算法
常见限流算法包括固定窗口、滑动窗口、令牌桶与漏桶；令牌桶允许突发，漏桶平滑输出，滑动窗口统计更平滑，选择取决于要抑制突发还是允许突发。
蓝绿与金丝雀发布
蓝绿用两套环境整体切换，回滚快但资源投入约翻倍；金丝雀先放少量流量验证再逐步放大，风险小但需要版本级观测与快速回滚能力。
PACELC 扩展模型
PACELC 补齐 CAP 的空白：发生分区时在可用性 A 与一致性 C 之间取舍，否则（Else）在延迟 L 与一致性 C 之间取舍；说明无分区时一致性的代价主要是延迟。
领导者选举与租约
分布式系统通过选举产生单一写入者（或协调者）：基于共识协议、租约或外部协调服务实现；必须配合租约到期与隔离机制避免双主。
超时设计
为每一次跨进程调用设置超时，让失败尽快暴露；阈值应覆盖调用链正常耗时并留余量，上游超时要大于下游预算，避免级联截断。
SLI、SLO 与错误预算
SLI 是可测量的服务质量指标，SLO 是其目标值，SLA 是对外承诺；错误预算等于 1 减 SLO，用量化余额平衡发布速度与稳定性。
多地域部署
把服务与数据分布到多个地域，兼顾就近访问与地域级容灾；主动-主动需要解决数据冲突与流量调度，主动-被动实现简单但存在切流决策与容量验证成本。
读己之写（Read Your Writes）
会话级一致性保证：用户提交写入后，自己的后续读取能看到该结果；常见实现是写后一段时间内路由到主库或用会话令牌绑定数据版本。
补偿事务与业务回滚
分布式流程无法物理回滚已完成的远程操作，只能执行语义相反的补偿动作（退款、释放库存、回发优惠券）；补偿必须幂等、可重试且可审计。
读写分离
写请求路由到主库、读请求路由到从库，用复制扩展读吞吐；代价是复制延迟下的旧数据读，需要为“刚写就查”等场景保留走主库的路径。
熔断器
当下游错误率或慢调用比例超过阈值时快速失败一段时间，给下游恢复窗口；半开状态放少量探测流量验证恢复，是防止级联故障的常用手段。
优雅降级
依赖不可用时按预设策略返回降级结果（缓存、默认值、精简功能），保住主流程可用；降级开关应可动态下发并记录审计，避免长期滞留。
可串行化（Serializability）
事务隔离的最高级别：并发事务的执行结果等价于某种串行执行顺序；它保证多对象事务的正确性，但通常伴随吞吐下降或冲突重试。
Saga 协同式实现
各服务订阅事件并在本地事务完成后发布新事件，由事件链推动流程；解耦度高、无中心组件，但整体流程分散，排障与变更影响评估更难。
去重表与消费幂等
用数据库唯一约束或去重表记录已处理的消息标识，重复投递时直接跳过；与业务更新放在同一事务中，才能保证“处理+记录”原子。
仲裁与读写法定人数
副本集通过法定人数（quorum）决定读写是否需要多数派参与；在 N 个副本中写 W 个、读 R 个，满足 R + W > N 时读可覆盖最近写入（简化条件下）。
故障域隔离
按进程、节点、机架、可用区、地域等层级划分故障影响范围，把副本与流量分布到独立域中；目标是单域故障不放大为全局故障。
线性一致性（Linearizability）
比顺序一致性更强的单对象保证：每个操作看起来在调用与返回之间的某一时刻原子生效，且所有客户端观察到同一顺序；组合多个线性一致对象仍是线性一致。
TCC（Try-Confirm-Cancel）
把分布式事务拆成三阶段业务操作：Try 预留资源、Confirm 确认提交、Cancel 释放预留；由业务实现三种操作，语义明确但侵入性强。
收件箱模式（Idempotent Consumer）
消费端记录已处理的消息标识（inbox 表），与业务变更同事务提交；重复投递时跳过处理，保证“至少一次投递”下的消费效果不重复。
脑裂（Split-Brain）
网络分区或旧主未停止时出现两个自认为有效的写入者，导致数据分叉；对策包括多数派仲裁、租约与隔离、fencing 令牌与存储端校验。
混沌工程
在可控范围内主动注入故障（延迟、宕机、网络分区），验证系统韧性假设；以稳态假设、有限爆炸半径与随时可中止为原则，可从只读实验起步。
因果一致性
保证有因果关系的操作在所有节点上按相同顺序可见，无因果关系的操作可乱序；比强一致代价低，又避免“评论早于帖子”这类明显异常。
XA 分布式事务
X/Open 定义的分布式事务接口：事务管理器通过 XA 接口协调多个资源管理器（数据库、消息中间件）的提交与回滚；跨异构资源可用，但性能与可用性成本较高。
多主复制
多个节点都能接受写入并互相复制，提升本地写入可用性；代价是写冲突必须显式解决（最后写入胜出、版本合并或应用层合并）。
一致性哈希
把节点与数据都映射到哈希环上，按顺时针就近归属；增删节点时只影响相邻区段的数据，配以虚拟节点缓解负载倾斜，常用于缓存与分片路由。
舱壁隔离
为不同调用或租户分配独立资源池（线程、连接、队列），一组流量出问题不拖垮其他部分；命名来自船体分舱，本质是限制故障的资源传导。
Paxos 共识算法
Paxos 通过提案编号与多数派接受达成共识；基础 Paxos 用于单值决策，Multi-Paxos 通过稳定的领导者扩展到日志复制。
无主复制（Leaderless）
客户端直接向多个副本读写，依赖法定人数与冲突解决保证收敛；常见机制包括读修复、提示移交与反熵同步，可用性高但语义更复杂。
背压
当下游处理能力不足时，向上游反馈并降低生产速率，使系统在过载下保持稳定；手段包括队列水位控制、拉模式消费与明确的拒绝策略。
单调读（Monotonic Reads）
同一会话的读取不会“时光倒流”：如果已看到某个版本的数据，后续读取不会返回更旧的版本；通过绑定副本或比较版本号实现。
三阶段提交（3PC）
在 2PC 的准备与提交之间增加预提交阶段，参与者可在超时后自行推断结果，降低阻塞概率；其正确性依赖同步网络与无分区假设，实际使用有限。
API 与集成设计60 条
REST/RPC、契约管理与 API 网关
REST 与资源建模
REST 以资源为中心组织接口，用统一接口与表述（representation）操作资源状态；资源名用名词复数、通过链接表达关系，避免在路径里塞动词。
HTTP 方法语义
GET 读取、POST 创建、PUT 整体替换、PATCH 部分更新、DELETE 删除；方法与安全/幂等属性共同决定重试与缓存行为，是一致接口语义的基础。
HTTP 状态码
状态码按 2xx/3xx/4xx/5xx 表达结果：400 参数问题、401 未认证、403 无权限、404 不存在、409 冲突、422 语义错误、429 限流、503 暂不可用。
OAuth 2.0
授权框架：资源所有者授权客户端代表其访问资源；核心角色包括资源服务器、授权服务器与客户端；授权码模式配 PKCE 是交互式应用的推荐形态。
gRPC
基于 HTTP/2 与 Protocol Buffers 的 RPC 框架，支持四种调用形态（一元、服务端流、客户端流、双向流）与跨语言代码生成，适合内网服务间高吞吐调用。
JWT 与令牌设计
以紧凑的 JSON 结构承载声明并附带签名；服务端无状态校验友好，但撤销困难，需要短有效期加刷新令牌、密钥轮换与时钟偏差容忍策略配合。
API 分页
集合接口需要分页：偏移分页简单但深翻页慢且数据变动时会漏项或重复，游标分页按稳定位置继续翻页，更适合大集合与实时数据。
OpenAPI 规范
用 OpenAPI 描述 HTTP 接口的路径、参数、模式与响应；描述文件可生成文档、客户端 SDK、服务端骨架与测试，是接口协作的通用载体。
API 网关
在客户端与服务之间提供统一入口：路由、鉴权、限流、TLS 终止、日志与协议转换；把横切关注点收敛到一层，同时避免网关演变成业务逻辑集中点。
OpenID Connect
构建在 OAuth 2.0 之上的认证层：用 ID Token（JWT）传递认证结果，标准化发现文档与用户信息端点；适合单点登录与第三方登录场景。
消息队列与投递语义
消息系统提供解耦、削峰与异步重试；投递语义分至多一次、至少一次与精确一次（依赖消费端幂等或事务实现），选型时要看清语义边界。
HTTP 缓存语义
用 Cache-Control、ETag 与 Vary 表达缓存策略：公共缓存与私有缓存分层，命中校验走 304；缓存键未覆盖的维度变化会产生错误内容。
API 版本化
对外接口需要可演进的兼容策略：路径版本（/v1）、请求头版本或媒体类型版本各有取舍；优先做兼容性扩展，破坏性变更才升版本。
Protocol Buffers
语言无关的接口与数据序列化格式，通过字段编号保证向前向后兼容：新增字段用新编号，废弃字段保留编号与名称（reserved），删除编号不复用。
Webhook 设计
服务端在事件发生时向订阅方回调 HTTP 请求的反向集成方式；要点是签名验证、重试策略、去重键与订阅生命周期管理，避免把可靠性问题转嫁给接收方。
错误响应设计
错误响应要机器可读且可追踪：统一结构包含类型、标题、状态、详情与实例标识（Problem Details），前端按类型分支处理，配合字段级校验信息。
变更数据捕获（CDC）
从数据库日志解析数据变更并发布为事件流，让下游准实时同步而无需侵入业务写入路径；注意去重、顺序与快照初始化的配合。
流式接口选型
把结果分批推给客户端的手段：轮询简单但延迟与开销高，长轮询减少空转，SSE 适合单向推送，WebSocket 支持双向低延迟通信；按交互需要选择。
条件请求与 ETag
用 ETag/Last-Modified 与 If-None-Match/If-Match 实现缓存校验与并发控制：读取省流量，写入用 If-Match 防丢更新（乐观锁）。
契约测试
用契约测试验证提供方与消费方对接口的约定：消费方定义期望并生成契约，提供方在流水线中执行验证，提前发现不兼容变更。
GraphQL
由客户端声明所需字段的查询语言：单端点、强类型模式、按需取数，减少多接口拼装；代价是查询复杂度不可控，缓存与限流策略与 HTTP 不同。
Schema Registry 与事件模式演进
集中管理事件与消息的模式版本并校验兼容性：生产者在发布前注册模式，消费者按版本解析；兼容策略（向后、向前、全兼容）决定可用的演进方式。
API 可观测性
面向接口的可观测体系：请求量、错误率、延迟分位与饱和度四类指标，配合结构化日志与追踪；按消费者与接口维度切片，才能定位影响面。
大文件上传设计
大文件走分片上传：初始化会话、并行上传分片、合并或由对象存储完成分片组装；支持断点续传与校验（分片哈希与整文件哈希），并限制单文件与并发配额。
死信队列
无法处理的消息转入死信通道隔离保存，主流程继续推进；死信要有告警、查看手段与重投工具，否则等同于消息黑洞。
过滤、排序与字段选择
集合接口的查询能力：过滤条件、排序字段与字段裁剪（fields/select）；参数要白名单化并限制复杂度，避免把数据库查询能力暴露成攻击面。
契约先行（API First）
先定义接口契约（OpenAPI/Proto/AsyncAPI）再实现，前后端与上下游按契约并行开发；契约评审纳入变更流程，错误语义在契约阶段确定。
BFF（Backend for Frontend）
为每类前端（Web、移动端、第三方）提供专属聚合层：按端裁剪字段、聚合多服务调用并处理差异化缓存；避免用一个通用接口适配所有客户端。
API 密钥与凭证管理
面向开发者的凭证形态之一：用于识别调用方而非认证具体用户；要支持签发、轮换、吊销与最小权限绑定，密钥只存哈希、不明文落库。
关联 ID 与请求追踪
为一次业务请求生成关联 ID 并全程透传（网关、服务、消息、日志），把分散日志串成调用链，是联调与故障定位的基础设施。
同步与异步集成
同步调用链路短、结果即时，但耦合时延与可用性；异步消息解耦、可削峰，但引入最终一致与运维复杂度。按调用方对时延与一致性的要求选择。
API 废弃策略
接口下线需要流程：公告弃用状态与替代方案、设置弃用响应头与期限、监控存量调用方，按批次关停；给消费者可执行的迁移路径，而非直接断供。
分布式追踪
用 trace/span 结构记录跨服务调用链：一次请求一个 trace，每个处理单元一个 span，记录耗时与父子关系；是定位跨服务延迟与失败传播的主要手段。
令牌生命周期管理
访问令牌短期有效、刷新令牌长期持有并一次性轮换；过期与刷新失败要区分处理（重新登录与静默刷新），客户端与服务端时钟偏差要留出容忍窗口。
消息顺序性
顺序保证通常是分区内而非全局：以业务键做分区键，同一实体的消息进入同一分区保序；跨实体顺序需要业务收敛或合并为单一键。
服务网格
把服务间通信的流量治理（mTLS、重试、熔断、遥测）下沉到数据面代理，控制面统一下发策略；降低业务侵入，但增加运维复杂度与延迟开销。
Richardson 成熟度模型
用四级阶梯描述 HTTP API 的成熟程度：单端点 POST、资源化、使用 HTTP 动词与状态码、超媒体驱动；级别是沟通工具，不必盲目追求高等级。
GraphQL 与 REST 取舍
REST 用固定资源接口与 HTTP 缓存语义，生态成熟；GraphQL 由客户端决定字段，聚合场景灵活但服务端复杂度更高。按消费方形态与治理能力选择。
API 组合与聚合
对多个下游服务的数据做组合查询（内存连接或编排调用）后返回；组合层要定义部分失败语义：整体失败还是带缺省结果，需要按业务场景确定。
双向 TLS（mTLS）
客户端与服务端互相验证证书，适用于服务间或企业与平台之间的强身份通道；证书生命周期管理（签发、轮换、吊销）是落地的主要工作量。
API 配额与限流响应
面向调用方的配额体系：按应用、用户与接口维度限制速率与总量，用响应头声明余额与重置时间，让客户端自助退避并配合告警。
企业集成模式（EIP）
Gregor Hohpe 归纳的消息集成模式目录：路由、转换、端点与消息通道四大类；用成熟模式表达集成逻辑，比自创管道更易评审与复用。
API 测试策略
按层组织：模式校验与单测、契约测试、集成测试（真实依赖）、端到端与性能冒烟；每层覆盖不同失败模式，避免把全部验证压在最慢的一层。
OpenTelemetry
可观测数据采集的开放标准：统一 API/SDK 与协议（OTLP）采集指标、日志与追踪，后端可替换；降低多供应商采集器重复埋点的成本。
授权范围（Scope）设计
Scope 表达令牌被授予的能力边界：按资源与动作命名（orders:read、orders:write），服务端逐请求校验；范围过粗失去最小权限意义，过细难以维护。
共享数据库集成
多个服务或系统直接读写同一数据库的集成方式；短期省事，长期锁死表结构、绕过业务规则并制造隐性耦合，常见替代方案是接口或事件集成。
毒消息治理
反复处理失败且阻塞队列的消息要尽快隔离：区分可重试（依赖临时故障）与不可重试（格式错误）两类，限次重试后转死信并告警。
超媒体与 HATEOAS
响应中携带可用状态转移的链接（_links），客户端由服务端指引决定下一步可做什么；适合状态机明显的业务接口，实现与理解成本较高。
消费者驱动契约
由消费方提出对接口的期望，多方期望汇总成提供方的兼容性边界；新增依赖与字段废弃都能被量化追踪，变更影响范围可审计。
RPC 与 REST 对比
RPC 关注调用动作与参数（gRPC、Thrift、JSON-RPC），REST 关注资源表述；内网服务间调用偏 RPC，对外开放集成偏 REST，选择取决于耦合与工具链。
批量文件与结算集成
企业间常见批量集成形态：按周期交换文件（SFTP 或对象存储），配合校验文件、断点续传与幂等装载；可靠性与可审计性优先于时延。
ESB 与遗留系统集成
企业服务总线在中心节点做协议适配、路由与转换，适合对接异构遗留系统；中心化带来治理与性能瓶颈，常见路线是逐步外移能力到网关与消息系统。
API 反模式
常见反模式：隧道式单端点、把数据库表当资源、错误码全 200、无版本与无废弃策略、参数语义不一致；识别这些模式有助于在设计评审阶段提出改进项。
集成沙箱与联调环境
为外部协作方提供隔离的测试环境：数据可重置、可模拟异常场景（超时、错误码）、有配额与访问控制；沙箱质量直接影响接入效率与支持成本。
gRPC 拦截器与横切关注点
拦截器统一处理鉴权、超时、重试、指标与链路传播：一元与流式拦截器形态不同；顺序与幂等性要设计，避免重复采集或覆盖上下文。
内容协商
客户端通过 Accept、Accept-Language 与 Accept-Encoding 声明偏好，服务端选择表述并在 Content-Type 中声明结果；版本升级也可借媒体类型承载。
SOAP 与 WSDL
基于 XML 的消息协议，用 WSDL 描述服务契约、XSD 描述数据类型，内置 WS-Security 等扩展；在传统企业集成与政务金融接口中仍有存量使用。
AsyncAPI
面向事件驱动接口的描述规范，用 channels、operations 与 messages 描述消息通道与载荷；定位类似异步场景的 OpenAPI，支撑文档、代码生成与治理。
开发者门户与文档体验
面向接入方的统一入口：快速开始、认证说明、接口参考、错误码表、变更日志与状态页；文档质量决定接入周期与支持工单量。
规范校验与风格检查
对接口描述文件做自动校验：命名风格、必填字段、错误结构与示例有效性；把团队规范变成可执行规则（如 Spectral 规则集），在流水线里拦截偏差。
容量与性能设计51 条
容量估算、缓存与数据库设计
容量估算流程
容量估算按步骤推进：业务目标（用户量、订单量）→ 换算请求模型 → 资源消耗模型 → 峰值与冗余 → 验证压测；估算结果要留假设清单与复核节点。
Little 定律
稳态系统中并发数等于到达率乘以平均停留时间（L=λW）；它是容量换算的基础工具：已知 QPS 与响应时间即可估并发，反之亦然。
缓存模式
旁路缓存（Cache-Aside）最常见：读未命中查库回填，写时删除缓存；读穿、写穿、写回各有取舍，写回吞吐高但可能丢数据。
索引与查询优化
索引用空间换取查询速度：按高频查询的过滤与排序顺序建立联合索引，遵循最左前缀；写放大与选择性之间需要权衡，冗余索引要定期清理。
QPS 与并发数换算
QPS 约等于并发数除以平均响应时间；反推时两者联动：提升并发不必然提升吞吐，瓶颈资源饱和后延迟上升、吞吐停滞。
压测方法
常用压测形态：阶梯加压找拐点、恒定压力做浸泡（Soak）、突发流量验证弹性、全链路压测验证端到端；压测环境与数据要尽量贴近生产。
线程池容量核算
线程数按任务类型核算：CPU 密集型接近核数，IO 密集型可按等待比放大；必须配队列上限与拒绝策略，防止无界队列掩盖过载。
慢查询治理
慢查询是数据库性能问题的线索来源：开启慢查询日志，按总耗时贡献排序，用执行计划定位扫描行数与临时表，建立治理台账跟踪闭环。
峰值系数与冗余设计
容量按峰值而非均值设计：峰值系数=峰时流量/平均流量，结合故障冗余（N+1、跨可用区）得到部署容量；同时用队列与限流削平尖峰。
尾延迟与长尾效应
请求延迟分布呈长尾：单服务 P99 叠加到扇出调用后，端到端 P99 被放大；降低尾延迟靠并行化、请求对冲、超时预算与慢节点摘除等手段。
缓存雪崩与击穿
大量缓存同时失效（雪崩）或热点键失效瞬间（击穿）会把流量直压数据库；对策包括 TTL 抖动、逻辑过期、互斥重建与热点永不过期策略。
队列积压估算
积压清理时间等于积压量除以净消化速率（消费速率减生产速率）；容量设计要保证消费能力留有裕量，并用积压时长告警而不是只看条数。
读扩展组合
读多写少的系统按层次扩展读能力：本地缓存→分布式缓存→只读副本→搜索索引与物化视图；每层的新鲜度与运维成本不同，按查询特征分层选择。
批处理与合并请求
把多个小请求合并为批次执行：网络往返、事务与锁开销被摊薄，吞吐明显提升；需要在批大小、等待窗口与延迟目标之间设定参数。
压测指标解读
压测报告核心指标：吞吐（成功请求每秒）、延迟分位（P50/P95/P99）、错误率与资源水位；吞吐不再随压力增长且延迟陡升的点即容量拐点。
连接池设计
数据库与下游连接复用开销高，需要连接池：池大小按并发与下游容量核算，超时要覆盖取连接与执行两个阶段，避免取连接排队拖垮整条链路。
写扩展与批量化
写扩展路径：批量化合并写入、异步化削峰、分区与分片分摊、追加日志替代随机写；每步都要评估其对一致性与延迟的影响。
异步化与削峰
把非关键路径从请求链路中剥离：请求只做校验与落库，耗时动作（通知、导出、结算）转异步；用队列水位与消费速率控制端到端时效。
热 Key 与热点数据
部分键承载远高于均值的流量：缓存层会形成单分片热点，数据库会出现行锁竞争；用本地缓存、热点复制与写合并等手段摊平热点。
过载保护与流量丢弃
当负载超过容量时主动丢弃低优先级流量：按优先级分类请求，先保核心链路，丢弃或排队旁路请求，并快速返回可重试的错误。
排队论与利用率
排队系统利用率接近上限时等待时间急剧增长：利用率 50% 与 90% 对应的队列长度差异并非线性；给关键资源留出裕量是控制延迟的现实手段。
弹性伸缩
按负载信号自动调整实例数：指标选择（CPU、队列深度、QPS）、触发阈值、冷却时间与伸缩步长共同决定响应质量；冷启动与扩容时延要实测。
性能需求的三要素
性能需求要同时给出响应时间、吞吐量与容量边界（数据规模、并发用户），并标注测量条件；缺任何一项都无法验证，也无法指导容量与压测设计。
通用可扩展性定律（USL）
在 Amdahl 之外补充一致性开销：争用导致收益递减，交叉耦合（通信与同步成本）会让吞吐在到达顶点后下降，用于解释加机器反而变慢的现象。
延迟与吞吐的权衡
批量化与排队能提升吞吐但推高单次延迟；在线系统按延迟目标反推批大小与队列深度，离线系统可以换更大批次。按业务分层设定目标。
缓存穿透
查询不存在的数据时缓存永不命中，请求持续落到数据库；对策包括空值缓存（短期）、布隆过滤器前置拦截与参数合法性校验。
分区与冷热分离
按时间或范围把大表拆分为分区，历史分区可归档到低成本存储；分区裁剪让查询只扫描相关分区，同时把批量维护（删除历史）变成分区级操作。
数据库连接瓶颈
数据库连接数是稀缺资源：单实例可承载连接有限，应用实例扩张会成倍放大连接需求；用连接池收敛、代理层复用与请求准入控制管理连接数。
CDN 与静态资源
把静态资源与可缓存内容分发到边缘节点：降低源站带宽与访问延迟；配置要点包括缓存规则、回源策略、刷新与预热，动态内容可按需加速。
HTTP/2 与 HTTP/3 演进
HTTP/2 引入多路复用与头部压缩，改善并发传输效率；HTTP/3 基于 QUIC 把传输层的队头阻塞进一步消解，弱网与移动场景收益更明显。
长连接与连接复用
TCP/HTTP 长连接省去反复握手与慢启动成本；需要与负载均衡、网关的空闲超时协调，避免请求被单方面关闭形成偶发 502。
GC 与延迟
垃圾回收会造成周期性停顿并恶化尾延迟：通过堆大小、代际策略与低延迟收集器选择控制停顿，用 GC 日志量化频率与时长再调参。
数据倾斜
某些分区键对应的数据量与流量远大于其他分区：表现为个别实例 CPU 或存储显著偏高、任务出现长尾；需要重新选择分布键或对热点加盐拆分。
性能剖析与火焰图
用采样剖析定位热点代码：perf、async-profiler 等工具生成火焰图，按 CPU、内存或锁维度查看调用栈占比，先定位再优化。
性能预算分配
把端到端延迟目标拆解到各环节：网关、服务、数据库与外部依赖各分配预算并留余量；新增依赖前核对剩余预算，避免逐项小幅劣化累积超标。
性能回归与基准管理
把关键路径性能纳入持续验证：固化基准场景与数据，定期执行并对比历史基线；超过阈值即告警或阻断发布，防止性能在迭代中慢性劣化。
垂直与水平扩展
垂直扩展提升单机规格，简单但存在上限与停机改造；水平扩展增加实例，需要处理无状态化、数据分布与会话共享，是弹性与容灾的基础。
容量冗余与预留
按 N+1 或 N+2 预留容量以承受故障与突发：冗余部署在独立故障域，且要定期验证故障时全量流量可被承接，而非只停留在纸面预留。
存储容量估算
存储估算按数据量、副本系数、索引与日志开销、增长速率综合计算，并预留归档与备份空间；增长率与保留策略决定何时需要扩容或归档。
磁盘 IO 与顺序写
数据库与日志系统优先使用顺序写：日志结构存储把随机写转为顺序追加；评估 IO 时看 IOPS、吞吐与延迟三个维度，并按读写比例选择存储介质。
网络往返与跨地域延迟
跨地域调用的延迟下限由物理往返时间决定：同城约毫秒级、跨区域数十毫秒、跨洲上百毫秒级；依赖跨地域强一致交互的接口要改为本地化路径。
缓存预热
重启或发布后缓存为空，流量直压数据库；通过预热脚本回填热点数据、延迟放量与分批导流降低冲击，预热进度要与放量节奏联动。
容量预测与增长管理
容量管理是持续过程：按业务增长与季节因素预测资源需求曲线，提前排期扩容与压测；把容量水位纳入日常看板，避免临近峰值才启动扩容。
邻居干扰与资源隔离
多租户或同集群共存时，个别租户的资源消耗会拖慢其他租户（吵闹邻居）：用配额、限流、资源池与优先级隔离限制互相影响，并监控离群实例。
延迟分解与归因
把端到端延迟拆成排队、计算、网络与下游等待各段：按段测量（追踪、指标、日志）定位主要贡献者，避免在非瓶颈环节投入优化。
Amdahl 定律
系统整体加速比受串行部分占比限制：即使并行部分无限加速，整体上限仍是 1/串行占比；用于识别优化收益的天花板。
USE 方法
对每类资源检查三项：利用率（Utilization）、饱和度（Saturation）与错误（Errors）；按资源清单逐项排查，系统化定位瓶颈而非凭直觉猜测。
RED 方法
面向服务的指标三件套：请求速率（Rate）、错误数（Errors）与请求耗时分布（Duration）；适合微服务监控面板，与 USE 的资源视角互补。
带宽估算
带宽按峰值 QPS × 平均响应体大小 × 冗余系数估算；出口带宽、跨区域复制与备份流量都要计入，压缩与 CDN 可以明显降低回源带宽。
Web 性能指标
以用户视角衡量前端性能的指标：LCP（加载）、INP（交互响应）与 CLS（布局稳定）；达标需要资源优化、代码拆分与减少主线程阻塞配合。
压缩与载荷优化
在传输与存储层压缩数据：HTTP 响应压缩（gzip/brotli）、消息批量压缩与列式存储压缩各有适用；要在 CPU 开销与带宽节省之间测量取舍。
技术选型与决策52 条
选型维度、ADR 与演进式架构
技术选型维度
选型按统一维度评估：问题匹配度、成熟度、团队技能、生态与社区、性能与容量、运维成本、许可与合规、退出成本；维度权重按项目约束确定。
功能开关（Feature Flags）
功能开关把发布与启用解耦：代码随时可发布，功能按开关灰度；按用途分为发布、实验、运维与权限开关，并为每个开关设定生命周期与清理责任人。
架构决策记录（ADR）
用短文档记录单条架构决策：背景、决策内容、备选方案与后果；ADR 按编号归档并纳入代码库评审，让后来者理解决策的来龙去脉。
数据库选型
数据库选型从数据模型与访问模式出发：关系型适合事务与复杂查询，文档型适合聚合读写的半结构化数据，宽列适合海量写入，图库适合多跳关系；再叠加一致性与运维要求。
基础设施即代码工具选型
IaC 工具按声明式与命令式、状态管理、多云覆盖评估：声明式描述终态并做差异收敛，命令式脚本灵活但需自行保证幂等；同时看状态后端、漂移检测与团队技能。
可观测性技术栈选型
可观测性按指标、日志、追踪三面选配：优先统一采集标准（OpenTelemetry），再决定托管或自建；评估计费模型、采样策略、保留期限与查询体验。
PoC 与基准验证
PoC 用真实场景验证关键假设：明确验收指标、数据规模与失败退出条件；避免做成演示玩具，结论要能回答“是否满足生产要求”。
自建与采购
自建与采购的比较围绕差异化与总成本：核心差异化能力倾向自建，通用能力倾向采购或托管；评估要覆盖迁移、集成与退出成本，而非只看订阅价格。
开源许可证合规
引入开源组件前核对许可证类型与义务：宽松（MIT/Apache-2.0）、弱传染（LGPL/MPL）与强传染（GPL/AGPL）的义务不同；分发与网络服务场景需分别评估。
消息中间件选型
消息选型对比投递模型、顺序性、延迟、吞吐与运维复杂度：Kafka 偏流式与高吞吐，RabbitMQ 偏路由灵活，云托管队列偏省运维；按场景组合使用也常见。
CI/CD 平台选型
流水线平台在托管与自建之间取舍：托管省去升级与扩缩运维，自建可控性强、适合内网与专有环境；评估运行器管理、缓存与制品、密钥注入与审计能力。
依赖管理与供应链治理
依赖治理覆盖声明、锁定、更新与安全四个环节：锁文件固定解析结果，更新机器人按节奏提交变更，扫描与 SBOM 纳入流水线；传递依赖同样在治理范围内。
决策矩阵与加权评分
把备选方案与评估维度做成矩阵：逐项评分并加权汇总，评分依据公开记录；矩阵用于结构化讨论与留痕，不替代最终责任人的判断。
ATAM 架构评审
架构权衡分析方法：围绕质量属性场景与利益相关方，识别敏感点与权衡点，输出风险与非风险清单；适合重大架构决策前的结构化评审。
总拥有成本（TCO）
TCO 覆盖获取、集成、运维、升级、培训与退役各阶段成本；云与自建的比较要按同口径核算（含人力与网络），并按多年周期而非首年报价对比。
开源项目评估
评估开源依赖不只看功能：维护活跃度、版本发布节奏、议题与安全响应、文档质量、依赖树与许可证都要检查；核心依赖要准备“无人维护”的应对预案。
SQL 与 NoSQL 取舍
关系型提供强事务与灵活查询，NoSQL 以水平扩展与模型灵活性见长；选择取决于一致性要求、数据模型稳定性与访问模式，多模型组合存储也常见。
容器编排选型
容器编排的核心是调度、滚动发布、自愈与资源配额；Kubernetes 是常见事实标准但运维复杂度高，托管集群降低控制面负担；小规模场景也可用更轻量的调度方案。
供应商锁定与退出策略
锁定来自数据格式、专有接口与深度集成：评估锁定程度并按关键性设计退出路径（标准协议、数据导出、抽象接口）；锁定本身不是错误，失控的锁定才是风险。
迁移策略选择
系统迁移按场景选策略：停机迁移适合小体量与窗口充足；双写加校验适合在线迁移；绞杀者渐进替换适合长期演进；组合使用时明确阶段与回滚点。
单仓与多仓（Monorepo / Polyrepo）
仓库布局影响依赖管理与协作方式：单仓便于跨模块原子提交与统一工具链，多仓便于独立发布与细粒度权限；选择取决于团队规模、构建系统能力与治理成本。
参考架构的选用方法
云厂商与社区的参考架构是起点而非答案：先核对场景假设（规模、合规、成本模型），再映射自身约束并标出偏离点；偏离处补充自己的决策记录。
适应度函数
把架构特征写成可自动验证的检查：性能预算、依赖方向、模块耦合度、安全基线；在流水线持续执行，架构约束不再依赖口头约定。
演进式架构
架构按可演进目标设计：以增量为单位交付结构变化，用适应度函数守护方向；把“改架构”变成持续过程而非一次性重构项目。
技术雷达
用环形图维护技术采用策略：按采用、试验、评估、暂缓四环归档技术，并标注移动方向；定期评审更新，让团队对技术选择有共同视图。
版本策略与 LTS
依赖与运行时的版本策略：优先选择长期支持（LTS）版本，明确升级节奏与安全补丁窗口；把升级排期纳入例行计划，避免多版本并行与版本悬崖。
缓存组件选型
缓存选型看数据结构、持久化、集群模式、一致性与运维成本：Redis 数据结构与生态丰富，Memcached 形态简单；本地缓存与分布式缓存按数据量与新鲜度需求分层。
RPC 框架选型
RPC 框架选型看协议与序列化、语言支持、服务治理（注册发现、负载均衡、熔断）与生态：gRPC 跨语言强类型，Dubbo 等生态绑定语言栈与治理体系。
语言与运行时选型
语言选型超越语法偏好：并发模型、运行时性能与内存特征、生态与库质量、部署形态与团队存量技能；多语言并存要评估构建与运维的复杂度增量。
Serverless 适用性评估
函数计算适合突发、短时、事件驱动的任务：免运维与按量计费是优势，冷启动、时长限制与本地调试是约束；长连接与常驻进程类负载通常不适合。
存储类型选型
块存储适合数据库与文件系统，文件存储适合共享目录与遗留应用兼容，对象存储适合海量与静态内容；按访问模式、共享需求与一致性选择。
托管服务选型
托管服务把运维责任转移给供应商：评估可用性 SLA、可观测接口、备份恢复能力与成本模型；同时确认数据驻留、合规与额度限制是否满足要求。
多云与混合云
多云降低单一供应商依赖但引入复杂度：网络互联、身份统一、数据同步与运维工具双份；多数团队从单一主云开始，仅对关键组件做可迁移设计。
技术风险评估
对选型与架构方案做风险清单：识别风险（性能、兼容、供应链、人才）、评估概率与影响、给出缓解与触发器；高风险项要绑定验证计划与责任人。
技术债管理
技术债是维护成本与变化的累积：把债务显性化（登记、分类、影响面），按利息（每次变更的额外成本）排序偿还，并设置防止新增的护栏。
架构治理
治理让架构决策可执行：通过评审门径、原则清单与适应度函数保证一致性；治理强度按团队自治程度调整，重流程会压垮交付，无治理则架构失控。
云成本优化
云成本优化从可见性开始：打标签分账、识别闲置与规格过剩、匹配计费模式（按量与预留）、设置预算告警；优化动作要与性能与可靠性目标联动评估。
试点与灰度推广
新平台或新架构先选试点验证：明确成功指标与止损条件，限定范围与时长；通过后分批推广，把迁移手册与培训材料作为交付物沉淀。
工作负载放置决策
按延迟、合规、成本与运维能力选择虚机、容器、无服务器或边缘等运行形态；同一系统可以混合放置，例如核心交易用容器、突发批处理用无服务器。
测试框架与分层选型
测试投入按分层分配：单元测试快速反馈，集成与契约测试覆盖交互边界，端到端测试保关键路径；框架选型看语言生态、执行速度与调试体验。
社区与生态
技术生态决定长期使用体验：SDK 与工具链完整度、问答资源、招聘市场、上下游集成与文档语言覆盖；生态薄弱会转化为自研成本与排障周期。
应用框架选型
框架选型评估：约定与自由度、性能表现、生态插件、升级节奏与社区活跃度；框架约定越多迁移与升级成本越高，按团队规模与交付节奏选择。
技术刺探（Spike）
对不确定性高的技术点做限时探索：目标单一、时间盒固定、产出可丢弃的原型与结论；用刺探降低决策风险，而不是把原型直接演化为产品。
可逆与不可逆决策
区分决策的可逆性：可逆决策快速试错，不可逆决策充分论证；数据模型、公共契约与供应商绑定多属难逆，需要投入更多评估与评审资源。
标准化与统一技术栈
统一技术栈降低运维与协作成本，但过度统一会牺牲场景适配；常见做法是默认标准加例外流程：核心域统一，边缘场景经评审引入差异。
团队拓扑与技术选择
康威定律指出系统结构趋向组织结构：团队边界决定接口与合作成本；技术选型要匹配团队拓扑，平台能力与赋能团队可降低重复建设。
退出策略与替代预案
为关键技术与供应商定义退出路径：数据导出格式与频率、替代方案候选、切换工作量与触发条件；把它写进架构决策记录并定期回访验证。
技术下线与退役管理
为技术建立退役流程：设定下线标准（使用率、替代方案就绪、迁移窗口），先冻结新增使用，再公告并进入迁移期，保留数据导出与回滚窗口，收尾清理依赖与账号。
开核模式与许可评估
评估开源项目的商业模式与许可：开放内核把部分能力放入商业版，需关注许可条款、功能边界变动历史与分发渠道；核心依赖要评估许可变更风险与替代路径。
创新采纳与技术生命周期
技术采纳遵循生命周期规律：创新者验证、早期采用者探索、主流跟进、滞后群体补课；按组织阶段选择参与时机，早期收益与风险并存。
商业支持与 SLA
评估供应商支持能力：SLA 指标与赔付条款、支持渠道与响应时长、版本支持周期与升级协助；关键系统要有供应商之外的备份知识。
最后责任时刻
在必须决定时才决定：把决策推迟到掌握足够信息、且仍能承担后果的时点；用接口与配置隔离变化点，避免过早固化实现。