后端能力地图

高谷深陵大约 13 分钟约 4016 字

后端能力地图高清原图

刚进入后端开发时，人很容易把学习计划写成产品清单：Java、Spring Boot、MySQL、Redis、Kafka。清单看起来很长，却解释不了三个更重要的问题：一段代码怎样成为正在服务流量的进程，一次请求为什么会跨过协议、线程、连接和事务边界，故障发生时应该先看哪一层证据。

能力地图不是“什么都学一点”的目录。它是一套定位坐标：面对需求时知道该调用哪类能力，面对故障时知道沿哪条链路反推，面对架构变化时知道新增的收益和成本落在哪些边界上。

先用五条主线建立后端坐标

接下来把后端工程的 25 个知识域放进交付链、请求链、数据链、失败链和治理链，逐一说明每组能力解决什么问题、依赖哪些知识，以及怎样用最小实验验证掌握程度。

这张地图只负责建立稳定坐标。Java 语法、JVM 收集器、Spring 源码、数据库索引和消息产品部署会在对应专题沿机制展开，任何一家公司的技术栈也不会被当成通用答案。

跑通第一个坐标只需要本地 HTTP 环境

阅读不要求已有框架经验。为了完成文中的最小实验，需要一台能运行 curl 的机器，以及任意一种能监听 HTTP 端口的开发环境。示例使用 Python 只是为了减少准备成本，并不代表生产技术栈选择。

如果处在企业内网或离线环境，实验不需要访问外网：服务监听回环地址 127.0.0.1，客户端也在本机访问。后续选择语言、框架和依赖时，再由团队的制品仓库、版本基线与供应链策略决定下载入口。

这张地图在知识树中的位置

这张地图是 25 个知识域的根节点。它先建立“交付链、请求链、数据链、失败链、治理链”五条主线；后续文章再把每个节点拆成可运行机制。

这不是严格的瀑布顺序。真实系统里，观测会反过来约束代码，安全会贯穿每一层，测试会在交付前建立证据。不过学习时仍然要先抓住因果顺序：先知道对象怎样运行，再讨论怎样优化和治理。

不要按产品名学习，要按问题闭环学习

假设需求是“提交订单”。只会产品名的人可能立刻说要 Spring Boot、MySQL、Redis 和 MQ。工程上的第一轮问题却应该是：

客户端提交的资源和操作怎样用 HTTP 契约表达？输入从字节变成对象时，在哪校验身份、权限和业务约束？哪些状态必须在同一个本地事务中提交？

请求超时后，客户端重试会不会创建两个订单？消息发送失败时，数据库状态怎样与下游最终收敛？如何用日志、指标和链路证明请求走到了哪一步？

一个知识点只有进入这样的因果链，才变成工程能力。框架 API 会升级，产品会替换，但输入边界、执行资源、状态提交、失败窗口和证据链不会消失。

25 个知识域怎样组成完整路径

工程入口：先建立共同语言

工程入口包含能力地图、请求到响应、代码到进程、架构形态和环境边界。它回答“系统由什么组成”而不是“某个 API 怎么写”。

完成这一层后，读者应能画出一个最小服务的运行图，区分源码、构建产物、进程、端口、连接、请求、线程、事务和外部依赖，且不会把开发环境跑通误判为生产可用。

Java、JVM 与并发：理解进程内部发生了什么

Java 提供类型、对象、异常、集合、泛型、反射和工程表达能力；JVM 负责把类文件变成运行时类型，管理内存、执行代码和回收对象；并发专题解释多个任务怎样共享 CPU、内存和有限资源。

这三层共同回答：代码为何能运行、对象在哪里、线程为何等待、可见性怎样成立、队列为何堆积、CPU 和内存异常怎样形成。没有这层基础，框架故障很容易被误判成“Spring 有问题”。

网络、Servlet、Spring 与 MVC：理解请求怎样进入应用

网络与 Web 负责 DNS、TCP、TLS、HTTP、代理、超时和连接复用。Servlet 容器把网络事件转成 Java Web 请求处理。Spring Framework 管理对象、依赖、代理和事务，Spring Boot 负责应用装配和生命周期，Spring MVC 把 HTTP 输入映射成处理器调用和协议响应。

这一组能力要形成一条连续链，而不是五门互不相干的课程：

数据访问、缓存、消息和搜索：管理状态与成本

数据访问负责持久状态、事务和查询；缓存用更靠近计算的位置换取低延迟，但引入失效窗口；消息把同步调用变成异步投递，同时带来重复、丢失、乱序和积压问题；搜索把业务数据重建为适合检索或分析的结构。

它们不是可以随意叠加的“性能组件”。每增加一份状态副本，就增加一条一致性与恢复责任；每增加一个异步边界，就增加一种未完成状态。

微服务、分布式系统和安全：管理跨边界协作

微服务把进程内调用变成网络调用。分布式系统处理分区、复制、时间、协调与最终一致。安全则明确哪些输入、身份、权限和数据不能被默认信任。

拆分服务不是代码目录调整，而是把函数调用变成会超时、会重试、可能只完成一半的远程协作。只有当独立交付、隔离或组织边界的收益大于这些成本，拆分才成立。

测试、可观测、性能和可靠性：用证据控制失败

