CodeRoadMap
首页路线题库资源库文章社区
CodeRoadMap

程序员的学习成长路线图。内容免费开放,登录后可同步路线图与课时进度。

由 程序员柏风 独立维护 · 关于作者

学习

  • 路线图
  • 课程
  • 面试题
  • 文章
  • 我

更多

  • 资源
  • 社区
  • 关于作者
  • 内容说明

© 2026 CodeRoadMap

津ICP备2026012044号-1·津公网安备12011002026155号·coderoadmap@126.com
软件架构师入门/课时/软件架构是什么
RawBlame
课时目录12 节

软件架构师入门

  1. 01软件架构是什么
  2. 02架构师软技能
  3. 03设计模式与原则
  4. 04架构风格
  5. 05数据架构
  6. 06API 与集成
  7. 07安全架构
  8. 08云与设计模式
  9. 09网络基础
  10. 10技术栈选型
  11. 11治理与方法论
  12. 12综合练习

软件架构是什么

职责、层级与 ADR 文档。

30 分钟

软件架构是什么

这一课你将能做到

  1. 用一句话向非技术人员解释「软件架构」,并说出架构师与高级开发的本质区别
  2. 画出本站从单体 Spring Boot 演进到微服务的架构分层图,标出每一层的职责
  3. 写出一份符合规范的 ADR(架构决策记录),能直接放进项目仓库

为什么要学

写代码解决的是「这个功能怎么实现」,架构解决的是「这个功能放在哪、和谁通信、挂了怎么办」。功能写错了改一个类就行,架构错了要推翻重写整个系统。

人话:架构就像城市规划。开发是盖楼,架构师决定哪里是住宅区、哪里是商业区、路怎么修、水电怎么走。楼盖歪了可以拆,城市规划错了全城堵车十年。

面试场景:面试官问你「你们系统架构是怎样的」,如果你只会说「Spring Boot + MySQL」,那是技术栈罗列,不是架构。能讲清楚「为什么这样分层、瓶颈在哪、下一步怎么演进」,才是架构思维。

先建立图像

本站(CodeRoadMap)架构演进的三个阶段:

【阶段一:单体】(起步期,1 个开发者)
┌─────────────────────────────────┐
│      Spring Boot 单体应用         │
│  ┌──────┐ ┌──────┐ ┌──────┐    │
│  │用户模块│ │课程模块│ │支付模块│  │
│  └──┬───┘ └──┬───┘ └──┬───┘    │
│     └────────┴────────┘         │
│           共享 Service/DAO       │
└──────────────┬──────────────────┘
               │ JDBC
        ┌──────┴──────┐
        │    MySQL     │
        └─────────────┘

【阶段二:单体 + 缓存】(日活 1 万)
浏览器 → Nginx → Spring Boot ──→ Redis(热点课程缓存)
                      │
                   MySQL(主)→ MySQL(从,读写分离)

【阶段三:微服务】(日活 10 万+,团队 20 人)
            ┌──→ 用户服务 ──→ MySQL(用户库)
Nginx → API Gateway ──→ 课程服务 ──→ MySQL(课程库)+ Redis
            │              │
            └──→ 订单服务 ──┴──→ RocketMQ(下单事件)──→ 推荐服务

跟着做

步骤 1:识别架构的四个层次

任何系统都可以拆成四层来看,用本站举例:

层次问题本站的答案
应用架构代码怎么组织?单体按包划分:controller/service/dao/domain
系统架构进程怎么部署?阶段一:1 个 JVM 进程 + 1 个 MySQL
数据架构数据存哪、怎么流?MySQL 主库,课程表按 track_id 分索引
基础设施跑在哪?阶段一:1 台云服务器;阶段三:K8s 集群

步骤 2:做一次架构推演

假设需求:「给本站加课程搜索功能」。架构师的思考路径:

  1. 数据量级?课程表 5000 行 → MySQL LIKE 够用;50 万行 → 必须上 Elasticsearch
  2. QPS 多少?日活 1 万 → 峰值约 50 QPS,MySQL 扛得住
  3. 一致性要求?课程更新后 5 分钟内可被搜到即可 → 允许近实时
  4. 结论:当前用 MySQL 全文索引,预留 ES 演进路径,写入侧用 Canal 监听 binlog 同步

步骤 3:写一份 ADR

架构决策记录(Architecture Decision Record)是架构师的核心产出物:

# ADR-003: 课程搜索使用 MySQL 全文索引而非 Elasticsearch

## 状态
已接受(2024-06-01)

## 背景
课程总量 5000,日搜索请求约 2 万次,团队无 ES 运维经验。

## 决策
使用 MySQL 8 的 ngram 全文索引,搜索接口走从库。
当课程数超过 5 万或搜索延迟 P99 超过 500ms 时,重新评估迁移 ES。

## 后果
+ 零新增基础设施,运维成本不变
+ 数据与业务库强一致,无同步延迟
- 中文分词精度低于 ES 的 ik 分词器
- 复杂排序(相关性打分)能力受限

