CycleUser

很多刚入行的同学一听"架构"俩字，脑子里立马浮现出一个格子衬衫牛仔裤、抱着笔记本在白板前画框图的中年人，嘴里蹦着一堆"高内聚低耦合""微服务""中台""云原生"之类的词，看着就很高深。

可你真去问他："架构到底是啥？"十有八九他也得愣一下，然后给你来一段听着很玄乎但细品啥也没说的回答。

这事儿其实不怪他，因为"架构"这词本身就有点滑头，它既是动词也是名词，既是结果也是过程，既关乎技术也关乎人。

我自己考过软考高级系统架构设计师，也写过不少乱七八糟的系统，备考的时候把五大架构风格、质量属性、架构评估这些东西翻来覆去啃了好几遍，就试着用朴素语言把这个事儿讲讲清楚，顺便把教材里的正经说法也捎带上，免得大家看了图一乐却过不了考试。

一、架构到底是个啥

先说朴素语言：架构就是结构，就是怎么把一堆东西组织起来的方案。

你盖房子，得想好哪是客厅哪是卧室，哪面墙承重，水管电线怎么走——这套安排就是房子的架构。 你开个饭馆，得想好前厅几桌、后厨几人、收银台摆哪、进货走哪个门——这套安排就是饭馆的架构。 你写个程序，得想好哪块管界面、哪块管数据、哪块管业务逻辑、它们之间怎么通信——这套安排就是软件的架构。

再说教材口径。软考官方给的定义是：软件架构是对软件系统提供的结构、行为、属性的高级抽象，是特定应用领域的惯用模式，定义了词汇表和约束。

有个冷知识：业界叫"软件架构"，学术界叫"软件体系结构"，俩名说的是一回事。它存在于需求分析和软件设计之间，是把两者衔接起来的桥梁。

更本质地说，架构设计是需求分配——把满足需求的职责，分配到系统的各个组件上。也就是说，需求告诉你"要干啥"，架构告诉你"谁来干、怎么搭伙干"。

不管哪种说法，核心都落在两个问题上：

1. 这玩意儿拆成几块？（构件）
2. 这几块之间怎么连？（连接件）

在架构描述语言（ADL）里，这俩叫 ADL 的三要素：构件（干活的）、连接件（连接规则）、架构配置（连接图）。记住这仨词，案例题经常考。

架构的作用，教材给了四条，翻译成人话就是：

• 让项目里各种人（产品、开发、测试、运维、老板）有个共同语言能聊到一块去；
• 它是个能复用、能传递的模型，还能预测软件质量——架构定得好不好，基本就能看出这系统将来稳不稳、快不快；
• 支持循序渐进地搭原型；
• 是降成本、提质量、按时按需交付的关键。

二、架构师又是干啥的

知道了架构是啥，架构师就好理解了——就是那个定架构的人。

软考给这个角色的定位是：IT 行业中负责系统整体技术蓝图的核心角色。跟普通软件工程师专注模块实现不一样，架构师得站在全局视角，在需求分析和软件设计之间架桥，做"需求分配"。

但这里有个常见的误解，很多人以为架构师就是"技术最牛的那个人"。技术牛是基础，你得知道各种方案长啥样、各有啥优缺点，不然连选项都列不出来。但光技术牛远远不够，架构师真正干的活是这几件：

1. 搞清楚要盖什么样的房子（架构需求）

也就是需求分析。用户说要一个"能跑的系统"，你得问出来：多少人同时跑？跑多快？断了能不能自己恢复？将来要不要加新功能？这些没搞明白，架构就是空中楼阁。

教材里把需求分成两类：功能需求用用例来捕获，质量需求用质量场景来捕获。质量场景有六个要素：刺激源、刺激、环境、制品、响应、响应度量。听着玄乎，其实就是"谁、在啥情况下、对系统的啥东西、做了啥操作、系统应该咋反应、反应得好不好怎么量"。比如"1000 个用户（刺激源）在促销期间（环境）对下单接口（制品）发起请求（刺激），系统应在 1 秒内（响应度量）返回结果（响应）"——这就是一个性能质量场景。

2. 在一堆互相打架的目标之间做取舍（质量属性权衡）

这是架构师最核心的活儿。你想让系统又快又稳又便宜还特别好扩展——对不起，这种好事不存在。

