文章目录
-
- 一、高频架构模式
-
- [1. MVC：Spring MVC](#1. MVC：Spring MVC)
- [2. MVP 与 MVVM：Android MVP、Vue MVVM](#2. MVP 与 MVVM：Android MVP、Vue MVVM)
- [3. 微内核：VS Code 插件体系](#3. 微内核：VS Code 插件体系)
- [4. SOA：企业 ESB 集成平台](#4. SOA：企业 ESB 集成平台)
- [5. 微服务：订单/库存/支付拆分](#5. 微服务：订单/库存/支付拆分)
- [6. C/S 与 B/S：证券终端 vs OA Web](#6. C/S 与 B/S：证券终端 vs OA Web)
- 二、架构选型思路
一、高频架构模式
除了五大基础架构风格，案例题还经常直接考具体模式或系统形态。真正难的不是背定义，而是看清这些模式各自解决的是什么矛盾，以及题干里的"信号词"到底在指向哪一种组织方式。
1. MVC：Spring MVC
怎么理解： MVC 解决的核心问题，不是"把系统分三层"这么简单，而是把输入处理、业务状态、界面展示拆开，避免界面代码和业务代码互相缠绕。
- Model 管数据和业务规则
- View 负责展示结果
- Controller 接住用户输入，决定调用哪个业务，再把结果交给 View
在 Web 系统里，这通常表现为：请求先进入 Controller，再调用 Service 或领域对象处理业务，最后返回页面或 JSON。它的价值在于把"怎么点页面"和"业务怎么运转"分开。
为什么会出现： 早期很多应用把事件处理、页面刷新、业务计算全写在一起。这样做一开始开发很快，但页面一多，任何一个按钮点击都可能牵出一串业务逻辑，结果就是难测、难改、难协作。MVC 的出现，本质上是在解决界面变化频繁，而业务规则也需要稳定演进这一矛盾。
何时用，怎么考： MVC 适合页面较多、交互明确、展示逻辑和业务逻辑都需要长期维护的系统。题干里如果出现 请求先到控制器、Model 管业务、View 负责显示、前后职责分离，通常就是在指向 MVC。
优点是分工清楚、业务可测试、前后协作边界明确；缺点是样板代码容易变多，业务一旦堆进 Controller，就会迅速出现"胖 Controller"问题。因此工程上常常在 MVC 之外再引入 Service 层，避免控制器变成新的大杂烩。
| 考试信号 | 工程落地 |
|---|---|
| Controller 接请求、Model 管业务、View 展示结果 | Spring MVC 、ASP.NET MVC 、Rails ；前后端分离时 BFF 也常承担类似控制器职责 |
2. MVP 与 MVVM：Android MVP、Vue MVVM
怎么理解： MVP 和 MVVM 都不是凭空冒出来的，它们都是在 MVC 基础上继续往前走一步，专门解决富客户端界面状态太复杂的问题。
服务端 MVC 面对的是一次 HTTP 请求，请求进来、处理完、响应回去，这个生命周期很短。桌面应用、移动 App、重型前端却不是这样: 一个页面要持续存在，要处理输入框、滚动、异步回调、加载状态、按钮联动、错误提示。此时如果还把很多逻辑写在页面代码里，页面很快就会变成"既管显示，又管业务，还管流程"的混合体。
MVP 的思路是把这些逻辑集中到 Presenter 。View 只负责把"发生了什么"告诉 Presenter，再由 Presenter 决定"应该显示什么"。MVVM 的思路则更进一步，它不强调界面去接命令，而是强调界面直接绑定一份状态，由 ViewModel 维护这份状态，状态变了，界面跟着变。
它们到底差在哪： 最容易混淆的地方，不是名字，而是谁在主导界面变化。
| 模式 | 业务主要放在哪 | 界面怎么更新 | 更适合的场景 |
|---|---|---|---|
| MVC | Controller + Model | Controller/Model 配合刷新 View | 传统 Web 交互 |
| MVP | Presenter | Presenter 明确调用 View 接口 | 想强化隔离、强调单测的客户端 |
| MVVM | ViewModel | View 绑定状态，状态变则界面变 | 表单多、联动多、声明式 UI |
一句话记忆：
- MVP 是"界面不做决定，Presenter 来指挥"
- MVVM 是"界面不再手工刷新，而是跟着状态走"
何时用，怎么考： 题干如果强调 Presenter 完全中介、View 不碰 Model、接口回调刷新界面 ，优先判断为 MVP 。如果强调 ViewModel、绑定、双向绑定、响应式更新、状态驱动视图 ，优先判断为 MVVM。
MVP 的好处是逻辑集中、测试清晰，坏处是 Presenter 很容易越来越厚。MVVM 的好处是状态统一、胶水代码更少，坏处是绑定链条一长，调试就不再直观。工程上二者并不互斥，遗留客户端常保留 MVP，新页面和声明式 UI 更容易落到 MVVM。
| 考试信号 | 工程落地 |
|---|---|
| Presenter 中介、View 不碰 Model | Android 经典 MVP |
| ViewModel、绑定、命令、可观察状态 | Android ViewModel + LiveData/Flow 、WPF 、Vue 、React Hooks |
3. 微内核：VS Code 插件体系
怎么理解： 微内核解决的不是"分层"问题，而是稳定核心和快速变化能力怎么共存的问题。
如果一个产品要活很多年，要让第三方接入，还要按客户组合不同能力，那么最危险的做法就是把所有功能都写进主程序。这样每加一个能力都要动核心，核心越改越重，最终任何新需求都可能影响全局。微内核的做法是反过来：把真正稳定、必须统一管理的能力留在核心里，把变化快、定制强、可选装的能力做成插件。
因此，微内核最关键的一句话是：核心定义规则和扩展点，插件填充具体能力。
何时用，怎么考： 它适合生命周期长、产品线多、插件生态明显、第三方扩展强的系统。题干如果反复出现 插件、扩展点、SPI、核心极小、第三方扩展不改核心、可插拔，通常就该优先想到微内核。
它的优势是核心稳定、扩展灵活、长尾需求可以由插件生态承接；它的代价则在于接口设计必须非常克制，一旦扩展点设计失误，后续就会积累大量兼容债。同时，插件隔离、沙箱、版本冲突也都会带来真实的工程成本。
| 考试信号 | 工程落地 |
|---|---|
| 内核小、扩展点、插件接入、能力后装 | VS Code / JetBrains / Eclipse 插件体系、Chromium 扩展、K8s CNI/CSI/CRI |
4. SOA：企业 ESB 集成平台
怎么理解： SOA 的出发点不是把一个新系统拆细，而是把企业里本来就存在的多套系统组织起来。
很多企业并不是只有一个应用，而是财务、人事、ERP、供应链、CRM 各有一套，技术栈、接口格式、数据库结构都不同。真正的问题不是"怎么把一个应用写得更优雅"，而是"这些已经存在的系统怎么在不推倒重来的情况下协同工作"。SOA 的答案是：先把能力包装成服务，再用统一契约、注册目录和集成层把它们接起来。
这里的关键角色通常有三个：
| 角色 | 作用 |
|---|---|
| 服务提供者 | 提供可调用的业务能力和契约 |
| 服务消费者 | 按契约调用能力，不依赖内部实现 |
| 注册中心/服务目录 | 管理服务注册、发现和元数据 |
很多教材把 ESB 讲得很重，原因就在这里。ESB 不是普通消息中间件，而是企业集成的中心点，负责路由、协议转换、服务编排，以及日志、鉴权、限流等横切治理。
为什么会出现： SOA 解决的是遗留系统众多、技术异构、集成成本高、治理分散的问题。它更强调"把企业能力纳入统一治理"，而不是"让每个小团队各自自治"。
何时用，怎么考： 题干如果强调 ESB、服务契约、服务目录、异构系统集成、统一治理、编排、遗留系统对接 ，优先判断为 SOA。它适合大企业集成、合规要求强、组织上需要统一入口和统一治理的场景。
它的优点是遗留系统能逐步纳管、服务边界更清晰、日志安全路由可集中治理；它的缺点是 ESB 容易成为中心瓶颈，组织流程通常会更重，排障也更依赖中间层。
| 考试信号 | 工程落地 |
|---|---|
| ESB、契约、统一治理、异构集成 | IBM WebSphere 、Oracle OSB 、Mule ESB、企业集成平台 |
5. 微服务：订单/库存/支付拆分
怎么理解： 微服务经常和 SOA 混在一起，但两者的出发点并不一样。
微服务面对的通常不是"企业里已有很多异构系统"，而是"一个产品自己长得太大了"。系统最初可能是单体应用，团队小的时候开发很顺手；等团队变大以后，就会出现发布互相卡住、回归成本越来越重、一个模块故障拖垮全站、热点能力没法单独扩容等问题。微服务的核心思想，就是按业务边界把这个大系统拆成多个独立服务，让它们独立开发、独立部署、独立扩缩容。
从工程视角看，它不只是"拆服务"，而是配套带来一整套分布式问题：服务发现、网关、链路追踪、熔断限流、配置管理、最终一致性、灰度发布。也正因为这些配套成本很高，微服务不是越早拆越好，而是当单体的协作成本已经明显高于分布式成本时才值得拆。
和 SOA 到底差在哪： 最容易区分二者的方法，是先看它在解决哪个层面的复杂性。
| 维度 | SOA | 微服务 |
|---|---|---|
| 主要问题 | 企业异构系统集成 | 单一产品内部过大 |
| 组织方式 | 集中治理更强 | 团队自治更强 |
| 中枢特征 | 常见 ESB、编排、目录 | 常见网关、注册发现、服务网格 |
| 服务粒度 | 相对较粗 | 相对较细 |
| 数据方式 | 共享库更常见 | 一服务一库更常见 |
何时用，怎么考： 题干如果强调 独立部署、容器化、每服务独立库、限界上下文、团队自治、K8s、网关、熔断、链路追踪 ，通常优先判断为 微服务 。如果同时还在讲企业遗留集成、中央 ESB、统一编排，则应更偏向 SOA。
微服务的优点是业务边界清楚，发布和扩容可以局部化，故障影响面也更容易控制；缺点是网络失败会成为日常问题，跨服务事务无法依赖单库事务解决，监控、日志和链路追踪如果跟不上，系统会迅速失去可观测性。
| 考试信号 | 工程落地 |
|---|---|
| 独立部署、轻协议、自治团队、独立库 | Spring Cloud 、Go 微服务 、K8s 、API 网关 、Jaeger/Zipkin 、Kafka/RabbitMQ |
6. C/S 与 B/S：证券终端 vs OA Web
怎么理解： C/S 和 B/S 经常被当成"老知识点"，但案例题真正考的不是名词，而是客户端能力放在哪里、升级责任由谁承担。
C/S 的关键是专用客户端。客户端需要安装，通常承担更多本地渲染、计算、缓存或设备访问能力。B/S 的关键是浏览器作为通用客户端，页面和脚本由服务端统一交付，升级更多集中在服务端完成。
所以它们的区别，本质上不是"有没有前端"，而是系统把多少能力放在本地、把多少运维责任收回到服务端。
| 维度 | C/S | B/S |
|---|---|---|
| 客户端 | 专用客户端，通常需安装 | 浏览器即可 |
| 升级方式 | 客户端和服务端都要管 | 主要在服务端统一升级 |
| 本地能力 | 强本地计算、离线、外设支持更强 | 零安装、广覆盖更强 |
| 常见场景 | 证券终端、CAD、游戏 | OA、运营后台、政务办理 |
何时用，怎么考： 题干如果强调 零安装、统一升级、分支机构快速上线、浏览器访问 ，通常偏向 B/S ；如果强调 专用客户端、离线能力、本地计算、外设依赖、胖客户端 ，通常偏向 C/S。
真正答题时，不要把它们写成绝对对立。很多现实产品是混合形态，例如 Electron 是 Web 技术栈加桌面分发，小程序在体验上像 App，在运维上又很像 B/S。考试只要抓住"谁负责升级、客户端是否专用、是否依赖本地能力"这三个判断点，就不容易写偏。
| 考试信号 | 工程落地 |
|---|---|
| 胖/瘦客户端、安装方式、升级责任 | 原生桌面客户端 、移动 App 、H5/PWA 、Electron |
二、架构选型思路
| 题干/业务信号 | 适合的风格 | 考试落笔（关键词） | 工程锚点（可举 1 个） |
|---|---|---|---|
| 数据需要经过多步顺序处理 | 管道-过滤器 | 过滤器独立、数据沿管道、可增量 | Flink 算子链、网关 Filter、编译器各遍 |
| 系统分为展示、业务、数据三层 | 分层 | 上层依赖下层、接口隔离、职责分离 | Controller→Service→DAO、DDD 分层 |
| 需要高度松耦合、异步通信 | 事件驱动 / 发布-订阅 | 隐式调用、发布订阅、异步解耦 | Kafka、Outbox、领域事件 |
| AI 类问题、多种不确定推理策略 | 黑板 | 知识源、黑板、控制器、迭代求精 | 多路召回融合、多模型协同 |
| 规则频繁变化、需要动态执行 | 解释器 / 规则引擎 | 可配置、动态规则、解释执行 | Drools、营销规则台、脚本热更 |
| 需要插件化扩展 | 微内核 | 核心稳定、插件可插拔 | VS Code 扩展点、策略 SPI |
| 多团队独立开发、独立部署 | 微服务 | 细粒度服务、独立进程与库 | K8s、gRPC、每服务独立库 |
| 异构系统集成、标准化接口 | SOA | ESB、服务契约、企业治理 | 集成平台、遗留系统 Web Service |
| Web 前端交互复杂 | MVC / MVVM | 表现与逻辑分离、绑定 | Vue/React、MVVM 双向绑定 |