Day40-02｜20.3.2 如何写好正文：把架构决策讲清楚、落下去、验出来

对应教材：第20章《系统架构设计师论文写作要点》20.3.2 如何写好正文

一、正文要回答“为什么这样设计”

正文是论文的主要得分区域。它不是摘要的简单扩写，也不是教材知识点的拼接，而是围绕项目约束展开架构决策。每个重点段落都建议按“问题—目标—方案—机制—验证—权衡”组织。

现状问题 → 质量目标 → 架构决策 → 运行机制 → 验证结果 → 代价改进

这条链能够让阅卷者看到设计不是凭空产生的。比如在高并发场景下使用缓存，必须先说明访问热点和数据库瓶颈，再说明缓存分层、失效和一致性机制，最后给出压测指标以及短暂不一致的处理办法。

二、第一段写清背景和边界

正文开头需要交代系统服务对象、核心业务、规模、原有问题和建设目标。规模至少选择三项，不要一次罗列十个没有用的数字。项目边界也很重要：说明本文重点讨论哪个子系统，哪些外部系统是依赖，哪些能力不在范围内。

例如：“本文以订单与库存子系统为对象，支付由外部平台提供，重点讨论峰值流量、库存一致性和故障恢复。”这样可以避免后文无限扩展，也说明你具备边界意识。

三、第二段写总体架构

总体架构可以采用分层、分域和部署三个视角。分层说明接入、业务、数据和基础设施的职责；分域说明用户、订单、库存、营销等业务边界；部署说明节点、网络区域、数据库、缓存、消息和监控的关系。

用户/终端
      ↓
接入层：网关、鉴权、限流、路由
      ↓
业务层：用户｜商品｜订单｜库存｜营销
      ↓                 ↓
数据层：关系库、缓存、搜索、对象存储
      ↓
平台层：消息、配置、注册、日志、指标、追踪

架构图之后必须用文字解释关键边界和数据流，不能只画图不说明。正文不需要把每个组件都写成产品名，重点是职责、依赖和故障影响范围。

四、第三段写关键决策一：边界与拆分

服务或模块拆分应根据业务能力、数据归属、变化原因、团队职责和故障隔离需求。按数据库表拆分容易造成业务耦合；按组织架构照搬也可能形成跨服务长调用链。拆分后要说明服务之间如何通信、如何发布、如何处理数据一致性。

高级表达应包含取舍：“将订单、库存和营销拆分为独立服务，减少不同变化节奏之间的影响；订单与库存通过事件和幂等接口协作，但跨服务事务不再由单一数据库事务保证，因此增加本地消息表、重试、补偿和对账。”

五、第四段写关键决策二：性能或可用性机制

性能段落要写负载特征、瓶颈位置、优化机制和验证结果。可用性段落要写故障模型、冗余方式、检测与切换、降级和恢复。安全段落要写资产、威胁、控制和审计。数据段落要写数据生命周期、读写特征、一致性、扩展和备份。

不要把所有属性平均写一遍。题目要求什么，就把什么写深；其他属性用来说明方案的边界和副作用。

六、第五段写治理与落地

架构方案能否实施，取决于治理。可以写架构评审、接口契约、代码规范、配置管理、自动化测试、灰度发布、监控告警、容量管理和应急预案。治理内容不是运维附录，而是保证架构决策持续有效的机制。

例如微服务系统中，若没有接口版本管理和依赖治理，服务拆分会迅速形成调用混乱；若没有链路追踪和统一日志，故障定位时间会明显增加；若没有契约测试和灰度发布，独立交付反而提高上线风险。

七、结果段要连接方案

结果不是“领导满意、用户好评”，而是方案造成的可观察变化。至少写两组前后对比，并说明测量方法或场景。比如“在相同压测数据和并发模型下，P99由1200毫秒降至420毫秒；在模拟应用节点宕机和数据库主备切换的演练中，核心业务恢复时间分别为30秒和6分钟。”

也要写没有解决的问题。架构升级通常会增加成本、学习曲线、治理负担或一致性复杂度。承认这些问题并给出改进方向，能够体现工程判断。

八、正文中的术语控制

