论文01:从一道真题到一整篇范文

软考架构师 · 考点拆解　2026-10-12

论文写作01：从一道真题到一整篇范文

星期五 · 论文写作第 01 期 · 真题与范文

综合知识 75 题 / 75 分（120—150 分钟）　案例分析 5 选 3 / 75 分（90 分钟）　论文 4 选 1 / 75 分（120 分钟）　三科均 45 分合格

论文题库十年，题型只有一种

论文 4 选 1，120 分钟，2500 到 3000 字。这一期只讲一类题：用一项架构技术撑起一整篇论文。

选的是 2025 年上半年的负载均衡。这个考点 2019 年考过一次，题目叫「论负载均衡技术在 Web 系统中的应用」，2025 年换成「论负载均衡设计技术」，三个方面一模一样。

先讲三个方面怎么对应到段落，再写出完整范文。之后给一道模拟预测题，配第二篇范文。最后附 2016 到 2025 的论文题目清单，十年四十道题。

两篇范文都是示例，项目名和数字换成你自己的。照抄别人的项目，评卷人一眼就看出来。

1.真题：2025 上半年 · 论负载均衡设计技术

2.范文一：按三个方面写完整篇，含摘要与六段正文

3.模拟预测题：论高可用系统的可用性设计及其应用（自拟）

4.范文二：同结构写完整篇

5.十年题目清单：2016 到 2025，共 40 道题

2025 上半年：论负载均衡设计技术

请围绕「论负载均衡设计技术」话题依次从以下三个方面论述：1. 概要叙述你参与设计和实施的项目中负载均衡应用的背景、面临的技术挑战以及你在负载均衡方案设计中承担的主要工作；2. 简要说明负载均衡的基本原理和分类，详细阐述静态负载均衡策略、动态负载均衡策略的特点和适用场景，以及基于不同应用场景的负载均衡设计方法；3. 围绕你在项目中设计和实现的负载均衡方案，详细说明方案的技术架构、关键算法选择、实施过程，并分析该方案在提升系统性能、可用性等方面取得的效果以及遇到的问题和解决措施。

三个方面对应六个段落，字数不要平摊

第 1 问写项目和你的角色，答辩人只想知道「你是不是真做过」。系统名、用户量、并发量、上线时间、你的岗位，五样凑齐就算过关。

第 2 问是纯知识，可以提前背。这类题的套路是先给原理，再给分类，最后给选型方法。负载均衡就按「四层与七层」「静态与动态」两刀切开，每一类说清特点和适用场景。

第 3 问是拉分的地方。要写方案的技术架构、算法选择、实施过程，还要给效果和问题。评卷人在这里看的是数字和你的技术判断。

常见失误是把 2500 字平均分给三个方面，第 3 问只剩 800 字，数字塞不进去。合理的比例是第 1 问 500 字左右，第 2 问 600 字左右，第 3 问 1400 字以上。

动笔顺序建议倒着来：先写第 3 问的方案段，再补第 2 问的知识，第 1 问的背景最后写，摘要留到最后收尾。

这一类的题，2016 年以来问过五轮

架构评估、架构风格、负载均衡、可靠性评价，这几类题在 2016、2017、2019、2023、2025 都出现过。题干换名词，三个方面不动。

十年题目清单在文末。对着清单挑两三类把素材备好，比每道题都写一遍省力。

论负载均衡设计技术（全文）

全文约 2400 字，考场按同样比例扩写到 2600 字以上即可。项目名称与数字均为示例。

摘要

本文以某三甲医院互联网医疗平台的负载均衡改造为背景，论述负载均衡技术的设计与实施。该平台覆盖 12 家分院，日均处理预约与查询请求 800 万次，挂号高峰段峰值并发 1.2 万。我担任项目技术负责人，负责负载均衡方案的设计、中间件选型与灰度上线。方案采用四层与七层结合的两级结构，入口以 LVS 承担四层转发，应用层以 Nginx 按业务路由，会话状态外置到 Redis 集群共享。改造上线后平均响应时间从 1.2 秒降到 320 毫秒，单节点故障切换控制在 3 秒以内，高峰期服务器平均利用率从 85% 降到 55%。