教材里列了六大质量属性：性能、可靠性、可用性、安全性、可修改性、功能性，再加可变性、互操作性。这些属性之间经常互相打架：

• 要快（性能），可能就得把数据冗余存好几份，那就费钱费空间，还可能引入一致性问题（可修改性下降）。
• 要稳（可用性），就得加各种备份和容灾，那就复杂、慢、贵。
• 要好扩展（可修改性），就得拆成微服务，那运维成本蹭蹭往上涨，性能还可能因为网络调用变差。

这就是架构评估里常说的几个词，考试必考：

• 敏感点：影响某一个质量属性的拐点。比如缓存大小直接影响性能。
• 权衡点：影响多个质量属性的特征。比如"是否使用加密"既影响安全性又影响性能——这就是个权衡点。
• 风险点：架构决策里埋的雷，将来可能出事。
• 非风险点：已经验证过、不会出问题的决策。

架构师的功夫就体现在：知道哪个该舍、哪个该取，而且能讲清楚为什么。一个只会说"我们要做到全部都要"的人，不是架构师，是许愿池。

3. 把决策落到图和文档上（架构文档化）

架构师不能光在脑子里想，得画出来、写下来。不是给领导看的那种花里胡哨的 PPT，而是真要让开发团队能照着干的技术文档。

教材里强调，架构成功的关键因素是文档的完整性和质量。而且文档要从使用者角度写，要分发给所有开发人员，手上的必须是最新版——不然就是废纸。

描述架构常用的是 4+1 视图：逻辑视图（给最终用户看，讲功能和需求）、开发视图（给程序员看，讲代码怎么组织）、进程视图（给集成人员看，讲并发和性能）、物理视图（给系统工程师看，讲部署拓扑）、用例视图（给分析和测试人员看，讲核心场景）。口诀是：分析人员测试人员看用例，最终用户看逻辑，程序员看实现，集成人员看进程，系统工程师看部署。

4. 拍板并为之负责（架构复审与演化）

团队里讨论起来没完的时候，得有人站出来说"就按这个来"。出了问题，也得有人站出来说"这是我的锅，咱们这么改"。这就是架构师。

教材里专门有个 ABSD（基于架构的软件设计）方法，把架构师的活儿拆成六步：架构需求 → 架构设计 → 架构文档化 → 架构复审 → 架构实现 → 架构演化。这是个自顶向下、递归细化的循环，不是一次性的事儿。其中架构复审是为了发现风险和缺陷，检查需求满不满足、质量体没体现、层次清不清楚、文档明不明确；架构演化是需求变了之后，把构件归类、定计划、改构件、重新组装测试——架构是会跟着系统一起长的。

所以架构师与其说是技术岗位，不如说是一个需要技术底子的决策岗位。考软考那会儿我对这点的体会特别深，论文题考的压根不是你会多少种框架，而是你能不能在一个具体项目里，把"为什么这么选、这么选有什么好处、遇到问题怎么办"讲明白。

三、常见的几种架构

软考教材把架构风格分成五大类，这是考试重点中的重点，能占 15 到 20 分。我先把教材的分类体系摆出来，再用朴素语言挨个讲。

五大架构风格：

除了这五大类，还有几种新架构（微服务、云原生、湖仓一体等）也常考，后面一起讲。

1. 单体架构：一锅炖

最朴素的架构，所有功能都塞在一个程序里，打成一个包，部署在一台机器上。严格说它不算教材五大风格里的某一种，更像是"还没怎么分"的原始状态。

例子：你开个小卖部，零食饮料日用品全摆在一间屋里，你一个人既收银又上货又理货。简单、省事、起步快。

好处：开发简单，调试方便，部署就一个包，测试也容易。 坏处：一旦生意大了，屋子塞不下，你想单扩一个货架都做不到——因为整个屋子是一体的，要么全扩要么不扩。代码也会越堆越臃肿，改一个地方怕牵连别的。

这就是早期大多数系统的样子，现在很多小项目、内部工具也还是这样，没什么丢人的。合适的就是好的。

2. 分层架构：按楼层分工

属于调用/返回风格里最常见的一种。把系统竖着切成几层，每层只跟相邻的层打交道，上层调用下层，下层返回结果给上层。

