单题备考 · d01
微服务治理
真题出处：2021 年论文 试题四「论微服务架构及其应用」。本页给出一篇可直接背的合规论文 + 可交互治理演练台。
① 会考什么
2021 年 论文 · 试题四（原文逐字）
请围绕"论微服务架构及其应用"论题，依次从以下三个方面进行论述。
- 概要叙述你所参与管理或开发的软件项目，以及你在其中所承担的主要工作。
- 简要描述微服务优点。
- 具体阐述如何基于微服务架构进行软件设计实现的。
频次与权重。按 docs/真题分析.md：架构风格/模式类 9 年出现 10 次以上，每年必有一题，是权重最高的族。同族的「云原生 / 微服务 / SOA / Serverless / EDA / 六边形」9 年共出现 5 次（2020 云原生、2021 微服务、2024下 SOA、2025下 Serverless、2026上 六边形），近三年连续不断。微服务本体 2021 年考过 1 次，但作为架构风格族的代表，仍是必练题。
架构风格题不能靠建 Demo 覆盖，靠「一架构多说法」——用微服务的语言重述同一套项目。本页的论文骨架（网关治理 + 容错 + 限流可观测）同样能改写成云原生、SOA、Serverless 的版本。
② 一句话讲清
TL;DR：微服务把单体拆成独立部署的小服务，好处是独立部署、故障隔离、弹性扩展；真正的难点不在拆，而在拆完之后的治理——注册发现、网关连接管理、重试超时熔断、限流与可观测。我按 DDD 拆出六个 Go 服务，用一个轻量注册中心加一道自研网关把它们管住，网关一处连接池缺陷修完吞吐翻 3.4 倍，单实例故障下错误率从 50% 收敛到近零。
③ 机制讲解
微服务的治理可以拆成两条独立的链路来理解：入口的吞吐治理（网关连接管理）和运行时的故障容错（重试 / 超时 / 熔断 / 摘除）。下面两个演练台分别把这两条链路跑一遍，"不这么做会怎样"的对照就摆在数字里。
演练台 A · 网关连接池：吞吐的上限
网关每个请求是否复用 TCP 连接，决定了整条链路能扛多少 QPS。拖动请求速率、切换连接池，看指标。（教学模拟，真值见下方对照表）
吞吐
—
p99 时延
—
错误率
—
TIME_WAIT
—
连接池关闭：连接每请求新建，用完即关。
不这么做会怎样：每请求新建连接 → 连接用完即进 TIME_WAIT（约 120 秒才回收）→ 测试机 16384 个临时端口约 4 秒见底 → 网关开始返回 502。实测吞吐被压在 3852 req/s、错误率 0.22%、p99 73ms；开启连接池后吞吐 12918 req/s、错误率归零、p99 降到 4ms、TIME_WAIT 从 14790 降到 178。
演练台 B · 实例故障：治理开关的对照
2 个实例轮询，第 6 秒杀掉一个。切换「重试 / 熔断 / 健康摘除」，观察故障影响窗口与错误率怎么变。
故障影响窗口
0 s
窗口内错误率
0%
累计失败 (502)
0
累计成功
0
0s时间 → 20s（第 6s 注入故障）
未开始
不这么做会怎样（E1 实测基线）：无任何治理时，杀一个实例 → 网关在健康状态刷新前仍把一半流量轮询给死实例 → 故障窗口 4~5 秒、窗口内错误率约 50%、单次压测累计 13439~19056 次 502。注意成功请求的 p95 仍是 4ms——死实例端口立即拒绝连接，是快速失败，不是响应变慢。
关键区分：快速失败用重试就能救（换实例即成功）；响应变慢只能靠超时 + 熔断救。健康摘除负责把故障实例移出轮询列表，缩短窗口；重试负责在窗口内把失败改判成功；熔断负责在连续故障时快速跳过。三者解决的是不同问题，不能互相替代。
④ 落到我们平台
网关 = 治理入口
fazi 平台的 gateway：反向代理 + 轮询负载均衡 + 全局连接池，全平台的流量都从这里进。E0 的连接池缺陷就出在这里。
服务 = DDD 限界上下文
会员、社交、存证、培训报名、法律咨询五个业务服务，各自独立部署、独立扩容，统一 Go + Gin。
注册发现 = 自研轻量组件
不引入重型注册中心。各实例启动注册、周期心跳，注册中心把健康列表下发给网关——用 PG 表 + 心跳即可。
取舍：能省则省
云托管容器服务承载实例；缓存用进程内缓存或 PG，不再引入独立缓存组件；把运维精力留给治理逻辑本身。
治理的边界也要说清：跨服务一致性我们用本地消息表 + 补偿做最终一致，而不是分布式事务框架；链路排查靠统一采集的请求量/错误率/时延分位数与熔断状态，把 MTTR 从 45 分钟压到 8 分钟。
⑤ 完整论文
六段全文（摘要 + 正文，约 2.5 千字）
摘要
2025年3月，我作为河南省法律咨询协会唯一的全栈架构师，主导建设了协会数字平台。该项目面向协会500名常用会员及未来3000名潜在用户，涵盖信息发布、社交系统、电子存证、培训报名、法律智能咨询五大模块。我在项目中承担需求分析、架构设计、编码实现、部署运维的全部技术职责。本文以该项目为例，讨论了微服务架构在实际项目中的应用。文章首先介绍项目背景和微服务架构的基本概念，然后详细阐述我们在架构设计、技术选型、问题解决等方面的具体实践，最后总结项目经验和不足。通过微服务架构的有效应用，平台于2026年6月上线，法律问答Recall@20达0.92，P95响应380毫秒，缓存命中率92%，可用性99.95%，MTTR从45分钟降至8分钟。实践表明，在协会资源支持下，一人全栈架构师借助云托管服务和AI辅助开发，可以交付生产级法律数字化平台。
一、项目背景
河南省法律咨询协会成立于2004年，现有理事119名、法学专家62名、律师团成员78名、讲师团成员69名，承担法制宣传、法律培训、法律咨询、调解仲裁等职能。协会原有官网仅能发布新闻，会员管理、法律咨询、电子存证依赖线下和微信群，数据分散、效率低下。协会服务对象中有大量基层群众和中小微企业，法律术语看不懂、流程搞不清、律师咨询门槛高，维权成本居高不下。
2025年3月，协会理事会决定建设数字平台，并给予充分资源支持。我作为协会唯一的全栈架构师，承担从需求分析、架构设计、编码实现到部署运维的全部技术职责。平台以"fazi协会数字平台"为中心，涵盖信息发布、社交系统、电子存证、培训报名、法律智能咨询五大模块。前端采用 Nuxt 4 SSR + Vue 3.5 + Tailwind 4，后端采用 Go 1.26 + Gin + pgx 手写 SQL，数据库 PostgreSQL 18，部署在云托管容器服务上。平台常用用户500人，未来半年潜在用户3000人，峰值QPS约800。
技术选型上，我基于"一人全栈、生产级标准"原则做了三个关键决策：一是采用云托管服务替代自建中间件，把运维精力留给业务；二是以 PostgreSQL 18 + pgvector 作为统一数据平台，同时承载关系数据、向量检索、JSONB 文档和全文检索；三是引入 Claude Code / Vibe Coding 辅助开发，提升一人开发效率。协会在法律知识库、律师资源、经费预算上给予全力支持，使我能够专注于架构决策和业务实现。
二、微服务架构与治理
（以下为正文）
微服务架构是一种把单一应用按业务能力拆分为一组小型、可独立部署服务的架构风格，各服务围绕业务能力构建，通过轻量级通信机制协作。相比单体架构，它具有六方面优点：一是独立部署，每个服务可独立上线升级，不牵动其他服务；二是技术异构，不同服务可选用最适合的技术；三是故障隔离，单个服务故障不会导致整体崩溃；四是弹性扩展，可针对高负载服务单独扩容；五是团队自治，小团队端到端负责一个服务；六是易于理解，每个服务职责单一、代码量小。结合协会一人全栈的现实，我确定四条设计原则：遵循单一职责，每个服务只承担一个业务能力；按领域驱动设计的限界上下文拆分，以业务边界而非技术分层划分服务；数据自治，每个服务只通过自己的接口访问数据；接口优先，先约定接口再并行实现。微服务在带来上述优点的同时，也引入了分布式系统的固有复杂度：实例的注册与发现、请求的路由与负载均衡、调用的超时与重试、故障的隔离与降级、过载下的流量控制。我认为，微服务的成败不在于拆得多细，而在于配套的治理能力是否到位，因此我重点做的是拆分之后的治理设计。
三、服务拆分与网关治理
在协会平台，我按限界上下文把系统拆分为网关、会员、社交、存证、培训报名、法律咨询六个服务，均以 Go 1.26 加 Gin 实现，接口遵循先约定后实现的原则。法律咨询与培训报名流量和复杂度最高，独立部署并按需扩容。服务注册发现不引入重型组件，而是自研一个轻量注册中心：各实例启动时注册地址并周期性心跳，注册中心把健康实例列表下发给网关；网关是整条链路的入口，承担路由与轮询负载均衡。上线前压测时我发现一个隐蔽缺陷：网关每个请求都新建到上游的 TCP 连接，连接用完即关，很快耗尽测试机的临时端口并返回错误，无故障时错误率即有千分之二、吞吐抖动近两倍。定位到根因是反向代理未复用连接、连接池默认每台上游只保留两条空闲连接后，我改为全局共享一个带连接池的传输层，并按上游地址缓存反向代理对象。修复后吞吐从每秒三千八百多提升到一万二千多，p99 时延从七十三毫秒降到四毫秒，端口占用大幅回落，错误率归零。这让我确认：网关的连接管理决定整个集群的性能上限，治理必须从入口做起。
四、跨服务调用的容错治理
拆分之后，跨服务调用的容错成为首要问题。为取得可信的对照，我先测出无治理时的故障基线：压测进行到第 6 秒杀掉一个实例，网关在健康状态刷新前仍把约一半流量轮询到已死实例，形成一个持续 4 到 5 秒的故障窗口，窗口内错误率约 50%，单次压测累计接近两万次失败。值得注意的是，成功请求的 p95 始终是毫秒级——进程退出后端口立即拒绝连接，属于快速失败，而非响应变慢。这一区分决定了治理手段：快速失败可用重试救回，慢响应只能靠超时加熔断。据此我做三层设计。第一，重试：对幂等的读请求，失败后换实例重试一次并退避，配合接口幂等键保证不重复处理，这一步把窗口内的快速失败基本救回。第二，超时与熔断：为每个上游设置连接与读超时，连续失败超过阈值即打开熔断，快速跳过故障实例，避免协程与连接被拖住，冷却后放行少量探测流量决定是否恢复。第三，降级：熔断打开后走本地兜底，例如法律咨询在检索不可用时返回进程内缓存的热门问答，保证核心链路可用。三层叠加后，单实例故障对用户几乎不可见。
五、治理闭环与运行效果
在容错之外，我补齐了治理闭环的最后几环。健康探测与自动摘除：网关按固定间隔探测各实例，连续失败达阈值就从轮询列表移除，恢复后自动放回，这一环把故障窗口从 4 到 5 秒收敛到秒级。限流：在网关按服务配置令牌桶，超限请求快速拒绝并返回排队提示，保护后端不被突发流量打垮，培训报名开放时段的瞬时高峰便由此兜底。可观测：统一采集请求量、错误率、时延分位数与熔断状态，任何异常都能定位到具体服务与实例，MTTR 从 45 分钟降到 8 分钟。在资源取舍上，我坚持用云托管容器服务承载实例、用 PostgreSQL 统一存储，缓存用进程内缓存而不再引入独立组件，注册中心自研而不引入重型中间件，把有限的运维精力集中在治理逻辑本身。此外，跨服务的数据一致性用本地消息表加补偿实现最终一致，避免引入重量级的分布式事务框架。上线后，平台在峰值约 800 QPS 下保持稳定，可用性达 99.95%，法律咨询链路 P95 响应 380 毫秒。
六、总结展望
本项目让我深刻体会到，在资源受限、单人全栈的现实约束下，架构决策的核心不是"用什么最先进的技术"，而是"在约束下做什么取舍"。通过云托管服务、PostgreSQL 统一数据平台和 AI 辅助开发，我把有限的精力集中在业务架构和核心模块上，交付了生产级平台。
不足与改进：一是自动化测试覆盖率不足 60%，回归测试依赖手工，计划引入 AI 辅助测试生成；二是告警体系仍依赖规则阈值，计划引入 AIOps 做智能降噪和根因分析；三是部分业务模块仍为单体，计划按 DDD 限界上下文逐步拆分。
未来，我将继续完善微服务的治理体系，补充链路追踪与更精细的熔断降级策略，为协会会员和基层群众提供更低门槛、更高质量的法律服务。
⑥ 逐段拆解
字数口径为纯汉字（不含标点、数字、字母）。校验命令：bash scripts/verify-pages.sh d01。
| 段 | 讲什么 | 对题干 | 纯汉字 |
|---|---|---|---|
| 摘要 | 项目 + 主题 + 结果指标 | 总起 | 301（区间 300–330） |
| 一、项目背景 | 协会现状、我的职责、技术栈 | 第 1 问 | 459（定稿逐字） |
| 二、理论概述 | 微服务六优点 + 四条拆分原则 + 治理必要性 | 第 2 问 | 421（区间 320–440） |
| 三、实践一 | DDD 拆六服务 + 注册发现 + 网关连接池（E0 真值） | 第 3 问 | 391（区间 320–440） |
| 四、实践二 | 故障基线（E1 真值）+ 重试 / 超时熔断 / 降级 | 第 3 问 | 387（区间 320–440） |
| 五、实践三 | 健康摘除 + 限流 + 可观测 + 资源取舍与效果 | 第 3 问 | 335（区间 320–440） |
| 六、总结展望 | 体会、不足与改进、主题展望 | 收尾 | 251（区间 200–300） |
| 正文 P1–P6 合计（摘要另计） | 2244（区间 2000–2500） | ||
⑦ 答题要点
题干三问 → 本文分段（必须对上）
- 题干第 1 问（项目 + 我的职责）→ 本文第一段。
- 题干第 2 问（微服务优点）→ 本文第二段。
- 题干第 3 问（如何基于微服务架构设计实现）→ 本文第三、四、五段。
✅ 加分
- 优点不背概念，落到本项目：每条优点都对应平台的具体取舍。
- 三问齐全，三段实践分别回答拆分、容错、闭环，逻辑成链。
- 带真实数据与对照：网关吞吐、故障窗口、错误率——数据有对照才可信。
- 写出"快速失败 vs 响应变慢"这类区分，体现真做过而非背模板。
- 讲清资源受限下的取舍（自研注册中心、进程内缓存），符合一人全栈设定。
❌ 扣分
- 只堆微服务概念，不与项目、不与我承担的工作挂钩。
- 大段罗列中间件产品名（注册中心 / 网关 / 配置中心各来一串），却不讲怎么落地。
- 漏答三问中的任何一问，尤其把"优点"写成"缺点"。
- 数据自相矛盾：摘要写 MTTR 8 分钟，正文写 30 分钟。
- 拆得越细越好论：只讲拆分，不讲拆完之后的治理与容错。
⑧ 背诵清单
- 微服务 = 按业务能力拆成一组可独立部署的服务；优点是独立部署、技术异构、故障隔离、弹性扩展、团队自治、易于理解。
- 四条拆分原则：单一职责、DDD 限界上下文、数据自治、接口优先。
- 平台拆六个服务（网关 / 会员 / 社交 / 存证 / 培训报名 / 法律咨询），统一 Go + Gin。
- 网关连接池缺陷：修复前 3852 req/s、错误率 0.22%、p99 73ms；修复后 12918 req/s、错误率 0、p99 4ms。
- 故障基线：单实例宕机窗口 4~5 秒、窗口内错误率约 50%、累计近两万次 502；成功请求 p95 仍是 4ms（快速失败）。
- 三层容错：重试救快速失败，超时 + 熔断救慢响应，降级保核心链路。
- 闭环：健康探测自动摘除把窗口收敛到秒级；网关令牌桶限流保护后端；可观测把 MTTR 从 45 分钟降到 8 分钟。
- 效果：可用性 99.95%、P95 380ms、Recall@20 0.92、缓存命中率 92%。
⑨ 数据来源
| 数据 | 来源 | 标注 |
|---|---|---|
| 网关吞吐 3852 → 12918 req/s；p99 73 → 4ms；TIME_WAIT 14790 → 178；错误率 0.22% → 0 | demo1 实验 E0（真实压测） | 真实实验 |
| 故障窗口 4~5 秒；窗口内错误率约 50%；单次失败 13439 / 19056 次 502 | demo1 实验 E1（真实压测，两次复跑） | 真实实验 |
| 成功请求 p95 仍为 4ms（快速失败） | demo1 实验 E1（真实压测） | 真实实验 |
| 同机发压：服务与发压同机、20 并发，绝对吞吐低于真实能力，相对对比成立 | demo1 环境说明 | 真实实验 |
| 可用性 99.95%；MTTR 45 → 8 分钟；峰值 800 QPS；P95 380ms；Recall@20 0.92；缓存命中率 92% | 成文取值（无法自证的量） | 固化取值 |
| 健康摘除"窗口收敛到秒级"、令牌桶限流、本地缓存降级 | 机制描述（未做实验的机制不写具体数值） | 机制 |
| 演练台 A / B 中的所有数字 | 按真实机制与常量构造的教学模拟，非实测 | 教学模拟 |
真值记录在 demo1-microservice-governance/docs/experiments.md。论文正文中凡引用具体数字处，均为上表「真实实验」或「固化取值」两行；模拟器数字只用于理解机制，不入论文。