一、项目背景与我的工作

该平台 2022 年上线，面向本市 12 家分院的患者，提供预约挂号、报告查询、在线缴费和复诊续方四类服务。上线一年后注册用户涨到 180 万，日均请求从 60 万次涨到 800 万次。每天早上七点半到九点是挂号高峰，峰值并发 1.2 万。

原先的部署方式是两台应用服务器轮流接收全部流量，高峰段这两台机器的 CPU 长期在 90% 以上，偶发请求超时。业务部门给出的目标是把高峰段响应时间压到 500 毫秒以内，并且任意一台服务器宕机都不能影响挂号。我在项目中担任技术负责人，负责负载均衡方案的设计与选型，牵头完成灰度上线与故障演练。

二、负载均衡的基本原理与分类

负载均衡的基本原理是在请求入口处放一个调度器，按既定策略把请求分发给后端多个节点，同时通过健康检查把故障节点从候选集合里摘掉。它解决两件事：把单机承受不了的流量摊到多台上，以及任意一台出问题时不让全局不可用。

按所在的网络层次分，常见的是四层和七层。四层工作在传输层，只看 IP 和端口，转发在内核完成，吞吐高、延迟低，代价是不认识 HTTP 内容。七层工作在应用层，能按 URL、请求头和 Cookie 路由，可以做灰度与限流，代价是多一次解析，吞吐低于四层。

按调度策略分，静态和动态两类。静态策略不感知后端实时状态，包括轮询、加权轮询、IP 哈希和一致性哈希。轮询适合节点配置一致的场景；加权轮询适合新旧机器混部；IP 哈希让同一来源的请求固定落到一台，适合带本地缓存的服务；一致性哈希在节点增减时只影响少量请求，适合缓存类服务。

动态策略要看后端的实时指标，包括最小连接数、加权最小连接数、最小响应时间，以及按 CPU、队列长度计算权重的调度。动态策略对慢节点更敏感，代价是要采集并计算指标，调度器自身也有开销。

落到设计方法上，选型顺序是先定层次、再定策略、最后定健康检查与降级方案。请求量大又不需要按内容分流的入口走四层；需要按业务路由或做灰度时叠加七层。会话状态不要留在单机上，外置共享是后面策略能自由切换的前提。

三、平台的负载均衡方案设计

方案分两级。市中心机房部署两台 LVS，用 Keepalived 抢占同一个虚拟 IP，主备之间通过 VRRP 交换心跳。LVS 采用 DR 模式，请求进 LVS、响应由后端服务器直接回给客户端，绕开 LVS 的带宽瓶颈。

第二级是 Nginx 集群。LVS 把流量分到 8 台 Nginx 上，Nginx 再按 URL 前缀路由到三个业务集群：预约挂号走 appointment 集群，报告查询走 report 集群，在线缴费走 pay 集群。三个集群的机器配置不同，预约集群挂了 GPU 用于影像预处理，查询集群是普通机型，因此三个 upstream 配了不同的权重。

关键算法按业务分别选。查询服务无状态，用加权最小连接数，让慢节点自然少接请求。预约挂号要求同一患者的多次请求串行，否则会出现超订，所以按患者 ID 做一致性哈希，同一患者固定落到同一台，服务内再用乐观锁兜底。在线缴费涉及第三方回调，不能重复处理，用 IP 哈希配合幂等表。

会话状态的处理是这次改造的关键。原来用的是会话粘性，患者登录后粘在一台机器上，那台机器一挂就要重新登录。改造后把会话写入 Redis 集群，应用服务器不再保存本地会话，扩容和摘除节点都不用考虑会话迁移。

健康检查分两层。Nginx 每 3 秒请求一次后端节点的健康接口，连续 3 次失败才摘除。节点恢复后先按 10% 权重放流量，30 秒内逐步加到满权重。这个慢启动是为了避免刚重启的节点被瞬时流量打垮。

