黑河市all几年前我参加一次架构评审，讲的人用了40分钟，屏幕上的图换了一张又一张：流量进网关、落到微服务、经过缓存、最终到数据库。图很完整，分层很清晰，看起来很“架构”。评审快结束时我问了一句：如果某天凌晨两点数据库出现慢查询，你的第一反应去看哪个组件？会议室安静了五六秒。后来这个系统上线，业务增长比预期快，最先被推翻重构的，恰恰是当时最漂亮的那张图。
这件事让我重新理解了什么是架构：架构不是一张分层图或者部署图，架构是一连串设计决策，以及这些决策在真实环境里被验证后产生的后果。我见过太多人把精力花在把图画得漂亮，却忽略了架构真正值钱的能力，是对原则的理解、对约束的判断和对后果的承担。下面就把我这些年做系统设计、做方案评审、折腾微服务、事件驱动、嵌入式甚至AI模型结构时沉淀下来的实操体会整理一遍，希望能给正在搞架构设计、准备系统架构设计师考试、或者单纯被各种架构风格绕晕的朋友一点参考。
1. 架构到底是什么：连续假设、决策序列与那张被高估的图
1.1 架构图只是投影，决策才是本体
先聊一个最容易被误解的点：架构图不等于架构。
一张框线图能表达的，充其量是系统在某一时刻的组件构成和依赖关系。它回答的是“现在有什么”，但它回答不了“为什么会有”“当初为什么不做另一种方案”“哪条线断了会发生什么”。这三个问题才是架构设计的真正命题。
举个例子。很多业务系统都画过这样一张图：接入层、业务层、缓存层、数据层，整整齐齐。有人看了觉得架构很清晰，可真正进入维护期才发现，缓存层处理了读请求，却没有处理写后一致性的问题；业务层看起来拆了几个模块，但实际上所有模块都直接连了同一张订单表；接入层的鉴权逻辑散落在每个服务里，改一处权限规则要排期三天。这些信息，图上一个都看不出来。
架构图的第二个问题是：它把被否决的方案给抹掉了。这非常可惜，因为架构评审中最有价值的往往不是最终选中的那条路，而是当时为什么没有选另一条路。如果这些理由没有沉淀下来，三个月后新来的同事看到现在的设计，只会觉得“这里有点绕”，但他不知道绕是因为曾经有一个更简单的方案在特定约束下行不通。于是他会又踩一次坑，或者为了“简化”把架构改回去。
所以我现在自己画图时有一条硬规矩：每画一个组件、每连一条线，都要在旁边写清楚这条线代表的是调用、数据流还是部署依赖；每个被否决的候选方案，单独留一节记录，写清楚否决理由。图是给别人快速理解用的，真正承载架构信息的，是图背后的决策序列。
1.2 业务系统、嵌入式、AI模型都在回答同一组问题
这些年技术热词换来换去，从微服务架构到分布式架构，从CNN逻辑架构到Transformer架构，再到多Agent系统，看起来领域隔得很远，实际拆开看，大家回答的问题惊人的一致。
第一个问题是边界。系统的能力应该切成几块？每一块的职责是什么？什么可以跨边界调用，什么不允许？业务系统里这叫模块划分或服务划分；嵌入式里叫任务划分；AI模型里叫层与子模块设计。边界划得好不好，直接决定了后续所有变更的扩散范围。
第二个问题是状态。数据放在哪里、由谁写入、由谁读取、一致性能容忍到什么程度？做支付系统的人每天都在跟这个死磕；做嵌入式的人则在纠结哪些变量要在中断上下文里保护；搞分布式系统的人要处理多副本、脑裂、时钟漂移。状态是架构里最麻烦的东西，大多数系统的复杂度根本不是业务逻辑本身，而是状态在多处流动所带来的同步问题。
第三个问题是依赖方向。高层组件应不应该知道底层组件的存在？一个模块发生了变更，谁会被波及？指令集架构之所以重要，就是因为它是一份软件与硬件之间的稳定契约。应用开发者不需要知道CPU内部有多少级流水线，只需要知道指令集定义了哪些操作、寄存器怎么用，这就把“变的部分”和“不变的部分”隔开了。ARM架构、MIPS架构能长期稳定，靠的不是某颗芯片的性能，而是这套契约的稳定性。
想明白这一点，再看那些花里胡哨的架构名词就不慌了。微服务只是把边界从进程内提到了进程外；事件驱动只是把同步依赖变成了异步消息流；Transformer也只是在层与层之间定义了一种特定的信息流动方式。底层逻辑并没有变。
1.3 用对待假设的方式管理架构
还有一个我越来越认同的判断：架构表面上是结构，本质上是假设的集合。
选分布式架构，等于假设网络带来的复杂度可以被独立扩展的收益覆盖；选事件驱动，等于假设异步削峰的价值大于链路排错的成本；选大内存方案而不是加缓存层，等于假设数据量不会暴涨到单机扛不住的程度。没有哪个假设是永远正确的，只分在某个时间窗口内成不成立。架构师的核心工作，其实是管理这一组假设的过期时间。
为什么很多系统重构那么痛苦？因为当初的假设被当成了永久事实。系统设计时假设并发只有一两千，于是选择了最简单的主从数据库方案，等流量翻了二十倍，才发现读写分离的延迟、主从切换的节点都像定时炸弹。如果当初在设计文档里写了一句“本方案假设峰值QPS不超过2000，若超过需引入分片或缓存分层”，后来的人就不至于把架构推翻重来，而是顺着这个信号提前做局部升级。
基于这个认识，我现在特别推荐“延迟决策”的做法：能不现在做的决策就尽量不做，但要把触发决策的信号写清楚。比如“当前阶段内部模块之间走同步调用，等某条链路的流量需要独立扩容时，再拆成独立服务”。这既不会让架构失控，又不会为想象中的未来提前买单。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 真正扛得住落地的原则：从口号到可执行的取舍
2.1 关注点分离：拆分对象不是组件，是变更原因
架构设计原则翻来覆去就是那么几条：单一职责、开闭原则、接口隔离、依赖倒置。道理大家都懂，可一落地就走样。问题出在哪？我看是把“职责”理解错了。
单一职责不是指一个类只做一件事，而是指一个模块应该只有一个引起它变更的原因。举个实际场景：一个订单服务里的金额计算，刚开始只涉及商品单价和数量；后来营销活动要加优惠券；再后来用户等级要加折扣；再后来要区分企业客户和个人客户。如果这些规则全部写在订单金额计算的一个方法里，那任何一条规则变化，你都要改这个方法，还要担心另外三条规则被破坏。这才是真正需要分离的东西：不是因为优惠券代码和订单代码“看起来不一样”，而是因为它们的变更频率和变更原因不同。
设计模式本质上就是为“分离变更原因”服务的。策略模式是把一类可以互相替换的算法抽出来；观察者模式是把状态的变更通知机制与业务主体分离；门面模式是给复杂子系统提供一个稳定入口，让调用方不依赖内部变化。理解了这个，你就不用去背设计模式期末考里的类图了。模式是一个成熟社区给常见问题起的名字，它帮你把“哪部分会变、哪部分不变”说清楚。
2.2 最小可用原则：不是不设计，是只为高确定性未来付费
我见过太多项目死于过度设计，而不是死于设计不足。
有一个印象很深的系统，业务还没跑通，架构上先引进了消息队列，理由是“以后要做异步解耦”；引进了分库分表中间件，理由是“以后数据量肯定会大”；引进了容器编排平台，理由是“以后要弹性伸缩”。结果是系统上线整整一年，消息队列只处理了一个每天跑几次的定时任务，分库分表后连最简单的跨页查询都变得很别扭，容器平台的运维成本把一个不到十人的团队压得喘不过气。不是说这些技术不好，它们都是解决特定问题的好工具，但“以后可能要用”从来都不是现在引入的理由。
我这里的经验是，架构设计要区分两类需求。一类是确定性很高的核心路径，比如订单创建的库存扣减，这是从第一天就必须保证正确的事情；另一类是可能性较高的未来需求，比如“以后可能要多一个分销渠道”。前者的设计要一步到位，后者的设计优先级很低，只需要保证将来有扩展接缝就行，比如把创建订单的接口参数设计成可扩展结构，而不是直接把Kafka搬进来。
最小可用原则的另一个好处是让反馈来得更快。系统越简单，上线越早，真实流量给到的信息会推翻很多纸面推测。很多当时拍脑袋担心的性能问题，在真实数据面前根本不是问题；而真正的问题往往藏在那些你没想到的地方。
2.3 幂等性设计：一个原则从规范落到代码库的完整路径
聊一个具体的原则落地案例：API幂等性。这个词在分布式、微服务、消息队列的场景里被反复提到，但很多人只把它当成“要用唯一键去重”，没有理解它其实是架构层面对“失败模型”的回应。
为什么要做幂等设计？因为在分布式环境里，调用方收到超时的时候，你根本不知道服务端到底处理成功了没有。没有幂等保护，一次重试就可能导致订单重复创建、库存重复扣减、余额重复扣减。所以设计原则应该约定：凡是涉及资金、库存、状态流转的写操作，都必须支持幂等。
落地的路径一般分三层。
第一层是生成幂等键。客户端在发起请求时带上一个唯一标识，比如订单号、业务流水号，服务端把它当作这个操作的唯一凭证。第二层是在存储层加约束。数据表里把业务唯一号建唯一索引，或者用Redis的setnx做分布式锁。第三层是重复请求直接返回原结果。不只返回成功，还要把第一次执行的结果缓存下来，这样客户端重试时拿到的是同一个结果，而不是再执行一遍逻辑。
用伪代码表达大概是这样的：
python复制# 以订单支付回调为例
def payment_callback(order_id, payment_result):
# 幂等键：order_id + 回调类型
lock_key = f"pay_callback:{order_id}"
if not idempotency_store.lock(lock_key):
return idempotency_store.get_previous_result(order_id)
try:
# 真正的业务处理：更新订单状态、记账、通知等
result = process_payment(order_id, payment_result)
idempotency_store.save(lock_key, result)
return result
finally:
idempotency_store.release(lock_key)
这个案例值得注意的点是：幂等不只是“代码层面判断一下是否处理过”，它需要把状态存储、分布式锁、重试返回结果串起来。从架构视角看，这就是在“网络不可靠”这个假设之上，为业务操作重新建立的一种确定性。类似的约束还包括分布式事务里的对账、消息队列里的消费位点管理，本质都是把不确定性转化成可查询、可恢复的确定流程。
2.4 原则冲突的裁决点：我不会平均用力
原则与原则之间是会打架的。要强一致就别想要高可用；要高弹性就得接受最终一致；要极简就得放弃很多花哨能力；要极致性能往往要牺牲可维护性。如果只是把原则背出来而不排优先级，做决策的时候还会更纠结。
我的做法是，在每次做出关键架构选择前，先明确这个系统的质量属性优先级。不是说其他属性不重要，而是当冲突发生的时候，让步的必须是排在后面那个。比如做账户和支付核心链路，数据不丢、强一致就是第一位的，宁可损失一些性能也要先保证账能对平；而做资讯信息流的展示服务，展示短暂不一致完全可接受，可用性和响应速度反而更重要。
不少公司会把“八大管理原则”这类治理规则沉淀成文档，我觉得本质也是在组织层面定一个优先级框架，避免每个团队在同一个问题上反复吵架。原则只有落到“A和B冲突的时候选谁，为什么选谁”这个粒度，才真正有意义。否则它只是一句正确的废话。
3. 主流架构风格的选型逻辑：单体、微服务、事件驱动与嵌入式分水岭
3.1 我为什么永远把模块化单体放在备选列表第一位
近几年只要聊架构，话题就往微服务和分布式上跑，好像不拆微服务就不算做了架构设计。但以我实际评审过的系统来看，至少六成以上应用微服务属于本末倒置。
先说一个反直觉的事实：很多系统真正的问题不在“大”，而在“乱”。模块之间职责不清、数据表互相join、一个接口里串了七八个业务模块的代码，这时候就算把它拆成十个微服务，也只是把进程内的乱变成跨网络的乱，甚至更严重，因为原来IDE里还能一眼看到调用链，现在要靠分布式追踪系统去捞。
所以我通常建议先做模块化单体。也就是说，代码还是在一个应用里编译、部署，但内部按业务能力划分模块，模块之间只能通过接口访问对方的领域能力，不能直接操作对方的数据表。每个模块有自己清晰的边界、自己的存储表，模块发布的节奏可以在代码仓库层面分开管理，等将来某一块的流量独立增长到瓶颈，或者某个团队的发布节奏与其他团队已经互相拖累时，再把它拆出去成为独立服务。
这个过程的好处是，拆分的每一步都有真实数据支撑，而不是靠拍脑袋预判。实践中我见过成功的微服务改造，无一例外，都是先把单体内部边界理得很清楚，然后按边界一个一个拆；反过来，边界一塌糊涂就直接拆服务的，基本都落得一地鸡毛。
3.2 微服务和分布式架构的五笔账，算清了再动手
分布式架构和微服务的收益是明摆着的：独立扩展、故障隔离、独立发布。但收益从来不是免费的。引入它们等于同时背上了五笔硬成本，这点很多团队前期没有认真算过。
第一是网络成本。原来一次本地方法调用现在变成了RPC，要处理超时、重试、连接池耗尽、服务雪崩。第二是数据成本。原来一个数据库事务能搞定的事情，现在要跨多个服务做数据一致性，最终一致、对账、补偿、幂等，全都是新增工作。第三是运维成本。链路追踪、日志聚合、容器编排、服务注册发现、配置中心，监控告警，这一整套基础设施在单体架构里根本不需要。第四是团队成本。服务多了以后，接口版本管理、契约测试、跨团队联调，消耗的管理精力远超写代码本身。第五是认知成本。分布式系统里，故障从“进程崩溃”变成“不确定的慢”，你会遇到脑裂、时钟漂移、重复消息，调试难度完全不是一个数量级。
我常常用一个决定树来辅助判断：如果当前团队小于十人、系统并发没有出现明显的单点瓶颈、模块间的接口调用也还没到互相拖累发布的程度，那就不要碰微服务。而如果某个模块的流量消耗模式确实和别人差异极大，或者某个独立的子团队已经可以端到端负责一条业务线，这时候拆分才划算。
其实不仅仅是互联网后端。在一些网络设备里，分布式交换机系统架构同样需要处理控制面与数据面的分离，用一个快速的数据面处理报文，用一个相对慢但灵活的控制面来管理规则。它拆开的逻辑和微服务一样，是“变化的节奏不同”和“性能诉求不同”，但最后要付出的分布式一致性与运维代价也一模一样。
3.3 嵌入式场景：从超级大循环到事件驱动的那道分水岭
不少嵌入式开发者都是从51单片机或者STM32入门，最早写的架构基本都是超级大循环。代码大概长这样：
c复制while (1) {
read_sensor();
update_ui();
handle_comm();
delay(10);
}
大循环的优点是逻辑简单、时序可控性直观，非常适合任务少、事件固定的小系统。它的问题在于：整个系统只有一个时间轴。一旦某一次handle_comm()里出现一个比较长的阻塞，比如等待串口发送完成，那么读传感器和刷新UI就被拖住了。按键扫描会卡顿、屏幕会闪烁、高优先级的报警信号得不到及时处理。
从大循环升级到事件驱动，是嵌入式架构的一道典型分水岭。核心思路不是取消循环，而是把整个系统的时间轴打散成多个短任务。按键来了，投一个事件；定时器到了，投一个事件；串口收到完整帧，投一个事件。一个调度器或者状态机来决定先处理哪个事件，每个事件的处理函数必须快速返回，不能长时间阻塞。更复杂的场景，直接上RTOS，靠内核的优先级抢占保证硬实时性。
我补一句从实践里学到的经验：什么时候该升级？不是看代码行数，而是看系统里有没有“不同重要程度且互相抢占时间”的任务。如果按键响应慢一点没关系，串口处理也没有高优先级需求，大循环完全够用。当出现屏幕刷新和数据采集在争时间、或者通信处理偶尔导致关键操作延迟时，就该动手改了。这里的架构原则和互联网后端是一样的：让更重要的任务优先拿到计算资源，并且把不可控的长操作切成可控的短步骤。
3.4 多Agent架构实验：subagent作为工具的启示
最近AI领域很热闹，多Agent系统也成了一个流行词。看最新的一些设计讨论，主从模式里有一个很妙的观察：本质上，subagent可以被当作一种特殊的tool来调用。我挺认同这个视角，因为它无意中点破了一个传统架构师熟知的道理——策略与执行分离。
在主从模式的Agent架构里，主Agent不一定要理解任务内部的所有细节，它只负责拆解目标、选择工具、提供必要的上下文、定义输入输出格式，然后接收结果。subagent像tool一样被调用，意味着它的行为边界是清晰的，输出是约定好的，调用方不需要去猜它到底在想什么。这和微服务架构里的服务契约如出一辙：把复杂系统内部的能力封装成稳定接口，外部依赖接口而不是依赖实现。
当然，多Agent系统也继承了分布式系统所有经典难题：状态放在主Agent还是每个subagent里？调用超时怎么办？结果怎么校验？上下文会不会被撑爆？要怎么记录调用链用于排错？这些问题的答案，做软件架构设计的人早就趟过一遍了。每一种新架构范式出现时，总会有人说这是颠覆性的，但真正落地时你会发现，边界、协议、状态、故障处理这些老话题一个都绕不开。
4. 架构决策的落地链路：从场景约束到评审追问
4.1 第一步不是画图，是把关键场景和约束写出来
很多架构新手拿到需求就直接画图，这是最大的误区。画图应该在关键分析完成之后，而不是之前。
我习惯的第一步是，把系统最重要的十个左右业务场景写下来，并且对其中两三个极端场景做专门描述。极端场景包括：流量高峰期、数据量暴涨、某个下游服务长时间不可用、半夜要跑批。每个场景都要带上量化的质量属性目标，比如“商品查询接口在峰值1000 QPS、缓存失效的情况下，P99响应时间小于500毫秒”或“订单创建后1分钟内必须能够被对账任务发现并处理”。
第二步是识别约束。技术栈、团队规模、部署环境、已有基础设施、预算、数据合规要求，这些都是约束。约束决定了你不可以做什么，它比需求更能左右架构决策。比如一个团队只会Java，就不要引入一个需要全员学习Erlang的组件；现场部署在客户内网，就不要假设可以随时用云上的托管服务。
第三步才是根据关键场景和约束，列出几个候选架构，逐一比对。做比对的维度不必贪多：功能覆盖度、开发成本、运维成本、性能上限、故障恢复时间，每一条给一个简短判断即可。最后选定方案不是因为它每项都最好，而是因为它在最重要的几个维度上满足得最好。
4.2 架构文档的真正主角：决策记录与代价清单
我见过的架构文档大多是一堆图加一段简介，写得像项目汇报PPT。这种文档在评审时还挺好看，但它对后续维护几乎没有帮助。后来我开始用ADR（架构决策记录）的格式来写关键决策。
一份ADR不需要很长，但必须包含这么几个部分：背景、决策、后果、替代方案、状态。比如我曾经处理过一个订单和库存联动的方案，ADR写下的大致内容是：
状态：已接受。背景：创建订单时需要同时预占库存，原来用跨服务同步调用保证强一致，但大促时下游抖动会拖垮下单主链路。决策：下单主流程只做本地订单状态写入，预占库存改为发送异步消息，由库存服务消费后扣减，库存扣减结果通过回调修改订单状态，同时由定时对账任务扫描异常订单补偿。后果：订单和库存之间变成最终一致，极端情况下可能出现短时间超卖，需要通过对账任务在数秒内修复。替代方案：使用分布式事务中间件，但引入协调者节点带来的运维复杂度超过当时团队承受范围，暂不采用。
这样的记录，价值不在于决策本身对错，而在于后来人看到订单和库存状态不一致的代码时，知道这是有意为之、有补偿机制的，而不是顺手写出来的bug。代价清单也重要。我会在文档里明确写出“当前方案选择的简单是什么、背负的复杂是什么”，比如选择了读写分离，换来的复杂是主从延迟可能造成读不到刚写入的数据；选择了最终一致，换来的复杂是每个环节都需要幂等。把代价写出来，比只写收益诚实得多。
4.3 评审时我固定追问的四类问题
做架构评审多了以后，我慢慢收敛出四个固定问题，每次评审都会按顺序问一遍。
第一问：如果某个关键节点在凌晨两点宕机，数据在哪里、业务多久恢复、怎么恢复？问的是故障域和恢复方案。很多方案图看着完整，一碰到“节点挂了”就开始含糊，说“应该会有告警”“基础设施层应该能自愈吧”。架构评审最不能容忍的就是“应该”和“吧”。
第二问：一个刚入职的同事，只凭这份架构文档，能不能知道改一个需求应该动哪个模块、不能动哪个模块？问的是边界是否清晰。如果文档里没有写清楚依赖规则和禁止项，那新成员就只能靠猜，猜错的代价早晚会暴露。
第三问：系统里最可能变化的东西是什么，为此留下了什么接缝？我并不是要求每个变化都被预判到，但架构师必须能指出，当团队规模扩大、业务范围扩展、单量暴涨这些大概率事件发生时，系统会先在哪里撑不住。这往往也是未来重构的起点。
第四问：如果再给你一次机会，这个方案里哪一层可以被直接删掉？问的是极简能力。很多方案加了一层缓存、加了一个消息中间件、加了一个抽象接口，问到最后发现并没有非加不可的理由。能主动做减法的架构师，比只会堆组件的架构师稀缺得多。
4.4 设计模式和参考架构的正确打开方式
设计模式在很多人印象里是一堆必须背的类图，尤其是期末考或者面试前突击的时候。但实际做架构设计时，设计模式的价值不在于分类，而在于它给常见问题起了一个“有共识的名字”。
举个例子，说“这里用策略模式”比手画五个类的依赖关系图要省事得多，大家一听就知道是想把一组算法做成可替换的形式。说“用观察者模式做状态变更通知”，其他开发者立刻明白模块间的耦合方式是事件订阅而不是直接调用。模式是交流和思考的词汇表，而不是模板。
但我也踩过套模式翻车的坑。有一回处理一段类型判断特别多的代码，看第一眼就想上策略模式，把每个类型包装成一个策略类。结果业务里类型一共就三种，而且一年也不怎么变，策略模式反而把原本集中在一个方法里的判断逻辑拆到五个文件里，阅读代码要来回跳。后来我把它们改回一个简单的switch，世界清净了。模式是药，不是饭。只有变化频率高、扩展点明确的时候才值得用。
参考架构也是一样。看到别人分享的领域分层、六边形架构、整洁架构时，不要整篇照搬，要理解它到底是为了解决什么组织问题才这么设计的。每个团队的技术水平、部署环境、业务形态不同，适合的架构一定也不同。把参考架构当成启发，而不是标准答案。
5. 踩坑总结：架构设计中最容易翻车的三个地方
5.1 评审变成方案展示会，没人讨论风险
很长一段时间，我们团队的架构评审会都开成了“方案路演”。汇报的人花了大半时间把架构图画得美观，讲的时候也特别有感染力，底下的人不好意思打断，最后稀里糊涂就过了。后来复盘时才意识到，这种评审方式过滤掉了最有价值的信息——风险。
真正有效的架构评审，气氛应该是略带紧张的。评审人的任务不是表扬方案，而是试图证伪它，不断提出边界条件去碰它的假设。比如你选型Redis当分布式锁，我就追问：锁过期了怎么办？主从切换丢数据怎么办？这些问题如果答不上来，恰恰说明方案还没成熟。没有风险的方案通常不是因为它完美，而是因为大家还没有认真找过它的风险。把“评审通过”的标准从“图讲得顺”改成“风险已经被识别且都有预案”之后，我们上线后的故障率下降得非常明显。
5.2 架构只做加法，从不做减法
技术债不只是代码层面的坏味道，它同样存在于架构层面。每接一个新需求，有人就新增一抽象层；为了应对一个偶发场景，就往系统里加一个组件；为了“保险起见”，加一层本该由基础设施解决的限流。组件越来越来多，但每新增一个组件，系统的状态空间和维护成本都在涨。到后期，系统不是复杂到没人看得懂，而是复杂到没人敢动。没有人敢删任何一个环节，因为没人知道还有谁在依赖它。
要让架构保持健康，必须定期做减法清洗。操作上可以分三步：先从流量路径入手，找出线上没有任何请求经过的组件和接口；再用一段时间的可观测数据来验证，确认确实没有调用方；最后才在评审通过后下线。这样做过一轮之后，通常能删掉不少“历史遗留”的中间层，系统的认知负担会明显下降。我自己的感受是，删组件带来的收益往往比重构代码还要大，因为它简化的是整个系统的拓扑结构。
5.3 把原则当成圣旨，忽略了场景和边界
坚持原则是好事，但原则一旦脱离了场景，就会变成官僚主义。我见过团队硬性规定“禁止使用存储过程”，理由是存储过程难维护、难测试。这个约束在OLTP的交易链路上是对的，但它被机械地套到了分析型报表场景里，结果就是几十万行数据被拉到应用内存里做关联过滤，数据库CPU倒是轻松了，应用服务频繁Full GC。
原则需要带上适用边界来理解。“禁止用存储过程”的真实内涵是“不要把复杂业务逻辑藏进数据库里，导致应用层失去对流程的掌控”。在注重计算下推的分析型场景里，把部分聚合逻辑放进数据库反而合理。坚持原则的时候，一定要明白原则也是基于一组假设的产物。当场景与假设不符时，突破原则恰恰是更负责任的做法。
5.4 我每次做架构设计都会留的三个锚点
踩过的坑多了之后，我慢慢固定了一套自己的工作习惯，每次做架构设计都从三个锚点开始。
第一，用一句话写清楚系统最核心的动作。比如“订单系统在用户下单时先预占库存，再异步处理支付结果”，或者“这条数据链路是从车内设备采集数据，经过边缘网关汇聚，再上云分析”。这句话是整个架构的罗盘，后续划分模块、定义接口、规划部署，都要能对得上这句话，对不上的部分就要反复审视是否必要。
第二，维护一张取舍表。表里明确写着当前系统选了哪种简单、付了哪种复杂。比如选单体是简单在运维，复杂在模块边界要靠自觉；选最终一致是简单在性能，复杂在补偿逻辑。这张表放在文档开头，能让所有参与者知道，眼下这种“不完美”是刻意为之。
第三，留一个暂缓决策清单。把那些现在不需要做、但将来可能会遇到的决策写下来，标明触发条件。比如“当订单量达到日均百万级时，需要评估订单表按月分表；当接口平均延迟超过200毫秒时，需要引入缓存分层”。这样架构演进就变成了一条有信号指引的连续路径，而不是某天突然推翻重来的事故。
在写这些内容的时候，我又回想起了那次凌晨两点的问题。这些年我越来越认同一个说法：好的架构不是让你预测未来，而是让你在搞错未来的时候，还有机会低成本修正。所谓设计原则，本质上就是帮你把“改错的代价”控制在一个可接受范围内的护栏。与其背诵各种最佳实践，不如多花时间想清楚，你的架构正在相信哪些假设，以及这些假设哪一天被推翻的时候，系统会发生什么。这大概是我能分享的最重要的一条经验了。