【案例题-知识点】架构风格与架构模式（2）：高频架构模式与选型

一、高频架构模式

除了五大基础架构风格，案例题还经常直接考具体模式或系统形态。真正难的不是背定义，而是看清这些模式各自解决的是什么矛盾，以及题干里的“信号词”到底在指向哪一种组织方式。

1. MVC：Spring MVC

怎么理解：MVC 解决的核心问题，不是“把系统分三层”这么简单，而是把输入处理、业务状态、界面展示拆开，避免界面代码和业务代码互相缠绕。

• Model管数据和业务规则
• View负责展示结果
• Controller接住用户输入，决定调用哪个业务，再把结果交给 View

在 Web 系统里，这通常表现为：请求先进入Controller，再调用Service或领域对象处理业务，最后返回页面或 JSON。它的价值在于把“怎么点页面”和“业务怎么运转”分开。

为什么会出现：早期很多应用把事件处理、页面刷新、业务计算全写在一起。这样做一开始开发很快，但页面一多，任何一个按钮点击都可能牵出一串业务逻辑，结果就是难测、难改、难协作。MVC 的出现，本质上是在解决界面变化频繁，而业务规则也需要稳定演进这一矛盾。

何时用，怎么考：MVC 适合页面较多、交互明确、展示逻辑和业务逻辑都需要长期维护的系统。题干里如果出现请求先到控制器、Model 管业务、View 负责显示、前后职责分离，通常就是在指向 MVC。

优点是分工清楚、业务可测试、前后协作边界明确；缺点是样板代码容易变多，业务一旦堆进 Controller，就会迅速出现“胖 Controller”问题。因此工程上常常在 MVC 之外再引入Service层，避免控制器变成新的大杂烩。

2. MVP 与 MVVM：Android MVP、Vue MVVM

怎么理解：MVP 和 MVVM 都不是凭空冒出来的，它们都是在 MVC 基础上继续往前走一步，专门解决富客户端界面状态太复杂的问题。

服务端 MVC 面对的是一次 HTTP 请求，请求进来、处理完、响应回去，这个生命周期很短。桌面应用、移动 App、重型前端却不是这样: 一个页面要持续存在，要处理输入框、滚动、异步回调、加载状态、按钮联动、错误提示。此时如果还把很多逻辑写在页面代码里，页面很快就会变成“既管显示，又管业务，还管流程”的混合体。

MVP 的思路是把这些逻辑集中到Presenter。View 只负责把“发生了什么”告诉 Presenter，再由 Presenter 决定“应该显示什么”。MVVM 的思路则更进一步，它不强调界面去接命令，而是强调界面直接绑定一份状态，由ViewModel维护这份状态，状态变了，界面跟着变。

它们到底差在哪：最容易混淆的地方，不是名字，而是谁在主导界面变化。

一句话记忆：

• MVP是“界面不做决定，Presenter 来指挥”
• MVVM是“界面不再手工刷新，而是跟着状态走”

何时用，怎么考：题干如果强调Presenter 完全中介、View 不碰 Model、接口回调刷新界面，优先判断为MVP。如果强调ViewModel、绑定、双向绑定、响应式更新、状态驱动视图，优先判断为MVVM。

MVP 的好处是逻辑集中、测试清晰，坏处是 Presenter 很容易越来越厚。MVVM 的好处是状态统一、胶水代码更少，坏处是绑定链条一长，调试就不再直观。工程上二者并不互斥，遗留客户端常保留 MVP，新页面和声明式 UI 更容易落到 MVVM。

3. 微内核：VS Code 插件体系

怎么理解：微内核解决的不是“分层”问题，而是稳定核心和快速变化能力怎么共存的问题。

如果一个产品要活很多年，要让第三方接入，还要按客户组合不同能力，那么最危险的做法就是把所有功能都写进主程序。这样每加一个能力都要动核心，核心越改越重，最终任何新需求都可能影响全局。微内核的做法是反过来：把真正稳定、必须统一管理的能力留在核心里，把变化快、定制强、可选装的能力做成插件。

因此，微内核最关键的一句话是：核心定义规则和扩展点，插件填充具体能力。

何时用，怎么考：它适合生命周期长、产品线多、插件生态明显、第三方扩展强的系统。题干如果反复出现插件、扩展点、SPI、核心极小、第三方扩展不改核心、可插拔，通常就该优先想到微内核。