四、实施过程与遇到的问题

上线分三步：先切报告查询，观察三天；再切预约挂号；最后切在线缴费。每一步都可以在 30 秒内把虚拟 IP 切回旧入口，留有退路。

第一个问题是 Redis 成了新的单点。会话外置后 Redis 一挂，全部患者都要重新登录。解决办法是上 Redis Cluster 三主三从，应用侧加一层本地缓存保存会话的只读副本，Redis 抖动时不至于立刻掉线。

第二个问题是 DR 模式的回包路径。后端服务器的网关指向了机房出口而不是 LVS 所在网段，导致部分网段的回包被防火墙拦掉。调整内核参数并把网关改回 LVS 所在网段后恢复正常。

第三个问题是健康检查抖动。上线第二天上午，一台 Nginx 因为一次 Full GC 让健康接口超时，节点被摘除，流量瞬间压到剩余节点上。改为连续三次失败才摘除，并把慢启动的起始权重从满权重降到 10%。

第四个问题是权重与实际能力不匹配。GPU 机器和普通机器按一比一配权重，但 GPU 机器同时要吃影像预处理，实际吞吐只有普通机器的七成。后来改为按队列长度动态调权，权重每分钟重算一次。

五、效果与总结

改造后平均响应时间从 1.2 秒降到 320 毫秒，挂号高峰段的超时率从 0.8% 降到 0.05%。做了一次故障演练，直接关掉一台 Nginx，患者无感知，流量在 3 秒内完成转移。服务器平均利用率从 85% 降到 55%，腾出来的余量够支撑半年的用户增长。

还有一处没解决：跨机房的流量切换仍然依赖 DNS，切换生效时间在分钟级。下一步打算做全局负载均衡，按机房健康状态和就近原则分配流量，把跨机房切换也压到秒级。

自拟：论高可用系统的可用性设计及其应用

下面这道是自拟的预测题，不挂出处。三个方面沿用同一模板，知识段换成可用性的战术。写法和上一篇完全一样，可以当作第二次练习。

请围绕「论高可用系统的可用性设计及其应用」话题依次从以下三个方面论述：1. 概要叙述你参与设计和实施的项目的背景、可用性目标，以及你在可用性方案设计中承担的主要工作；2. 简要说明可用性的含义与常见度量指标，并阐述提高系统可用性的主要战术分类及其适用场景；3. 围绕你在项目中设计和实现的可用性方案，详细说明方案的技术架构、关键战术选择与实施过程，并分析取得的效果以及遇到的问题和解决措施。

注意这道题和第 1 问的差别：它要的是「可用性目标」，所以背景段里必须出现停机时间或者可用性百分比这类数字，光写用户量不算回应题目。

论高可用系统的可用性设计及其应用（全文）

全文约 1700 字，同一套骨架换第 2 问的知识，考场按比例扩写。项目名称与数字均为示例。

摘要

本文以某省级医院手术审批与排班平台的可用性改造为背景，论述高可用系统的设计方法。平台覆盖 12 家分院的手术科室，日均审批单据 4 万份，麻醉评估与手术排班必须在术前 24 小时内完成。我担任平台技术负责人。方案采用同城双活加异地灾备，核心链路做服务隔离、限流降级与幂等重试，数据库用主从加半同步复制。改造后系统年可用性从 99.5% 提升到 99.95%，年度非计划停机时间从 43 小时降到 4.4 小时。

一、项目背景与可用性目标

该平台 2021 年上线，支撑 12 家分院的手术申请、麻醉评估、手术排班和术后随访。日均审批单据 4 万份，手术台次每天 260 台。业务上有一条硬约束：麻醉评估必须在术前 24 小时内完成，排班表在术前一天下午锁定。

改造前的可用性是 99.5%，折算下来一年有 43 小时不可用。这些停机里，一半来自数据库维护窗口，一半来自应用服务器重启。医务处给出的目标是年不可用时间压到 5 小时以内，同时任何单机故障不能让审批链路中断。我在项目中担任技术负责人，负责可用性方案的整体设计与演练组织。