例子：一家餐馆分三层。一楼是大厅，服务员招呼客人点菜（表示层）；二楼是后厨，厨师炒菜（业务层）；地下室是仓库，库管管食材（数据层）。服务员不下地下室，库管不进大厅，各层各管一段，通过传菜梯和订货单联系。

教材里分层分得细一点就是两层 C/S（胖客户端+数据库服务器）、三层 C/S（表示层+应用服务器+数据库服务器）、三层 B/S（浏览器+Web 服务器+数据库）、再往上还有 N 层架构，表现层走 MVC/MVP/MVVM，访问层走 ORM。

好处：重用性（接口不变可以复用整层）、可维护、可扩展、支持递增设计。 坏处：不是所有系统都适合分层，会影响效率；层一多，改一个需求动好几层，累。还有个坑叫污水池反模式——请求简单穿透好几层却没干啥业务逻辑，白白绕一圈，纯属浪费。

教材原话：分层架构是最通用的架构，常作为初始架构，核心是"关注分离"——每层只负责本层工作。

顺便提一句 MVC、MVP、MVVM 这仨，都是分层在表现层的变体： - MVC：模型、视图、控制器，控制器负责把输入转成对模型的调用，模型变了再通知视图。 - MVP：比 MVC 更严格，模型和视图完全分离，所有交互都走 Presenter，可以脱离界面做单元测试。 - MVVM：只跟相邻层打交道，强调数据双向绑定——视图是观察者，模型是被观察者，改了自动同步。

3. 管道-过滤器架构：流水线

属于数据流风格。数据像水流一样依次经过一系列处理环节，每个环节只管自己那道工序，处理完往下一环节传。

例子：汽车装配线。第一站装底盘，第二站装发动机，第三站装车轮，第四站喷漆……每一站只干一件事，原料进来成品出去，站与站之间靠传送带连接。

好处：松耦合、高内聚、好重用、好维护、支持并行。 坏处：交互性差，不适合需要频繁回头的场景。要是喷完漆发现底盘装错了，你得把整条线倒回去，那就尴尬了。

典型例子就是 C 语言编译过程：词法分析 → 语法分析 → 语义分析 → 代码生成，一步步往下走。还有 ETL 数据处理、视频转码、CI/CD 流水线，都是这个套路。

数据流风格里还有个批处理，跟管道-过滤器的区别是：批处理是整批数据一起处理、不需要用户交互；管道-过滤器是流式的、可以弱交互。

4. 事件驱动架构：靠消息传话

属于独立构件风格。系统的各个部分不直接互相调用，而是往一个"事件总线"上发消息，谁感兴趣谁订阅，发消息的不关心谁来接。

例子：小区的公告栏。物业贴一张"明天停水"的通知，不挨家挨户敲门，谁路过看到了谁就知道。住户也不天天问物业"明天停水吗"，而是自己留意公告栏。发通知的和看通知的互相不认识，但信息传到了。

好处：松耦合、重用、可修改、可扩展。加个新订阅者不用改发送方。 坏处：构件放弃了对计算的控制——触发事件后不知道有没有人响应、不知道调用顺序；数据交换麻烦；正确性不好推理。适合那种"一件事触发一堆后续动作"的场景，比如下单之后要扣库存、发短信、记积分、推送通知。

这种架构在异步处理、实时通知、物联网场景里特别常见，Kafka、RabbitMQ 这些就是干这个的。

5. 数据为中心风格：围着个核心转

也叫仓库风格。所有构件都围绕一个中央数据存取，构件之间不直接通信，全靠这个数据中心接力。

例子：医院的病历室。各个科室的医生不互相传纸条，而是把检查结果都写到病历上，下一个科室来看病历就行。病历就是那个中心数据源。

子风格有几种： - 数据库系统：最常见，不解释。 - 黑板系统：适合语音识别、图像处理、知识推理这种"答案不明确、得多方凑"的场景。黑板是中央数据源，多个知识源往上面写，某个知识源看到自己能处理的状态就动手。优点是可改可维护可重用、容错好；缺点是测试难、不能保证好结果、效率低。 - 超文本系统：网页跳转就是。

典型应用还有 Windows 的注册表和剪切板——你复制粘贴就是往剪切板这个中心写、再从中心读。

6. 虚拟机风格：加一层翻译官