讲清楚要点

  1. 架构 = 结构 + 决策 + 权衡:结构是「有什么组件、怎么连」,决策是「为什么这么选」,权衡是「放弃了什么」。三者缺一都不算架构。
  2. 没有最好的架构,只有最合适的架构:本站阶段三对日活 1 万的系统是灾难——分布式事务、服务治理的复杂度会拖死小团队。
  3. 架构师 vs Tech Lead:Tech Lead 对「这个 Sprint 交付什么」负责,架构师对「这个系统三年后还能不能演进」负责。小公司常一人兼任,但职责要分清。
  4. Solution Architecture vs Enterprise Architecture:前者管单个系统(本站的课程服务),后者管整个企业的系统版图(CRM、ERP、数据平台如何协同)。本 track 聚焦前者。
  5. 架构是演进的,不是设计的:没人一开始就设计出淘宝架构。正确姿势是「满足当前需求 + 留好演进接口 + 定期偿还技术债」。

你可能会懵的地方

  • 架构设计不就是画框图吗? 框图只是结果的呈现。架构的核心工作在框图之前:识别约束(预算、团队、时间)、列出备选方案、评估权衡。一张没有决策依据的框图没有价值。

  • 小项目需要架构吗? 需要,但程度不同。5000 行代码的项目,架构可能就是「分层 + 一份 README 说明」;50 万行的系统需要正式的架构文档。架构投入的多少本身就是架构决策。

  • 架构师还需要写代码吗? 需要。不写代码的架构师会逐渐失去对实现成本的判断力,做出「PPT 架构」。业界共识是架构师至少保留 30% 的编码时间。

  • 学了架构能马上用吗? 能。哪怕你只是普通开发,用架构思维写代码:模块边界清晰、依赖方向正确、变更影响可控——这就是架构能力在日常的体现。

  • 微服务是不是比单体高级? 不是。微服务是用「分布式复杂度」换「团队并行度和独立部署能力」。团队小于 10 人、日活低于 10 万,单体 + 模块化通常是更优解。

错法对照

错法问题正解
上来就拆微服务分布式事务、运维复杂度压垮小团队单体模块化先行,边界清晰后再拆
用消息队列解耦一切链路不可追踪,排查问题要翻 5 个系统只对「异步、削峰、最终一致」场景用 MQ
技术选型追新(Service Mesh 全套)学习成本高,社区不成熟踩坑无人救选团队能 Hold 住的最简单方案
架构文档写完不更新三个月后文档与现实脱节,误导新人ADR 随代码提交,架构图每个季度复审
为「以后可能的需求」过度设计80% 的预留设计永远不会被用到YAGNI:当前需求 + 留扩展点即可

卡点急救

  1. 拿到需求不知道从何下手:先问四个问题——数据量多大?并发多少?一致性要求多强?预算和 deadline?这四个答案基本锁定架构大方向。
  2. 评审时被人挑战方案,说不出依据:回到 ADR 的格式,把「背景-决策-后果」写清楚,用数据说话(QPS、延迟、成本),而不是「我觉得」。
  3. 老系统没人敢动,新需求越来越多:这是典型的技术债信号。做法:新功能用新架构(绞杀者模式),老功能按调用频率排序逐步迁移,不要大爆炸重写。

面试常问

  • 单体和微服务怎么选? 答题框架:团队规模(<10 人倾向单体)、业务复杂度(领域边界是否清晰)、部署频率要求(是否需独立发布)、运维能力(有无 K8s 和监控体系)。举例:本站日活 1 万时单体 + 读写分离是合理选择;日活 10 万、团队 20 人后按域拆出课程、订单、推荐服务。记住金句:「微服务解决的是组织问题,其次才是技术问题」。

  • 什么是架构决策记录 ADR? 一份轻量文档,记录某个架构决策的背景、选项、决策和后果,随代码版本管理。价值:新人能快速理解「为什么是这样」,避免后人推翻决策时不知道当初的约束。结构:标题、状态、背景、决策、后果五部分。

  • 如何评估一个架构好不好? 看四个非功能属性:可维护性(改一个需求动几个模块)、可扩展性(加 10 倍流量加什么)、可用性(挂一个组件影响多大)、成本(机器 + 人力)。好的架构是在当前约束下这四个属性的最优平衡点。

自测三问

  1. 用一句话说明架构师和高级开发的职责差异?
  2. 本站在日活 1 万时为什么不该拆微服务?至少说出两个理由。
  3. 一份合格的 ADR 必须包含哪五个部分?

小结一句话

架构是在约束条件下对系统结构和演进方向做权衡的艺术,核心产出是可追溯的决策,而不是漂亮的框图。

延伸

  • 《架构整洁之道》(Clean Architecture, Robert C. Martin)——依赖规则必读
  • 《软件架构:架构模式、特征及实践指南》(Fundamentals of Software Architecture)
  • roadmap.sh/software-architect
  • 下一课:架构师软技能——技术之外,沟通、估算与决策推进才决定方案能否落地。
加载本节练习…
下一课 →架构师软技能