技术术语应服务于解释。第一次出现时说明职责或作用，例如“服务注册中心负责保存实例地址和健康状态，调用方通过动态发现避免硬编码地址”。不要连续写产品名，也不要把“分布式、云原生、智能化、平台化”当作方案本身。

可以用“概念—机制—边界”三句法：概念是什么；在本项目中如何落地；什么情况下不适用。这样的表达比单句定义更接近架构设计。

九、案例：正文段落的改写

低质量表达：“为了提高系统性能，我们使用了缓存和消息队列，系统性能得到了很大提升。”

改写为：“平台的商品详情查询占总流量约70%，高峰期数据库读连接接近上限。我们在接入层和应用层之间增加热点缓存，并按商品版本设置失效标记；价格和库存采用短TTL与关键操作回源确认，普通描述允许短暂延迟。对于报表生成和通知发送等非核心任务，使用消息队列异步解耦，消费者按积压量弹性扩展。压测结果显示数据库读QPS下降65%，查询P99由780毫秒降至210毫秒；代价是缓存失效和消息重复带来一致性风险，因此增加幂等键、死信队列和对账任务。”

十、今日练习

以“论微服务治理”为题，写一个包含六个要素的正文段落。
将“系统使用主从复制提高可靠性”扩写成问题、机制、验证、代价四句。
画出一个包含接入、业务、数据、平台和监控的文字架构图。

参考要点：必须说明原问题、设计目标、技术机制、指标验证和副作用；图示至少体现主要数据流和监控覆盖。正文的质量取决于因果关系，而不是段落数量。

十一、段落的内部结构训练

每个关键段可以先写一句主题句，再写三到五句解释。主题句说明本段决策，例如“为隔离营销活动对订单核心链路的影响，系统采用资源池和消息队列进行削峰”。后续说明原问题、具体机制、验证方法和代价。主题句能够帮助阅卷者快速定位观点，解释句负责证明观点。

正文中的案例细节应服务于主题。写数据库时讲索引、事务、复制和备份；写安全时讲信任边界、身份、授权、加密和审计；写云原生时讲容器、编排、发布、弹性和观测。与主题无关的业务功能应压缩，避免正文变成项目说明书。

十二、不同层次的架构表达

逻辑架构回答模块和职责，开发架构回答代码组织和接口，运行架构回答进程、节点和通信，部署架构回答网络区域、实例和故障域，数据架构回答数据归属、存储和流转。论文不必把每个视图都画全，但至少要让文字说明覆盖与题目相关的视图。例如高可用题必须写运行和部署视图，数据题必须写数据视图，安全题必须写信任边界。

十三、正文改写练习

将“我们通过服务化提高了系统可维护性”改写为：原单体系统中订单和营销代码频繁互相修改，发布必须整体停机；项目按业务能力和变化原因拆分订单、营销和通知服务，统一接口契约和版本规则，并建立自动化测试与灰度发布；上线后独立发布比例提高，回滚时间下降，但服务调用和观测成本增加，后续通过依赖拓扑和平台模板治理。

十四、正文的证据链

正文中每一个结论都应尽量有证据。写“可扩展性提高”，证据可以是实例数量从2扩展到10时吞吐近似线性增长；写“可维护性提高”，证据可以是模块独立发布、接口契约测试通过率和故障定位时间下降；写“安全性提高”，证据可以是高风险操作全部进入审计、越权测试未通过、密钥轮换能够按期完成。证据不一定都是数字，也可以是演练结果、评审记录、故障工单和对比实验。

正文还要区分设计目标和实际结果。目标是设计阶段的要求，结果是上线后或测试中的观察；如果结果没有达到目标，应说明原因、影响和改进，而不要直接把目标写成结果。这样写更真实，也体现架构师的风险意识。

十五、考场快速展开法

当时间紧张时，每个关键方案至少写五句：第一句指出问题，第二句给出决策，第三句解释组件和数据流，第四句写验证指标，第五句写代价或风险。例如数据库高可用段落就写单点问题、主备/集群决策、复制和切换机制、RTO/RPO演练、复制延迟和脑裂风险。五句法可以保证正文不空洞。