故事单元 1：项目启动的架构抉择（对应考点：架构风格选型、需求分析、架构设计原则）

一、故事背景

“小张，这次的市域地下水动态监测云平台项目，公司把架构设计的担子交给你了！” 技术总监老王拍了拍架构师小张的肩膀，语气里满是信任。

小张所在的科创公司，此前一直用单体架构开发小型水文监测系统，可这次的新项目需求堪称 “重量级”：要接入全市 120 个监测站点的实时数据（包括水位、水质、沉降量等 6 类指标），支撑水务局、科研院所等 5 类用户的不同查询需求，还要预留未来 3 年的数据扩容和 AI 预警模块的接入空间，同时必须保证系统 7×24 小时不宕机 —— 毕竟地下水数据关系到城市防洪和地质安全，容不得半点差错。

拿到需求文档的当晚，小张对着屏幕犯了难：沿用熟悉的单体架构，开发速度快但肯定扛不住高并发和后期扩展；换成微服务架构，技术难度高、团队磨合成本大，可长远来看更适配项目需求。

二、知识点融入与剧情推进

1. 需求分析的核心逻辑（对应综合知识考点：架构需求分类）

   小张先按 “功能性需求” 和 “非功能性需求” 拆解了项目目标：

   • 功能性需求：数据采集、多维度查询、权限分级管理、数据可视化、预警阈值配置；

   • 非功能性需求：高可用性（全年宕机时间≤8 小时）、高并发（支持峰值 500 用户同时查询）、可扩展性（预留 AI 接口）、数据一致性（监测数据上传与展示无延迟偏差）。

     他突然想起教材里的知识点：架构设计的第一步是 “需求优先级排序”，非功能性需求中的高可用和数据一致性，是水文监测系统的核心底线，必须优先保障。

2. 架构风格的选型博弈（对应案例分析高频考点：架构选型对比）

   小张拉上团队开了架构评审会，会上出现了两种声音：

   • 老程序员老李主张用单体架构：“咱们团队熟这个技术栈，3 个月就能完成开发，先把项目拿下来再说！” 小张却反驳：“单体架构的痛点很明显 —— 所有模块耦合在一起，后期要加 AI 预警模块，就得整体重构；而且 120 个站点的实时数据并发写入，单体服务很容易出现性能瓶颈，一旦宕机，整个系统都瘫痪，这不符合水文监测的高可用要求。”

   • 技术骨干小陈提议用微服务架构：“把系统拆成数据采集服务、数据存储服务、用户权限服务、可视化服务、预警服务等独立模块，每个模块可单独扩容，就算某一个服务故障，也不会影响整体运行。” 小张补充道：“没错，微服务还能适配多团队协作 —— 采集模块交给物联网组，可视化交给前端组，我们架构组专注核心的分布式存储和服务治理，效率更高。”

     最后他还结合教材知识点总结：“单体架构适合小型、需求稳定的系统；微服务架构适合复杂、高并发、需持续迭代的大型系统，这个项目的体量和远期规划，微服务是最优解。”

3. 架构设计原则的落地（对应论文考点：架构设计的核心准则）

   确定微服务方向后，小张开始搭建基础架构框架，同时严格遵循 3 个核心原则：

   • 模块化与松耦合：每个微服务只负责单一功能（比如数据采集服务仅对接监测站点、解析传输协议），服务间通过 RESTful API 通信，避免模块间的强依赖；
   • 高内聚：把数据存储的相关逻辑（时序数据库选型、数据分片策略、备份机制）都整合在数据存储服务内，便于统一维护；
   • 关注点分离：将非业务功能（如日志收集、权限校验）抽离成独立的中间件，让业务服务只聚焦核心逻辑。

三、故事收尾与知识复盘

一周后，小张的微服务架构方案通过了评审，老王拍着他的方案说：“你这方案不仅贴合项目需求，还把架构设计的底层逻辑讲得明明白白！”

小张松了口气的同时，也暗自庆幸：把教材里的架构选型和设计原则融入到项目场景里，不仅没觉得枯燥，反而记得更牢了 —— 这比死记硬背知识点管用多了。

本单元核心考点复盘

1. 架构需求分为功能性需求和非功能性需求，非功能性需求中的高可用、可扩展性是大型系统架构设计的核心约束；
2. 单体架构与微服务架构的适用场景对比（单体：小型、需求稳定；微服务：大型、高并发、迭代频繁）；
3. 微服务架构设计需遵循松耦合、高内聚、关注点分离等核心原则。