解释器：在程序和真实机器之间加一层"翻译"，让程序可以灵活应对自定义场景。 例子：你跟一个只会方言的老大爷谈生意，听不懂咋办？请个翻译。翻译就是解释器。 典型就是 Java 虚拟机：Java 代码编译成字节码，JVM 把字节码解释给操作系统执行。好处是跨平台，坏处是复杂度高、性能有损耗。

规则系统：在解释器基础上加一堆经验规则，适合专家系统。组成是规则集、规则解释器、规则数据选择、工作内存。 例子：老中医看病。脑子里装着一堆"如果……就……"的规矩（规则集），看到啥症状（工作内存里的数据）就翻对应的规矩来下判断。

7. 微服务架构：把大馆子拆成一条小吃街

这属于新兴架构，教材里单列。把一个大单体拆成一堆小服务，每个服务独立部署、独立运行、独立存数据，服务之间通过网络调用（一般是轻量级 HTTP 或 RPC）通信。

例子：原来那家大餐馆拆成一条小吃街。烤串的、卖凉菜的、煮面汤的、收银的，各开各的小摊，各自管各自的账。客人想吃啥就去对应摊位买，摊位之间互不干涉，某个摊位关门了也不影响别的摊位做生意。

教材给的好处：复杂应用解耦（小服务专注做一件事）、独立（独立开发测试部署运行）、技术选型灵活（支持异构）、容错（故障隔离在单个服务）、松耦合易扩展。 代价：分布式环境下数据一致性更复杂；测试更难；运维更复杂。

微服务有四种常见模式：聚合器微服务（API 网关 → 聚合器 → 分发到多个服务）、链式微服务（服务串成一条链）、数据共享微服务（多个服务共用数据库）、异步消息传递微服务（靠消息队列）。

考试特别爱考微服务和 SOA 的对比，记住一个比喻就够：微服务是"能拆就拆"的独立子公司，SOA 是"能放一起就放一起"的大公司业务单元。具体来说：

微服务这玩意儿被吹了好几年，好像不上微服务就落伍了。实际上它适合的是规模大到一定程度的系统，团队多、业务杂、需要独立演进。要是你那系统就三五个人维护，上微服务就是给自己挖坑。

8. 云原生与 Serverless：把租房子改成租工位

这不算一种独立架构，更像是一套部署和运维的新玩法，但已经成了新系统的默认选择。

例子：以前开公司得自己买服务器、租机房、拉网线、请运维，相当于自己盖楼。云原生就是改成租写字楼，工位按需租，人多就多租几个，人少就退几个，水电物业大楼都管了。Serverless 更进一步，连工位都不用固定租，按你今天来几个人临时安排，用几小时付几小时钱。

教材给云原生列了四要素：微服务、持续交付、DevOps、容器。还有七项设计原则，我用朴素语言翻译一下：

1. 服务化：拆成多个独立小模块，各管一摊。
2. 弹性：访问量大了自动扩，小了自动缩。
3. 可观测性：运行状态看得见，出问题好查。
4. 韧性：部分挂了，核心还能撑着，不一坏全瘫。
5. 所有过程自动化：从提交代码到上线，尽量工具自动完成。
6. 零信任：谁都不默认信任，每次访问都验身份。
7. 架构持续演进：架构不是一锤子买卖，跟着业务和技术一直优化。

容器这块记住 Docker（轻量、共享内核、秒级启动）和 Kubernetes（资源调度、自动发布回滚、自动修复、服务发现、弹性伸缩）。虚拟机和容器的区别：镜像大小 G vs M，启动时间分钟级 vs 毫秒级，隔离系统级 vs 进程级。

好处：弹性扩缩容，省心省钱（理想情况下），团队专注业务不用管基础设施。 坏处：被云厂商绑定了，人家涨价你难受，人家断网你瘫梹；调试排错比自建机房难，因为好多东西看不见摸不着。

9. 湖仓一体架构：数据界的"大杂烩自助餐"

这是这两年论文题的新宠。传统上，数据仓库存的是清洗过的结构化数据，先定好模式再存，只能做分析；数据湖啥都能存，原始数据原样倒进去，先存后定模式，能做分析也能做事务。俩各有各的毛病，仓库不够灵活，湖不够靠谱。

湖仓一体就是把这俩捏一块，教材给四大特征：