它的优势是核心稳定、扩展灵活、长尾需求可以由插件生态承接；它的代价则在于接口设计必须非常克制，一旦扩展点设计失误，后续就会积累大量兼容债。同时，插件隔离、沙箱、版本冲突也都会带来真实的工程成本。

4. SOA：企业 ESB 集成平台

怎么理解：SOA 的出发点不是把一个新系统拆细，而是把企业里本来就存在的多套系统组织起来。

很多企业并不是只有一个应用，而是财务、人事、ERP、供应链、CRM 各有一套，技术栈、接口格式、数据库结构都不同。真正的问题不是“怎么把一个应用写得更优雅”，而是“这些已经存在的系统怎么在不推倒重来的情况下协同工作”。SOA 的答案是：先把能力包装成服务，再用统一契约、注册目录和集成层把它们接起来。

这里的关键角色通常有三个：

很多教材把ESB讲得很重，原因就在这里。ESB 不是普通消息中间件，而是企业集成的中心点，负责路由、协议转换、服务编排，以及日志、鉴权、限流等横切治理。

为什么会出现：SOA 解决的是遗留系统众多、技术异构、集成成本高、治理分散的问题。它更强调“把企业能力纳入统一治理”，而不是“让每个小团队各自自治”。

何时用，怎么考：题干如果强调ESB、服务契约、服务目录、异构系统集成、统一治理、编排、遗留系统对接，优先判断为SOA。它适合大企业集成、合规要求强、组织上需要统一入口和统一治理的场景。

它的优点是遗留系统能逐步纳管、服务边界更清晰、日志安全路由可集中治理；它的缺点是 ESB 容易成为中心瓶颈，组织流程通常会更重，排障也更依赖中间层。

5. 微服务：订单/库存/支付拆分

怎么理解：微服务经常和 SOA 混在一起，但两者的出发点并不一样。

微服务面对的通常不是“企业里已有很多异构系统”，而是“一个产品自己长得太大了”。系统最初可能是单体应用，团队小的时候开发很顺手；等团队变大以后，就会出现发布互相卡住、回归成本越来越重、一个模块故障拖垮全站、热点能力没法单独扩容等问题。微服务的核心思想，就是按业务边界把这个大系统拆成多个独立服务，让它们独立开发、独立部署、独立扩缩容。

从工程视角看，它不只是“拆服务”，而是配套带来一整套分布式问题：服务发现、网关、链路追踪、熔断限流、配置管理、最终一致性、灰度发布。也正因为这些配套成本很高，微服务不是越早拆越好，而是当单体的协作成本已经明显高于分布式成本时才值得拆。

和 SOA 到底差在哪：最容易区分二者的方法，是先看它在解决哪个层面的复杂性。

何时用，怎么考：题干如果强调独立部署、容器化、每服务独立库、限界上下文、团队自治、K8s、网关、熔断、链路追踪，通常优先判断为微服务。如果同时还在讲企业遗留集成、中央 ESB、统一编排，则应更偏向SOA。

微服务的优点是业务边界清楚，发布和扩容可以局部化，故障影响面也更容易控制；缺点是网络失败会成为日常问题，跨服务事务无法依赖单库事务解决，监控、日志和链路追踪如果跟不上，系统会迅速失去可观测性。

6. C/S 与 B/S：证券终端 vs OA Web

怎么理解：C/S 和 B/S 经常被当成“老知识点”，但案例题真正考的不是名词，而是客户端能力放在哪里、升级责任由谁承担。

C/S的关键是专用客户端。客户端需要安装，通常承担更多本地渲染、计算、缓存或设备访问能力。B/S的关键是浏览器作为通用客户端，页面和脚本由服务端统一交付，升级更多集中在服务端完成。

所以它们的区别，本质上不是“有没有前端”，而是系统把多少能力放在本地、把多少运维责任收回到服务端。

何时用，怎么考：题干如果强调零安装、统一升级、分支机构快速上线、浏览器访问，通常偏向B/S；如果强调专用客户端、离线能力、本地计算、外设依赖、胖客户端，通常偏向C/S。

真正答题时，不要把它们写成绝对对立。很多现实产品是混合形态，例如Electron是 Web 技术栈加桌面分发，小程序在体验上像 App，在运维上又很像 B/S。考试只要抓住“谁负责升级、客户端是否专用、是否依赖本地能力”这三个判断点，就不容易写偏。

二、架构选型思路