二、可用性的度量与主要战术

可用性指系统在一段时间内正常提供服务的能力，常用的度量指标是可用性百分比和不可用时间。99.9% 对应一年约 8.8 小时不可用，99.99% 对应约 52 分钟。与可用性配套的两个指标是恢复时间目标与恢复点目标，前者决定多久必须恢复，后者决定允许丢多少数据。

提高可用性的战术分三类：错误检测、错误恢复和错误预防。错误检测包括心跳、ping 与 echo、异常上报和监控告警，目的是尽快知道出事了。错误恢复包括主动冗余、被动冗余、备用件和检查点回滚，目的是出事之后接得住。错误预防包括移除单点、引入中间件隔离、限制资源使用和幂等设计，目的是让故障不容易发生或者影响可控。

选型要看代价。主动冗余切换快，但要付双份资源；被动冗余省资源，但启动需要时间。对可用性要求高又要求切换快的链路用主动冗余，非核心链路用被动冗余加快速重启就够了。

三 平台的高可用方案设计

整体结构是同城双活。两个机房各有一套完整应用集群，通过全局负载均衡按机房健康状态分配流量，主用机房正常情况下承担七成流量。两个机房之间用专线做数据同步，数据库主库在主机房、从库在备机房，采用半同步复制。

审批链路做了服务隔离。手术申请、麻醉评估、排班锁定三个服务各自独立部署，配有独立的线程池与连接池，避免一个服务慢把整条链路拖住。核心的排班锁定服务额外做了限流，超过每秒 200 个请求就排队并返回排队序号。

降级方案按业务分级。排班锁定和麻醉评估不能降级，必须走到成功或者明确失败；术后随访、统计报表可以降级，超时就直接返回缓存数据。降级的开关放在配置中心，出问题时由值班人员手动触发。

关键写操作全部做成幂等。手术申请提交、排班锁定、麻醉评估提交各带一个业务流水号，服务端维护幂等表，重复请求直接返回上次结果。这一条配合自动重试，把网络抖动引发的问题挡在了用户看不到的地方。

监控和演练是方案的最后一环。心跳由应用每 5 秒上报一次，连续三次收不到就触发告警；每周做一次单节点宕机演练，每季度做一次机房切换演练。

四、实施过程与遇到的问题

第一个问题是双活的写冲突。两个机房同时可写时，排班数据出现过两次重复锁定。解决办法是排班锁定服务只允许主机房写，备机房写请求转成只读并排队，故障切换时再整体提升为主。

第二个问题是半同步复制在主库抖动时退化成异步，出现了几秒的数据差。后来给从库加了延迟监控，延迟超过 1 秒就告警，并在切换脚本里加了数据一致性校验。

第三个问题是限流阈值定得偏大。上线第一周的大促体检日，排班锁定的队列积压到 800，患者端等待超过 20 秒。把阈值降到每秒 150 并加了排队序号提示后恢复正常。

五、效果与总结

改造后年可用性从 99.5% 提升到 99.95%，非计划停机从 43 小时降到 4.4 小时。机房切换演练的实测恢复时间是 47 秒，满足业务设定的 2 分钟目标。审批链路的日均失败请求从 1200 次降到 80 次以内。

遗留问题是异地灾备还停留在数据级，备机房的资源只够跑核心链路。下一步打算把灾备做成应用级，让备机房在主机房整体不可用时也能承载全部审批业务。

2016 到 2025，四十道题按年排开

每年四道题，十一年四十四道。看一遍就能发现高频主题圈：架构风格与评估、微服务与云原生、数据架构、可靠性、安全、测试与维护。

备素材时挑两三类主题各备一套项目背景与量化指标，考场上四道题里总能撞上一道。

本期复盘

论文这条线接着往下走，下一讲论文换成数据这一类题：从数据分片到多源数据集成，照样是真题原文、整篇范文、模拟预测题和第二篇范文。