测试在变更前证明预期行为；日志、指标与链路在运行中留下证据；性能容量解释延迟、吞吐、并发和排队；可靠性通过超时、幂等、隔离、限流、降级和恢复把故障限制在局部。

这组能力的共同产物不是“平台接入完成”，而是可回答的问题：什么时候开始退化、影响了谁、卡在哪一层、还能承受多少、怎样止血、怎样证明恢复。

调度、文件、契约、工程质量和架构演进：完成长期交付

调度异步管理非请求型任务；文件与对象存储处理大对象数据流；API 与事件契约控制跨团队兼容；工程结构和代码质量限制依赖腐化；架构演进把前面所有专题放进真实约束中做取舍。

这一层提醒我们：系统上线不是终点。版本升级、容量变化、团队协作、例外审批、灰度和回滚，才决定它能否长期维护。

用一个最小服务把地图跑起来

在空目录执行：

python -m http.server 8080 --bind 127.0.0.1

另开终端请求它：

curl -v --max-time 2 http://127.0.0.1:8080/

预期能看到三个层次的证据：服务端终端打印访问记录；curl 的 Connected to 表明连接建立；请求行、响应状态和响应头表明 HTTP 交换完成。即使这个服务没有数据库和业务框架，它也已经包含源码/运行入口、进程、监听地址、端口、连接、请求、响应和日志这些基础对象。

接着确认监听者。Linux 可以执行：

ss -lntp | grep ':8080'

Windows PowerShell 可以执行：

Get-NetTCPConnection -LocalPort 8080 -State Listen

最后按 Ctrl+C 停止进程，再重复 curl。如果请求失败且服务端不再有日志，说明失败发生在业务处理之前。这个反向实验很重要：能根据缺失的证据判断请求尚未跨过哪条边界，才算开始具备排障能力。

把实验映射回能力域

curl 的请求和状态码属于 HTTP 契约；端口监听属于进程与网络；访问日志属于可观测；--max-time 是客户端超时边界；绑定 127.0.0.1 是网络暴露与安全边界；停止进程后的失败属于可靠性与生命周期。

当服务再接入数据库时，还会出现连接池和事务；接入缓存会出现副本与失效；发送消息会出现投递状态；拆成多个服务会出现跨进程超时和上下文传播。地图的作用，就是让新增对象和新增责任一一对应。

怎样证明一个知识域已经学会

阅读完文档或复制成功 Demo 只能证明“见过”。一个知识域至少要形成四类证据。

第一类是正常路径证据：请求、任务或数据确实走完整条链。第二类是反向验证：故意停止进程、填错端口、收紧超时或制造无效输入，观察失败发生在哪。第三类是机制证据：日志、线程栈、抓包、执行计划或指标能解释现象。第四类是治理证据：团队知道上线门禁、容量假设、权限边界和回滚条件。

可以用同一个学习循环推进全部专题：

典型故障：先找断掉的边界

“接口慢”不是根因，它只是客户端观察到的总时间。真正的等待可能发生在 DNS、建连、TLS、代理排队、服务器线程池、数据库连接池、锁、下游调用或响应写回。

排障时先固定一个关联标识和时间窗，再按边界找证据：客户端是否发出、入口是否收到、应用是否开始处理、依赖是否收到、事务是否完成、响应是否写出。某一层没有证据，不等于这一层一定坏了，也可能是观测缺失；因此可观测本身就是架构能力，而不是故障发生后才补的日志。

常见误区还有：把 CPU 低当成系统空闲，忽略线程可能都在等待；把重试当成恢复手段，忽略重复写和流量放大；把缓存命中率高当成健康，忽略热点、过期风暴和源站承载；把微服务数量当成先进程度，忽略网络和一致性成本。

性能、安全与架构取舍贯穿全图

性能不是最后统一调优。每一层都有自己的有限资源：CPU 时间片、堆内存、线程、连接、队列、文件描述符、数据库锁和消息分区。优化某一层可能只是把排队转移到下一层。容量评估必须沿端到端路径找到最窄资源，并保留过载保护。

安全也不是只在登录接口出现。源码依赖有供应链风险，配置有凭证风险，监听地址决定暴露面，HTTP 输入需要校验，数据库需要最小权限，日志要避免泄漏，缓存和消息要隔离租户，文件要控制类型、大小和生命周期。

架构选择则要回答四件事：当前瓶颈的证据是什么，新增组件解决哪一个明确问题，它引入哪些新的失败状态，退出或回滚路径是什么。答不出这四问时，保持简单通常更安全。

团队怎样把地图变成治理机制

团队可以让每个服务维护一张“系统边界卡”，记录入口契约、运行时与资源上限、同步依赖、异步依赖、状态所有者、超时预算、关键指标、数据敏感级别、发布与回滚条件。它不是一次性架构图，而要随变更评审更新。

代码评审不只检查风格，还应追问：是否增加了新的网络调用、线程池、连接池、状态副本或重试；对应的超时、容量、观测、权限和失败收敛是否存在。架构评审也不以组件图结束，而以可验证假设结束。

建议把学习成果沉淀成可执行门禁：最小实验进入示例仓库，反向实验进入测试，关键指标进入仪表盘，依赖与超时进入配置基线，事故发现的新边界进入检查表。这样知识才不会只留在个人脑中。