1. 实时处理与分析：支持流批一体，既能批量灌数据也能即时查询。
2. 事务一致性与 ACID：多人并发操作也能保证原子、一致、隔离、持久，不会你改一半别人给覆盖了。
3. 统一存储管理：结构化、半结构化、非结构化数据都放一层里，不用来回搬。
4. 多元分析：SQL、机器学习、图计算都能来。

例子：以前你得先去菜市场买原料（数据湖），再回家洗净切好放进冰箱（数据仓库），做饭时还得来回倒腾。湖仓一体就是开了个自助餐厅，原料、半成品、成品都在一个档口，你要啥直接拿，省得来回跑。

四、架构怎么知道好不好：架构评估

架构定完了不是就完事了，得评估一下行不行。教材给了三种基于场景的评估方法，考试必考：

SAAM（软件架构分析法）：最早形成文档、广泛使用的评估方法。关注可修改性、可移植性、可扩充性。流程是：场景开发 → 架构描述 → 单个场景评估 → 场景交互评估 → 总体评估。

ATAM（架构权衡分析法）：从 SAAM 发展来，针对性能、可用性、安全性、可修改性，在系统开发之前对质量属性进行评价和折中。分四个阶段：场景和需求收集 → 架构图和场景实现 → 属性模型构造和分析 → 折中。评估时会头脑风暴三种场景：用例场景（最终用户视角）、增长场景（架构怎么发展）、探索场景（极端增长）。

CBAM（成本效益分析法）：在 ATAM 基础上加了个经济模型，不光看技术好不好，还看划不划算。

口诀：SAAM 重可修改，ATAM 重权衡，CBAM 加经济。

利益相关者有三种：最终用户、架构师、开发人员。评估过程中要找出风险点、非风险点、敏感点、权衡点——这四个概念前面讲过了，案例题经常让你判断"这条算啥"。

五、说到底，架构是取舍

你看上面这些架构，没有哪个是"最好"的，每种都有适合的场景，也都有代价。

选架构就像选车：

• 一个人上下班代步，买个几万块的小车最合适，省钱好停。
• 一家人自驾游，得整个 SUV，空间大舒服。
• 搬家拉货，得弄个面包车或者皮卡。
• 你要是非要骑着自行车去搬家，那不是自行车的问题，是你的问题。

教材里的 ATAM 方法说白了就是在帮你算这笔账：每个架构决策对你的质量属性有啥影响，哪些是敏感点，哪些是权衡点，哪些埋了雷。架构师就是那个算账的人。

记住，世界上没有完美的架构，只有当时合适的架构。今年合适的架构，三年后业务翻十倍了可能就不合适了，那就改。这就是 ABSD 方法里"架构演化"那一步存在的意义——架构不是一锤子买卖，是会跟着系统一起长的东西。

软考论文里我写的那套大模型教学评估系统，当初就经历过从单体到分层再到引入微服务的演化。不是一上来就微服务，而是业务真长到那个体量了，单体扛不住了才拆。一上来就照着大厂架构抄一通，那是把别人家的装修图纸往自己家硬套，最后住进去肯定别扭。

六、一个二手架构师的经验分享

架构这东西，听着高大上，内核其实很朴素：把要做的事想清楚，把要做的人分明白，把做事的规矩定下来。

你不用会十八般武艺才能当架构师，但你得知道什么时候该用刀、什么时候该用枪、什么时候什么都不用先歇会儿。五大架构风格是给你当菜单用的，不是让你全点一遍的。

这功夫不是看书看出来的，是一个一个项目摔出来的。我那会儿裸考挂了论文，不就是只会写代码不会讲清楚"为什么这么干"吗？后来补考能过，也不是我突然技术暴涨了，而是学会了用架构的语言把取舍讲明白——什么是敏感点、什么是权衡点、为什么这个场景选这个风格、质量属性怎么权衡的，把这些说清楚了，分就来了。

所以想入门架构，别急着背名词。先把手头的系统摸透，想想它为什么这么设计、换了你你会怎么改、改了有啥好处有啥坏处。多问几个为什么，比背十本架构书都管用。

真要考试，那就另说——五大风格、质量属性六要素、ATAM/SAAM/CBAM、ABSD 六步、云原生七原则、微服务对比 SOA、湖仓一体四特征，这些该背还是得背。但背的时候最好也想想它们对应的生活例子，记起来快，用起来也活。