软件工程术语库·系统与工程化篇

术语 = 你和 AI 的共享词汇表，叫对名字才能调用 AI 已有的知识。

本篇目录

一、工程实践与工具链
- [1.1 版本控制类](#1.1 版本控制类 "#s1-1")
- [1.2 CI/CD 与部署类](#1.2 CI/CD 与部署类 "#s1-2")
- [1.3 测试类](#1.3 测试类 "#s1-3")
- [1.4 基础工具与协议类](#1.4 基础工具与协议类 "#s1-4")
- [1.5 性能与压测](#1.5 性能与压测 "#s1-5")
- [1.6 依赖与配置管理](#1.6 依赖与配置管理 "#s1-6")
二、网络与通信协议
三、安全开发
四、分布式系统
- [4.1 消息队列](#4.1 消息队列 "#s4-1")
五、数据库与存储
[六、云原生与 SRE](#六、云原生与 SRE "#ch6")
[七、API 设计与服务治理](#七、API 设计与服务治理 "#ch7")

一、工程实践与工具链

1.1 版本控制类

Repository（代码仓库） ：存放项目全部代码 + 完整变更历史的存储库。版本追踪、代码审查、回滚的基础。
Git：分布式版本控制系统。现代软件开发协作的事实标准。
Branch（分支） ：指向提交的可移动指针，用于隔离开发。实现并行开发与功能隔离，避免主干代码不稳定。
Commit（提交） ：一次文件变更的原子记录，包含变更内容、作者、时间、提交信息。代码历史的最小可审计单元。
Merge（合并） ：把一个分支的变更合入另一个分支，保留完整分支拓扑。默认的分支整合方式，适合公共分支。
Pull Request / Merge Request（PR/MR，拉取/合并请求） ：请求将功能分支合并进目标分支的正式流程，附带代码审查、CI 检查。把代码合并从个人动作变成团队质量门禁。
Conflict（合并冲突） ：两个分支修改了同一处代码，Git 无法自动合并。冲突解决质量直接影响代码正确性，需人工确认。
Rebase（变基） ：把当前分支的提交「重放」到目标分支顶端，形成线性提交历史。历史清晰易读；但会重写提交历史，严禁用于多人共享的公共分支。
Cherry-pick（拣选提交） ：把指定提交单独应用到当前分支。选择性合入 bug 修复，不用合入整个分支。
Tag（标签） ：给某次提交打不可变的命名标记（如 v1.0.0）。版本发布的可追溯锚点。
Main/Master Branch（主干分支） ：项目的权威基线分支。生产就绪代码只从它发布，通常设置分支保护，禁止直接推送。
Git Worktree：Git 原生命令，允许同一个仓库同时检出多个分支到不同目录。单人多分支并行开发不用反复 stash 或克隆多个副本。
Hooks（Git 钩子） ：Git 特定事件（提交、推送）触发的自定义脚本。提交前自动跑 lint、测试，强制规范，不通过则阻止提交。

1.2 CI/CD 与部署类

CI（Continuous Integration，持续集成） ：开发者频繁把代码合入主干，每次 push 自动触发构建、测试。早期暴露集成问题，避免「集成地狱」。
Continuous Delivery（持续交付） ：CI 的延伸，软件始终保持可发布状态，发布到生产前保留人工审批。降低发布风险，随时可发布。
Continuous Deployment（持续部署） ：每一次通过自动化测试的合入，直接自动部署到生产环境，无需人工干预。最高发布频率，要求极强的测试、监控、回滚能力。
Pipeline（流水线） ：从代码提交到部署的自动化步骤链（lint→test→build→deploy）。把人工发布流程固化为代码，可重复、可审计。
Build（构建） ：把源代码编译、打包成可运行产物。CI 的第一道门禁------构建不通过，后续步骤都无意义。
Artifact（构建产物） ：构建产生的可分发结果（Jar/Docker 镜像/前端静态包）。流水线各阶段传递的实体，也是回滚的基础。
Staging（预发布环境） ：和生产配置一致的测试环境。上线前最后一轮验证，发现生产环境特有的问题。
Production（生产环境） ：面向真实用户的线上环境。稳定性直接决定业务收入，部署约束最严格。
Blue-Green Deployment（蓝绿部署） ：同时保留两个相同环境（蓝/绿），新版本部署到空闲环境，验证后切流量。零停机发布，出问题秒级切回旧版本。
Canary Deployment（金丝雀发布） ：先把新版本推给小比例用户，验证稳定后再逐步全量。小流量验证，降低故障影响范围。
Rolling Update（滚动更新） ：逐个替换旧版本实例，直到全部升级完成。K8s 默认部署策略，零停机，但回滚速度较慢。
Rollback（回滚） ：新版本出问题时恢复到上一个稳定版本。降低故障影响的最后一道防线。
Feature Flag（特性开关） ：用配置控制功能是否对用户可见，无需重新部署。功能和发布解耦，可灰度、可快速关闭问题功能。

1.3 测试类

Unit Test（单元测试） ：针对最小代码单元（函数/类）的测试，隔离所有外部依赖。运行快、定位问题准，是测试金字塔的基础。
Integration Test（集成测试） ：验证多个模块/真实依赖（数据库、API）协同工作。发现单元测试覆盖不到的接口契约断裂问题。
E2E Test（端到端测试） ：以真实用户视角走完完整业务流程。验证「功能真的能用」的最终证明，但运行慢、维护成本高。
Test Pyramid（测试金字塔） ：测试应按「单元测试多、集成测试中、E2E 测试少」的比例组织。平衡测试速度、覆盖率和维护成本。
TDD（Test-Driven Development，测试驱动开发） ：红（写失败测试）→ 绿（写最小实现让测试通过）→ 重构，循环开发。不只是测试方法，更是设计方法，倒逼代码可测试。
BDD（Behavior-Driven Development，行为驱动开发） ：用自然语言描述用户场景作为测试用例。拉齐产品、开发、测试对需求的理解。
Stub（桩对象） ：测试中提供预设返回值的替身对象，不验证交互。隔离外部依赖，只验证被测对象的状态。
Mock（模拟对象） ：预定期望调用的替身对象，验证方法是否被正确调用。验证交互行为，适合测试协作逻辑；过度使用会让测试脆弱。
Fake（假对象） ：有简化实现的替身（如内存数据库）。比 stub/mock 更接近真实行为，且运行快。
Fixture（测试固件） ：为测试搭建的固定环境和基础数据。保证测试可重复、可独立运行。
Regression Test（回归测试） ：代码改动后重跑所有已有测试。确认新变更没有破坏原有功能。
Smoke Test（冒烟测试） ：新版本部署后快速验证核心功能是否正常。最短时间判断构建是否可用，不合格直接打回。
Snapshot Test（快照测试） ：记录 UI/输出结果作为基准，后续对比检测非预期变化。UI 回归检测的轻量手段。
Mutation Testing（变异测试） ：故意修改代码（变异），检查测试是否能失败。衡量测试用例的有效性，发现「假覆盖」。

1.4 基础工具与协议类

CLI（Command-Line Interface，命令行界面） ：通过文本命令操作程序的界面。可脚本化、可自动化，是工程工具的标准交互方式。
API（Application Programming Interface，应用程序接口） ：定义组件间通信的契约。模块化、服务化的标准语言。
SDK（Software Development Kit，软件开发工具包） ：封装 API 的库、工具、文档集合。把「手搓 HTTP 请求」变成「import 即用」，降低接入成本。
Webhook：事件发生时，服务端主动向客户端配置的 URL 发送 HTTP 回调。近实时事件通知，避免客户端轮询浪费资源；需做验签、HTTPS、幂等处理。
Hook（钩子） ：在特定生命周期事件点插入自定义逻辑的机制。不修改主程序即可扩展、拦截行为（Git Hook、Claude Code Hooks 都是此机制）。
MCP（Model Context Protocol，模型上下文协议） ：Anthropic 提出的标准协议，让 AI 应用通过统一接口连接外部数据源和工具。解决 AI 工具和数据源的对接碎片化问题，是 LLM 生态的「USB 接口」。
Middleware（中间件） ：请求/响应处理链上的可插拔组件。把鉴权、日志、限流等横切关注点从业务代码中剥离。
HTTP/HTTPS：Web 客户端-服务器请求-响应的基础协议，HTTPS 是加密版。所有 Web API、浏览器通信的基础。
JSON：轻量键值对数据交换格式。现代 API 数据交换的事实标准。
YAML：用缩进表达层级的人类可读配置格式。CI/CD 配置、K8s 清单的事实标准。
Markdown：轻量标记语言。技术文档、README、AI 提示词的事实标准格式。

1.5 性能与压测

QPS（Queries Per Second，每秒查询数） ：服务每秒处理的请求数。衡量服务吞吐量的核心指标。
TPS（Transactions Per Second，每秒事务数） ：每秒处理的完整事务数（一个事务可能包含多个请求）。衡量业务处理能力，比QPS更贴近业务。
RT（Response Time，响应时间） ：从请求发出到收到响应的总耗时。用户体验的核心指标。
Percentile（分位值） ：P50/P95/P99，如P99=100ms表示99%的请求响应时间小于100ms。比平均值更能反映长尾延迟，平均值会掩盖慢请求。
Throughput（吞吐量） ：单位时间内系统处理的请求/数据量。衡量系统处理能力的核心指标。
Concurrency（并发数） ：系统同时处理的请求/用户数。压测的核心参数，并发数和QPS、RT互相影响。
Load Testing（负载测试） ：逐步增加并发，找到系统在满足性能指标下的最大承载能力。容量规划的基础。
Stress Testing（压力测试） ：超过系统预期负载持续压测，找到系统瓶颈和崩溃点。验证系统极限和故障恢复能力。
Benchmark（基准测试） ：在标准环境下跑固定用例，得到性能基准。版本迭代时对比性能变化，优化前后对比。
Capacity Planning（容量规划） ：根据预估流量计算需要多少服务器、资源。避免资源浪费或容量不足导致故障。
Bottleneck（瓶颈） ：限制系统整体性能的最慢环节。性能优化要先找瓶颈，不要盲目优化。
Profiling（性能剖析） ：运行时收集CPU、内存、IO占用，找到热点代码。性能优化的前提，不做剖析的优化都是瞎猜。

1.6 依赖与配置管理

Semantic Versioning（语义化版本，SemVer） ：版本号格式主版本.次版本.修订号，不兼容改主版本、向下兼容加功能改次版本、bug修复改修订号。依赖升级时判断兼容性的标准。
Transitive Dependency（传递依赖） ：你依赖的库又依赖的其他库。会导致依赖冲突、版本不一致，是依赖问题的主要来源。
Dependency Conflict（依赖冲突） ：多个库依赖同一个库的不同版本。可能导致编译失败或运行时NoSuchMethodError。
Lock File（锁文件） ：记录所有依赖（包括传递依赖）的精确版本号（package-lock.json/yarn.lock/gradle.lockfile）。保证不同环境安装的依赖版本完全一致，避免「我本地能跑」。
Maven/Gradle：Java/Kotlin生态的依赖管理和构建工具。Android和Java后端的标准构建工具。
npm/pnpm/yarn：Node.js生态的包管理工具。前端依赖管理的标准工具。
Configuration Center（配置中心） ：集中管理所有环境配置，支持动态下发、热更新。多环境、多实例配置统一管理，改配置不用重新部署。
Environment Variable（环境变量） ：操作系统级别的变量，不同环境可设置不同值。配置和代码分离，十二要素应用的标准实践。
Multi-Environment（多环境） ：通常分dev（开发）、test（测试）、staging（预发布）、prod（生产）。隔离开发测试和生产，避免影响线上用户。
Hotfix（热修复） ：线上紧急bug不发版本，直接打补丁修复。快速修复线上严重问题，缩短故障时间。

二、网络与通信协议

TCP（传输控制协议） ：面向连接、可靠、有序的传输层协议，三次握手建立连接。HTTP、数据库连接等需要可靠性的场景都基于 TCP。
UDP（用户数据报协议） ：无连接、不保证可靠、无序的传输层协议，速度快。适合视频通话、直播、DNS 查询等对延迟敏感、允许少量丢包的场景。
IP（网际协议） ：网络层协议，负责给设备寻址和路由数据包。互联网的基础，TCP/UDP 都运行在 IP 之上。
DNS（域名系统） ：把域名解析为 IP 地址的分布式系统。用户不用记 IP 地址，是互联网的「电话簿」。
CDN（内容分发网络） ：部署在各地的边缘节点缓存静态资源。用户从最近节点获取资源，降低延迟、减轻源站压力。
WebSocket：全双工通信协议，建立一次连接即可双向实时发数据。适合聊天、实时通知、协同编辑等实时场景，比 HTTP 轮询效率高。
HTTP/2：HTTP 第二个大版本，支持多路复用、头部压缩、服务器推送。解决 HTTP/1.1 队头阻塞问题，提升页面加载速度。
HTTP/3：基于 QUIC（UDP）的 HTTP 版本，进一步降低连接延迟。弱网环境下性能显著提升，是未来方向。
TLS/SSL：传输层加密协议，为通信提供加密、认证、完整性保护。HTTPS 的基础，防止数据被窃听、篡改。
REST：基于 HTTP 方法的资源风格 API 设计规范，无状态、用 URL 定位资源。最通用、最易理解的 API 风格，生态成熟。
GraphQL：Facebook 提出的 API 查询语言，客户端按需指定返回字段。解决 REST 接口冗余、多次请求的问题，适合前端复杂场景。
gRPC：Google 推出的高性能 RPC 框架，基于 HTTP/2、Protobuf 序列化。微服务间通信性能远高于 JSON REST，强类型、代码生成友好。
RPC（远程过程调用） ：像调用本地方法一样调用远程服务的接口。微服务间通信的编程模型更简单，屏蔽网络细节。

三、安全开发

OWASP Top 10：OWASP 组织每几年发布的十大最严重 Web 安全风险。Web 安全的基础检查清单，所有开发都应了解。
XSS（跨站脚本攻击） ：攻击者把恶意脚本注入到网页中，其他用户访问时执行。可窃取用户 Cookie、伪造用户操作，前端必须做输入转义。
SQL 注入：攻击者把恶意 SQL 拼接到参数中，被数据库执行。可拖库、删表，是最古老也最常见的后端漏洞，必须用参数化查询。
CSRF（跨站请求伪造） ：诱导已登录用户访问恶意网站，冒用用户身份发请求。可执行用户不知情的操作，需用 CSRF Token、SameSite Cookie 防护。
SSRF（服务端请求伪造） ：攻击者让服务器请求内网或敏感地址。可探测内网、攻击内部服务，云环境下可窃取元数据凭证。
Authentication（认证） ：验证「你是谁」，如登录、Token 校验。所有系统的第一道安全门。
Authorization（授权） ：验证「你能做什么」，如权限、角色校验。防止越权访问数据和功能。
RBAC（基于角色的访问控制） ：给角色分配权限，用户属于角色。最通用的权限模型，简单易维护。
ABAC（基于属性的访问控制） ：根据用户、资源、环境属性动态判断权限。适合复杂权限场景，更灵活但更复杂。
JWT（JSON Web Token） ：无状态的身份令牌，包含签名的用户信息。前后端分离、微服务场景最常用的认证方案；注意不要存敏感信息，不要设置过长有效期。
OAuth 2.0：第三方授权框架，允许第三方应用获取用户有限权限，无需给密码。微信/Google 登录、第三方授权的标准协议。
OIDC（OpenID Connect） ：基于 OAuth 2.0 的身份认证层。OAuth 是授权协议，OIDC 才是标准的认证协议。
Least Privilege（最小权限） ：程序、用户、服务只授予完成任务必需的最小权限。缩小攻击面，一个服务被攻破不会影响全局。
Defense in Depth（纵深防御） ：多层安全控制，一层被攻破还有其他层。不依赖单一安全措施，提升整体安全性。
Secure by Default（默认安全） ：系统默认配置就是安全的，不需要用户手动加固。避免用户因配置不当引入安全漏洞。
Input Validation（输入校验） ：所有外部输入都必须校验格式、长度、类型。永远不要信任用户输入，是绝大多数漏洞的第一道防线。
Output Encoding（输出编码） ：输出到 HTML/JS/SQL 时做对应编码。防止注入攻击，XSS 的核心防护手段。
Secret Management（密钥管理） ：密钥、密码、证书不硬编码在代码里，用专用服务管理。代码仓库泄露即密钥泄露，是最常见的低级安全事故。
Dependency Scanning（依赖扫描） ：扫描第三方依赖的已知漏洞。绝大多数应用 80% 代码是依赖，Log4j 级别的漏洞只能靠扫描发现。

四、分布式系统

CAP Theorem（CAP 定理） ：分布式系统只能同时满足一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）中的两个。分布式架构选型的基础理论，网络分区不可避免，因此实际是在 CP 和 AP 之间选择。
BASE Theory（BASE 理论） ：基本可用（Basically Available）、软状态（Soft State）、最终一致性（Eventually Consistent）。CAP 的工程落地，大多数互联网系统用最终一致性换取高可用。
Consistency（一致性） ：所有节点在同一时间看到相同数据。金融、账务等场景必须强一致，但会牺牲可用性。
Availability（可用性） ：每个请求都能得到非错误响应，但不保证是最新数据。
Partition Tolerance（分区容错） ：网络分区时系统仍能继续运行。网络不可靠是必然的，分布式系统必须容忍分区。
Eventual Consistency（最终一致性） ：数据更新后，经过一段时间同步，所有副本最终达到一致。高可用分布式系统的标准一致性模型，适合大多数非金融场景。
Strong Consistency（强一致性） ：写入成功后，所有后续读取都能读到最新值。数据强一致，但性能低、可用性差。
Idempotency（幂等性） ：见《编码与设计篇》2.4 节，分布式重试的基础。
Distributed Transaction（分布式事务） ：跨多个服务/数据库的事务。微服务场景下的数据一致性难题，没有完美方案，需根据场景权衡。
Saga Pattern：分布式事务方案，拆成一系列本地事务，每个有对应补偿操作，失败则反向补偿。长事务、跨服务事务的主流方案，最终一致。
TCC（Try-Confirm-Cancel） ：两阶段分布式事务，Try 预留资源、Confirm 确认、Cancel 取消。性能好、一致性强，但业务侵入性大，适合金融场景。
2PC（两阶段提交） ：协调者先问所有参与者能否提交，都同意再统一提交。强一致分布式事务协议，但同步阻塞、单点故障，性能差。
Consensus Algorithm（共识算法） ：让多个节点对某个值达成一致的算法（Paxos/Raft/Zab）。分布式协调、主从选举、配置中心的基础。
Raft：易理解的共识算法，通过选举领导者、日志复制实现一致。etcd、Consul 都用 Raft，是目前最主流的共识算法。
Paxos：Lamport 提出的经典共识算法，理论严谨但难理解实现。分布式共识的理论基础。
Service Discovery（服务发现） ：服务自动找到彼此的网络地址。微服务实例动态扩缩容，不能硬编码地址。
Load Balancer（负载均衡器） ：把请求分发到多个服务实例。水平扩展、高可用的基础，分四层（TCP）和七层（HTTP）负载。
Circuit Breaker（熔断器） ：下游服务故障率达到阈值时，直接熔断不发请求，一段时间后尝试恢复。防止故障级联，避免雪崩。
Rate Limiting（限流） ：限制单位时间的请求数。保护服务不被突发流量打垮，常见算法有令牌桶、漏桶、滑动窗口。
Bulkhead（舱壁模式） ：把线程池、资源按服务隔离，一个慢服务不占满所有资源。故障隔离，防止单个依赖拖垮整个应用。
Retry（重试） ：请求失败后自动重试。应对临时网络故障，但必须设置退避策略和最大次数，且接口必须幂等。
Backoff（退避） ：重试间隔逐步增加（指数退避）。避免故障服务被重试流量打垮。
Distributed Lock（分布式锁） ：跨进程、跨服务的互斥锁，通常基于 Redis/ZooKeeper 实现。分布式环境下共享资源的互斥访问，但要注意锁超时、可重入问题。
Distributed Trace（分布式链路追踪） ：追踪一个请求经过所有服务的调用链和耗时。微服务排障的核心手段，标准是 OpenTelemetry。

4.1 消息队列

Message Queue（消息队列，MQ） ：跨进程、跨服务的异步通信中间件（Kafka/RabbitMQ/RocketMQ）。解耦、削峰填谷、异步处理，是分布式系统的核心组件。
Delivery Guarantee（投递保证） ：分至少一次（At-least-once，可能重复）、至多一次（At-most-once，可能丢）、恰好一次（Exactly-once，不丢不重）。不同业务场景选不同保证级别，金融场景需要恰好一次。
Consumer Group（消费组） ：一组消费者共同消费一个Topic，一条消息只发给组内一个消费者。实现消费端水平扩展，不同消费组互不影响。
Partition（分区） ：Topic分成多个分区，分区内有序，不同分区可并行处理。Kafka水平扩展的基础，分区数决定最大并行度。
Replica（副本） ：每个分区有多个副本，主副本写，从副本同步数据。保证高可用，主副本挂了从副本可以顶上。
Message Backlog（消息积压） ：生产速度大于消费速度，消息在队列里堆积。会导致消息延迟越来越大，需要及时扩容消费者。
Dead Letter Queue（死信队列） ：见《编码与设计篇》2.4 节，消费失败的消息进入死信队列。
Idempotent Consumer（幂等消费者） ：重复消费同一条消息结果一样。至少一次投递会导致重复消费，消费端必须保证幂等。
Orderly Consumption（顺序消费） ：保证消息按发送顺序消费。订单状态流转等场景必须保证顺序，只能在单分区内实现。

五、数据库与存储

RDBMS（关系型数据库） ：基于关系模型、用表存储数据、支持 SQL 的数据库（MySQL/PostgreSQL/Oracle）。事务支持强、数据一致，是大多数业务系统的主力存储。
NoSQL：非关系型数据库的统称，分键值、文档、列族、图四类。适合高并发、大数据量、灵活 schema 场景，是关系型数据库的补充。
Key-Value Store（键值存储） ：Redis 为代表，按 key 存取 value。性能极高，适合缓存、会话、排行榜。
Document Store（文档数据库） ：MongoDB 为代表，存储 JSON 文档。schema 灵活，适合快速迭代的业务。
Time-Series Database（时序数据库） ：InfluxDB/Prometheus 为代表，优化时间戳数据存储。监控指标、IoT 数据的专用存储，压缩率和查询性能极高。
Graph Database（图数据库） ：Neo4j 为代表，存储节点和关系。社交关系、知识图谱、推荐系统场景查询效率远高于关系型数据库。
Primary Key（主键） ：表中唯一标识一行的字段。数据定位、关联查询的基础。
Foreign Key（外键） ：引用另一张表主键的字段，维护引用完整性。保证关联数据一致性，但高并发场景常不使用外键，由应用层保证。
Index（索引） ：对表中一列或多列建立排序的数据结构，加速查询。把查询从 O(n) 降到 O(log n)，但会降低写入速度、占用空间。
Clustered Index（聚簇索引） ：索引顺序和数据物理存储顺序一致，一张表只能有一个。主键查询极快，InnoDB 主键就是聚簇索引。
Non-Clustered Index（非聚簇索引） ：索引和数据分开存储，叶子节点存主键。一张表可以有多个，查询可能需要回表。
Covering Index（覆盖索引） ：查询需要的所有字段都在索引里，无需回表。查询性能最高，是索引优化的重要手段。
ACID：事务的四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。关系型数据库事务的核心保证。
Isolation Level（隔离级别） ：SQL 标准定义四个隔离级别：读未提交、读已提交、可重复读、串行化。隔离级别越高，一致性越好但并发性能越低，需权衡。
Dirty Read（脏读） ：读到其他事务未提交的数据。最低隔离级别才会出现，生产环境基本不允许。
Non-Repeatable Read（不可重复读） ：同一事务内两次读同一行，结果不一样（其他事务提交了更新）。读已提交级别会出现，可重复读及以上可避免。
Phantom Read（幻读） ：同一事务内两次范围查询，结果行数不一样（其他事务提交了插入/删除）。可重复读级别下 InnoDB 用间隙锁解决，串行化完全避免。
Normalization（数据库范式） ：设计表结构的规范，减少数据冗余，分 1NF/2NF/3NF/BCNF。避免数据冗余和更新异常，但高范式会增加 join，性能降低。
Denormalization（反范式化） ：故意增加冗余字段，减少 join。读多写少场景用空间换时间，提升查询性能。
Sharding（分库分表） ：把一张大表按某个维度拆到多个库/表。单表数据量过大时的水平扩展手段，但引入分布式事务、跨库查询等复杂度。
Read Replica（只读副本） ：主库同步数据到从库，读请求走从库，写走主库。读写分离，提升读性能，是数据库最常用的扩展手段。
Connection Pool（连接池） ：预先创建数据库连接，复用避免频繁创建。数据库连接创建成本高，连接池是性能必备。
ORM（对象关系映射） ：用对象操作数据库，自动生成 SQL（MyBatis-Plus/Hibernate/Room）。开发效率高、数据库无关，但复杂查询性能可能差，需懂 SQL 才能用好。
Migration（数据库迁移） ：用版本化脚本管理数据库 schema 变更。多环境、多开发者协作时 schema 一致性的保证，工具如 Flyway、Liquibase。
WAL（预写式日志） ：修改数据前先写日志，再写数据。数据库崩溃恢复、主从复制的基础，InnoDB、PostgreSQL 都用此机制。

六、云原生与 SRE

Container（容器） ：轻量级、隔离的运行环境，打包代码和依赖，一次构建到处运行。解决「我本地能跑」问题，比虚拟机轻量。
Docker：最主流的容器运行时。容器事实标准，定义了镜像格式。
Container Image（容器镜像） ：容器的只读模板，包含代码、运行时、依赖。容器分发的标准单元，分层构建、层复用。
Container Registry（镜像仓库） ：存储和分发容器镜像的服务（Docker Hub/Harbor）。镜像的「代码仓库」，CI/CD 流水线拉取镜像的来源。
Kubernetes（K8s） ：Google 开源的容器编排平台，管理容器化应用的部署、扩缩容、故障自愈。云原生操作系统，大规模容器管理的事实标准。
Pod：K8s 最小调度单位，包含一个或多个共享网络/存储的容器。K8s 所有调度都是以 Pod 为单位。
Deployment：K8s 工作负载，管理无状态应用的副本、滚动更新。无状态服务部署的标准资源。
Service：K8s 资源，为一组 Pod 提供稳定的访问地址和负载均衡。Pod IP 会变，Service 提供固定访问入口。
Ingress：K8s 资源，管理集群外部 HTTP 路由访问。统一入口、域名、TLS 终止。
Namespace：K8s 资源隔离单位，一个集群可分多个命名空间。多团队、多环境共享集群时的资源隔离。
Helm：K8s 包管理器，用 Chart 管理一组 K8s 资源。K8s 应用的「npm/apt」，版本化、参数化部署。
Service Mesh（服务网格） ：如 Istio，用 Sidecar 代理处理服务间通信，无侵入实现流量管理、可观测、安全。把服务治理能力从业务代码剥离，下沉到基础设施。
Sidecar Pattern（边车模式） ：在主容器旁部署一个辅助容器，提供通用能力。服务网格的基础，不修改主容器即可扩展能力。
Observability（可观测性） ：通过系统外部输出（Metrics/Logs/Traces）理解系统内部状态。分布式系统排障和优化的基础，三大支柱是指标、日志、链路追踪。
Metrics（指标） ：可聚合的数值数据（QPS、延迟、错误率）。监控和告警的基础，时序数据库存储。
Logs（日志） ：离散的事件记录，带时间戳。问题排查的详细依据，需结构化、可检索。
Traces（链路追踪） ：单个请求经过所有服务的调用链。微服务场景定位慢和错误的核心手段。
SLI（服务水平指标） ：量化服务可靠性的指标（如可用性、延迟 P99）。SLO 的度量基础。
SLO（服务水平目标） ：服务要达到的可靠性目标（如 99.9% 可用性）。团队对可靠性的共识，指导稳定性投入。
SLA（服务水平协议） ：和用户签订的可靠性协议，达不到要赔偿。对外的可靠性承诺，基于 SLO 制定。
Error Budget（错误预算） ：1 - SLO，允许的故障时间。平衡稳定性和迭代速度，预算内可以快速发版，超了就要优先稳定。
MTTR（平均恢复时间） ：从故障发生到恢复的平均时间。衡量应急响应能力的核心指标，越短越好。
MTBF（平均故障间隔） ：两次故障之间的平均时间。衡量系统稳定性。
Blameless Postmortem（无指责复盘） ：故障复盘聚焦流程和系统问题，不追究个人责任。鼓励暴露问题，从故障中学习，是 SRE 文化的核心。
Chaos Engineering（混沌工程） ：主动注入故障（杀实例、断网、高延迟），验证系统韧性。提前发现系统弱点，而不是等生产故障。
Autoscaling（自动扩缩容） ：根据 CPU、QPS 等指标自动增减实例数。应对流量波动，兼顾成本和性能。
Log Level（日志级别） ：DEBUG（调试）、INFO（正常信息）、WARN（警告）、ERROR（错误）、FATAL（致命错误）。不同环境设置不同级别，生产环境通常开INFO及以上，避免日志过多。
Structured Logging（结构化日志） ：日志输出为JSON格式，带traceId、userId等字段。可检索、可聚合，是ELK等日志系统的基础。
APM（Application Performance Monitoring，应用性能监控） ：监控应用性能、错误率、调用链，如SkyWalking、New Relic。自动发现性能瓶颈和错误，比手动打日志全面。
IaC（Infrastructure as Code，基础设施即代码） ：用代码定义服务器、网络、K8s资源，如Terraform、Ansible。基础设施可版本化、可复现、可审计，避免手动配置漂移。
Configuration Drift（配置漂移） ：手动修改服务器配置导致不同环境配置不一致。会导致「我本地能跑」的问题，IaC是解决方法。

七、API 设计与服务治理

REST：见第二章，资源风格 API。
gRPC：见第二章，高性能 RPC。
GraphQL：见第二章，查询语言 API。
OpenAPI/Swagger：REST API 的标准描述格式，可自动生成文档和客户端代码。API 契约的事实标准，前后端协作基础。
Protocol Buffers（Protobuf） ：Google 推出的二进制序列化格式，gRPC 默认使用。比 JSON 小 3-10 倍、快 20-100 倍，强类型。
Idempotency（幂等性） ：见《编码与设计篇》2.4 节，写接口必须考虑。
Pagination（分页） ：大量数据分批返回，常见有 offset 分页和游标分页。一次性返回全量数据会拖垮服务和客户端。
Rate Limiting（限流） ：见第四章，保护服务。
Circuit Breaker（熔断器） ：见第四章，防止级联故障。
Bulkhead（舱壁隔离） ：见第四章，故障隔离。
Retry with Backoff（退避重试） ：见第四章，处理临时故障。
Timeout（超时） ：调用下游设置最大等待时间，超时快速失败。防止慢请求占满线程池，是必须设置的参数。
API Gateway（API 网关） ：系统统一入口，处理路由、鉴权、限流、日志、监控。微服务统一入口，把横切关注点集中处理。
Backward Compatibility（向后兼容） ：新版本 API 不破坏老版本客户端。客户端升级不可控，API 必须向后兼容，不能随便删字段、改类型。
Versioning（API 版本） ：API 变更时通过版本号区分（URL 版本、Header 版本）。不兼容变更时保证老客户端可用。
HATEOAS：REST 成熟度最高级，返回结果包含相关操作链接。理论优雅，但实际工程很少用。
Webhook：见第一章，事件回调。
Polling（轮询） ：客户端定期发请求问有没有新数据。简单但浪费资源，实时场景已被 WebSocket/Webhook 替代。
Long Polling（长轮询） ：请求挂起直到有数据或超时再返回。比短轮询省资源，是 WebSocket 普及前的实时方案。