⭐ 架构的“5 种观察镜”
软件体系结构不是“一刀切”的设计，而是有 5 种核心模型，每种模型像一面“观察镜”，只聚焦系统的一个核心侧面，帮我们从不同角度理解架构。
- 通道模型 🚪：关注系统“计算的过程”，比如数据从输入到输出的流转，这类系统大多是“激励型”（有外部触发就会响应，像按开关灯就亮）。
- 过程模型 📋：研究“怎么造系统”，核心是构造系统的步骤和过程脚本，架构是按脚本执行后的结果（比如搭积木，按“先搭底座→再搭墙体→最后封顶”的过程，成品就是积木架构）。
- 功能模型 🧩：把架构看成“分层的功能构件组”，下层构件向上层提供服务，比如手机 App 的“界面层→业务层→数据层”，界面层依赖业务层的服务，业务层又依赖数据层的服务，是一种特殊的框架模型。
- （隐含）框架模型 🏗️：核心是“通用骨架”，比如 Spring 框架，开发者不用重新设计基础结构，只需在骨架上填业务代码，功能模型就是它的“分层版”。
- （隐含）数据模型 📊：关注系统数据的存储、流转和处理，比如数据库的表结构设计，是很多信息系统的核心（比如电商系统的用户表、订单表）。
🧠 2.1“4+1”视图模型 – 架构的“全景地图”
5 种基础模型各有侧重，单独用不够全面，Kruchen 在 1995 年提出“4+1”视图模型，用 5 个视角（4 个核心视图 + 1 个场景视图）“拼出”系统的完整架构，就像用 5 张照片合成一张全景图，每个视角对应不同角色的需求。
1. 逻辑视图 – 给最终用户看的“功能蓝图”
核心关注“系统能做什么”，描述系统的功能构件和构件间的逻辑关系，不关心代码怎么写、硬件怎么部署。比如微信的逻辑视图：“聊天构件”“朋友圈构件”“支付构件”，构件间的关系是“聊天时可分享朋友圈，支付时可发红包”。
2. 开发视图 – 给编程人员看的“代码地图”
核心关注“代码怎么组织”，描述软件的模块、子系统划分和依赖关系。建议分 4~6 层子系统，且子系统只能和同层或下层通信（比如“界面层→业务层→数据层”，界面层不能直接连数据层），避免复杂依赖。比如微信的开发视图：“UI 模块”“网络请求模块”“数据库模块”，UI 模块依赖网络模块，网络模块依赖数据库模块。
3. 进程视图 – 给系统分析师看的“动态流转图”
核心关注“系统怎么运行”，描述系统的进程、线程和它们的交互（比如消息传递、共享内存），属于 动态结构。比如微信的进程视图：“主进程（显示界面）”“后台进程（接收消息）”“支付进程（处理支付请求）”，后台进程收到消息后，通过消息传递通知主进程显示消息。
4. 物理视图 – 给系统工程人员看的“硬件部署图”
核心关注“软件怎么装到硬件上”，描述系统的拓扑结构、硬件结点和软件映射关系，属于 动态结构。比如微信的物理视图：“用户手机（装微信 App）”“微信服务器（处理消息、存储数据）”“支付服务器（处理支付）”，App 的“消息构件”映射到微信服务器，“支付构件”映射到支付服务器。
5. 场景视图 – 连接 4 个视图的“桥梁”
核心关注“用户怎么用系统”，用具体场景（比如“用户登录微信→发消息→收消息”）验证 4 个核心视图的合理性，是架构设计的“起点和终点”。比如文档中的 ACS 系统场景：“电话摘机→控制器检测状态→终端分配资源→发出拨号音→用户拨号→终端分析号码→打开会话”，这个场景能覆盖逻辑、开发、进程、物理 4 个视图的核心内容。
🔄 2.3 软件体系结构的生命周期模型 – 架构的“成长轨迹”
软件体系结构不是“设计完就不管”，而是有完整的“生命周期”，从诞生到终结，像人的“出生→成长→成熟→衰老→死亡”，每个阶段都有核心任务。
- 需求阶段 📝：收集用户需求，明确系统要解决的问题，为架构设计奠定基础（比如开发“外卖系统”，需求是“用户下单、商家接单、骑手配送、支付”）。
- 建立框架阶段 🏗️：设计系统的整体框架（比如外卖系统的“用户端、商家端、骑手端、后台管理端”4 大模块）。
- 设计阶段 ✏️：对框架进行细化，确定构件的详细接口、算法和数据类型（比如用户端的“登录构件”，接口是“输入手机号 + 验证码”，算法是“验证验证码有效性”）。
- 求精阶段 ✨：优化架构，解决设计中的问题（比如外卖系统高峰期卡顿，增加“缓存构件”减少数据库压力）。
- 实施阶段 🛠️：根据架构写代码、部署系统（比如开发用户端 App、部署后台服务器）。
- 评价度量阶段 📏：通过系统运行情况，定性评价（比如用户体验好不好）、定量度量（比如响应时间、并发量）架构的优劣，总结经验。
- 演化阶段 🌱：根据新需求修改架构（比如外卖系统新增“拼单功能”，在用户端增加“拼单构件”，调整业务层逻辑）。
- 逆向工程 / 再造工程阶段 🔍：如果架构难以理解，通过逆向工程（从代码反推架构）或再造工程（重新设计架构）优化。
- 终结阶段 ⚰️：架构经过多次修改，无法满足需求且优化成本过高，用新架构替代（比如早期的“PC 端外卖系统”，被“移动端外卖系统”的新架构替代）。
🤖 2.4 软件体系结构的抽象模型与关系 – 架构的“数学骨架”
这部分是架构的“底层逻辑”，用抽象的概念和规则描述架构，帮我们更严谨地设计和验证架构，初学者不用死记公式，重点理解核心概念。
1. 核心概念：构件与连接件
①构件 🧩：系统的“基本单元”，比如“登录构件”“支付构件”，有自己的输入、输出和功能；② 连接件 🔗：连接构件的“桥梁”，比如消息传递、函数调用（比如“登录构件”通过“函数调用”连接“数据库构件”，获取用户信息）。
2. 构件的 3 种核心运算（初学者通俗理解）
- 顺序运算（C₁□C₂） ➡️：构件按顺序执行，比如“登录构件→查询构件”（先登录，再查询）。
- 选择运算（C₁△C₂） ⚪⚫：按条件选一个构件执行，比如“会员登录构件△普通用户登录构件”（根据用户类型选登录方式）。
- 循环运算（C*） 🔄：构件重复执行，比如“刷新消息构件 *”（每隔 10 秒刷新一次消息）。
3. 架构的关系：映射与依赖
①映射 📌：不同架构间的“对应关系”，比如旧架构的“登录构件”对应新架构的“智能登录构件”（支持手机号、微信登录）；若映射是“一对一且全覆盖”，则两个架构“同构”（结构完全一致，只是名称不同）。
②依赖关系 🧵：构件间的“依赖”，比如“支付构件”依赖“订单构件”（先有订单，才能支付），分为事件依赖（一个构件的事件触发另一个构件）和实现依赖（一个构件的功能依赖另一个构件的实现），且依赖满足“传递性”（A 依赖 B，B 依赖 C，则 A 依赖 C）。
4. 架构的范式：RNF 范式
核心是“让架构更简洁、易维护”，满足 RNF 范式的架构，构件间的依赖关系清晰（顺序、分支、循环），没有冗余依赖。比如“下单构件”的实现依赖是顺序关系（“选商品→填地址→付款”），可拆分为“选商品构件；填地址构件；付款构件”，每个构件独立，后期修改地址功能时，不用动其他构件。
☁️ 本章总结 – 从零学架构的“核心路径”
初学者学软件体系结构，不用一开始就啃复杂公式，核心路径是：①先懂 5 大基础模型，知道架构的“5 种观察方式”；②再掌握“4+1”视图模型，能画出系统的“全景图”；③了解生命周期，知道架构“从设计到终结”的全过程；④最后接触抽象模型，让架构设计更严谨。
记住：架构的本质是“解决问题”，不是“炫技”，无论是简单的小系统，还是复杂的大平台，好的架构都能让系统“易维护、易扩展、高性能”✨。