董云舟架构风格这个词，行业内每天都在说，但真坐下来把"风格"二字讲透的人不多。更常见的情况是：两个人争论微服务和单体哪个好，争到一半发现彼此对"微服务"的定义根本不一样。我在不同团队待过，从传统企业级单体到高并发互联网微服务都做过，踩过各种风格切换的坑之后，最大的体会是——架构风格不是用来"选"的，是用来"认"的。你得先认清每种风格背后的本质约束和代价，才知道自己在什么处境下、该用什么武器。这篇内容就把我对架构风格的理解梳理一遍，不整虚的，全是实际工作中验证过的判断逻辑。
我尽量用一个老工程师的口吻，把每一种主流风格拆开看：它解决了什么问题、牺牲了什么、适合什么场景，以及最常见的误用方式。适合刚入行想建立架构认知体系的开发者，也适合那些带团队做技术决策、需要在方案评审会上拍板的人。
1. 架构风格的本质：不是画图的层次，是约束的集合
先聊一个最容易被忽略的点：架构风格到底在约束什么？
很多人以为架构风格是"画架构图的方式"，分层就画个三层图，微服务就画一堆方块加连线。这是本末倒置。架构风格的本质是一组设计约束，约束的是系统中组件的划分方式、组件之间的交互规则、数据的流动方向，以及变化的传播路径。
1.1 风格是对"变化"和"成本"的预判
每种风格背后都藏着一个核心预判：系统未来最频繁的变化是什么？成本最高的变化是什么？
单体的预判是——业务的整体性最强，拆分反而会引入更多成本。分层的预判是——技术栈的纵向升级（换数据库、换UI框架）比横向的功能变更更昂贵。微服务的预判是——各业务域的独立扩展性和独立发布频率，比内部调用的性能损耗更重要。事件驱动的预判是——业务的高峰流量不可预测，削峰填谷的价值远超实时响应的价值。
没有这个预判，选风格就是瞎蒙。我见过一个日活不到一万的后台管理系统，团队非要上微服务，理由是"行业主流"。结果服务拆了十几个，每次联调都要协调三四个仓库的发布窗口，一个简单的用户列表页面要跨五个服务组装数据。这就是典型的预判错误——这个系统未来最频繁的变化是业务字段的增删，单体或模块化单体五分钟改完，微服务得改五处再走一遍跨服务联调。
1.2 组件的边界是风格的真正分水岭
看一个系统是什么风格，不要看它用了什么框架，要看它的组件边界画在哪里，边界两侧用什么机制通信。
- 单体：边界在模块内部，通信走函数调用
- 分层：边界在层之间，通信走接口
- 微服务：边界在进程之间，通信走网络协议
- 事件驱动：边界在事件生产者与消费者之间，通信走消息总线
边界不同，失败隔离、扩展单元、团队协作方式就全不同。判断一种风格是否适合你，核心问题永远是：这个边界切下去，我能承受边界两侧的通信成本吗？ 通信成本不只是延迟，还包括序列化、协议版本管理、分布式事务、链路追踪、环境一致性——所有这些，模块内函数调用时都不存在。
这一节先立个总纲：架构风格是一组约束，约束背后是对变化的预判，预判的落地是组件边界和边界通信机制。后面所有风格的讨论，都围绕这个总纲展开。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 单体与分层：看似"过时"，却是绝大多数系统的正解
这些年微服务被捧上天，单体被踩得一文不值。但我说句得罪人的话：这个世界上80%以上的业务系统，最合理的架构风格就是单体或"模块化单体"，最多再加一层清晰的分层。 不是大家不想用先进的，是很多系统的规模根本不需要付出微服务的代价。
2.1 单体架构的底气：强一致性和极简运维
单体不是"乱成一坨"的代名词。一个合格的单体架构，内部的模块划分可以是高度清晰的——用户模块、订单模块、商品模块各自独立成package或目录，模块间通过内部接口交互，只是最终部署在一个进程里而已。
单体的底气在哪儿？第一，强一致性天然可得。一个事务跨五张表？没问题，数据库本地事务直接搞定。这在微服务里要付出分布式事务的沉重代价。第二，运维极简。一套代码、一个进程、一份日志，排查问题不需要在全链路追踪系统里爬。我当年维护过一个日订单百万级的单体系统，高峰期单机扛不住就水平扩展两台实例，前面挂个负载均衡，性能问题基本傻瓜式解决。
很多人一提单体就想到"意大利面条式代码"，这是把"单体"和"代码混乱"划等号了。代码混乱是工程管理问题，不是架构风格问题。模块化单体（Modular Monolith）就是专门回应这个误会的——它保持单体部署的简单性，同时强制模块边界，禁止跨模块直接访问内部数据。