我们得先承认一件事架构这个词在程序员圈子里已经被用滥了。我在一家中型互联网公司做过业务系统也带过十来人的研发团队每次坐在架构评审会的桌子前都会有一种很奇妙的抽离感——同一间屋子里的人谈论的其实是完全不同的东西。产品经理听到的是交付时间前端关心的是接口是否好接后端负责人满脑子是容量规划新来的同学则在意这套技术栈够不够新潮。等会议结束大家各自带着自己那个版本的结论离场而系统真正应该长成什么样仍旧是模糊的影子。后来我慢慢想明白了一件事如果能把所有关于架构的讨论翻译成钱——翻译成资源的分配、成本的曲线、收益兑现的时间——大多数争论会在几分钟内变得异常清晰。这也是架构经济学这个视角在我心里逐渐成形的过程。这篇文章不教你怎么画架构图也不鼓吹某种框架只记录我这些年把架构决策当账本来算之后得到的一些反直觉的教训。1. 架构这个词在会议室里至少被三种人说着不同的意思1.1 结构派把架构当成那张图最多人默认的架构定义就是那张方框和箭头组成的图。系统分层、服务拓扑、部署分组、数据流向画在白板或文档里规整、漂亮、一目了然。结构派认为架构的意义就在于可视化——让人一眼看懂系统长什么样。这个视角当然有价值。没有那张图新人入职的认知成本会高得惊人跨团队沟通也会像隔空喊话。但问题在于图只是架构在二维平面上的投影不是架构本身。就像城市地图并不是城市地图上画得再干净也不代表街道上没有堵车、没有积水。我见过不少团队为了保持那张图纯粹而做出荒唐的决策因为图上不应该有反向依赖而强行拆掉一个本可以内部解耦的模块因为这张图要好看而给交互极少的两个服务硬塞一条消息队列。为了投影的整洁牺牲实体的效率——这就是把图和实体混为一谈的代价。1.2 技术派把架构当成用了什么第二种常见的理解是把架构等同于技术栈选型。聊架构就是聊用了多少中间件、多少云服务、某个系统是不是够先进。这类讨论在技术社区里最热闹因为立场鲜明、话题性强谁都能对某个数据库或某个微服务框架发表两句见解。但技术栈只是资产清单不是经营策略。你持有哪些工具和你如何配置资源、如何应对变化、如何承担成本是两回事。我见过一些系统技术栈写出来光鲜亮丽几乎每个组件都是当前最流行的但业务迭代速度照样惨不忍睹——因为组件之间没有形成合力反而给团队增加了巨大的拼接成本。技术先进是手段不是架构本身的价值。1.3 管理派把架构当成谁干什么第三种视角更接近本质架构等于团队的分工边界。哪个小组拥有哪块代码谁对什么服务负责两个团队之间通过什么接口协作——这就是康威定律的现实版组织的沟通结构会镜像到系统的模块结构里。这个视角帮我理解了为什么有些架构改不动不是技术问题而是组织问题。服务归属一旦固化调整架构就等于调整汇报关系动谁都疼。所以架构评审会上真正的焦点往往不是技术选型而是这块以后归谁管。管理派最接近真相但依然只是架构的一个侧面——分工只回答了谁来做没有回答凭什么这么做、成本多少。1.4 经济学视角架构是长期资源的分配方式把前面三种视角合起来我只剩一个结论架构的本质是一组关于长期资源的分配决策。资源永远有限——工程师的工时、注意力、基础设施预算、运营精力以及最稀缺的当下改变方向的机会。架构图里的每一个框、每一条箭头本质上都是对未来劳动力的一笔索取这个组件以后要有人维护这条调用链以后要有人排查这套抽象以后要有人理解。所以当我们谈论架构时我们其实是在谈论谁的时间会被消耗在什么时候消耗换取什么回报这些问题一旦摆上台面架构讨论就从审美之争变成了经济决策而后者是有办法算清楚、有标准评判对错的。2. 把架构决策翻译成成本函数我算过的一笔真实重构账单2.1 打破拆了再说的直觉几年前某公司内部推行全面微服务化规则简单粗暴凡是单块应用都必须拆。我负责的系统是一个运行了三年的交易核心高峰期日请求量已经到了千万级别单库压力确实大。第一版方案写得慷慨激昂按领域拆成八个服务引入服务网格上独立配置中心……评审会上几乎所有人都默认拆分是趋势拆了才有未来。我没有跟着点头而是拉了两个同事花了一个下午把这次迁移的真实成本列成了一张表。那天晚上我把表格投到屏幕上会议室安静了很久。事实是在没有算账之前我们所有人都被趋势这两个字架着走没人认真回答过这笔投资划不划算。2.2 成本科目清单我们当时不只看迁移本身的工时而是把系统拆分后未来两年的持有成本全部折算了一遍成本科目单块架构八个微服务差异说明基础设施1套部署环境网关、注册中心、链路追踪、日志聚合基础设施费用增加20%~30%发布与运维1次构建1次发布多次构建、多次发布、编排协调发布工具链和值班成本明显上升联调与测试进程内调用Mock简单跨服务契约测试、环境隔离每轮迭代联调时间估算增加40%排障看日志定位跨服务链路排查线上问题的平均定位时间从分钟级变成小时级团队认知每个人能看到全部代码每个人只看到局部领域知识的割裂成本难以量化但真实存在再加上迁移期间业务冻结的时间、双轨运行的人力损耗最后算出来一个让我们自己都吃惊的数字未来两年这套系统的总持有成本将比不拆分高出接近一倍而收益——独立扩容和团队自治——只有其中一个模块真正用得上。2.3 两种典型的成本曲线那次之后我养成了一个习惯每聊一个架构方案先画两条成本曲线。第一种曲线是先高后低前期投入大后期边际成本低典型的是花力气做领域建模、自动化测试、基础设施完善的单块应用。第二种曲线是先低后高启动快但每加一个功能都要多付一点协调成本典型的是早期不设边界的快速堆码以及人数扩大后协调爆炸的单块。两种曲线本身没有对错关键看你的业务处在什么位置。团队规模小、业务方向未定选先低后高是理性的系统命脉、团队快速扩张选先高后低有账可算。大多数痛苦的架构都是选错了曲线的形状——或者更糟根本没有意识到自己在选曲线。从那次之后我在每个架构评审会上都会问一句话这个方案的投资回收期是多久还款来源是什么没人能答上来的方案最终基本都成了技术债。3. 复杂度的经济学认知税、维护年金和越滚越大的技术债3.1 复杂度像税收按接触次数征收架构经济学里最容易被忽略的成本是复杂度造成的认知税。每一个额外抽象、每一个配置项、每一条动态规则都不是一次性的——它们会向未来每一个阅读代码、排查问题的工程师征收一小笔税。税基是代码存活的时长和接触代码的人数。一件很有意思的事两套功能完全相同的系统一套用了最潮的分层抽象一套是朴素的分层结构前者的运行性能可能多损耗5%但全周期成本可能高出40%——因为每一届新人接手时都得先花三周理解那套华丽的抽象。很多人只算了机器的性能开销没算人脑的理解开销。人脑理解代码的带宽往往是整个系统里最贵的资源。3.2 好复杂度和坏复杂度按租金分类不过我不是想说复杂就是原罪。有些复杂度是省不掉的一个分布式系统必须处理部分失败、网络分区、最终一致性这些是地租不交就只能住帐篷。另一些复杂度则是自选的奢侈税为了未来某个假设的扩展点而预埋的额外机制为了设计模式而设计模式为了优雅而做的绕路。怎么区分二者我有个简单的测试方法如果这个东西现在马上删掉系统的行为会不会立刻变得不可接受如果删掉后一切照常只是看起来不够精致那它就是奢侈税可以果断砍掉。这个测试我用了很多年误判率很低。3.3 技术债是带复利的贷款还往往没写还款日技术债这个比喻大家都知道但我想说的是它更凶险的一面技术债不是单利是复利。因为人在写新功能时最省力的方式就是模仿现有的模式。一个烂设计会自我复制——一个临时方案里的投机取巧会变成下一个模块的参考实现再变成整个团队默认的写法。我印象最深的例子是一个临时用一下的配置系统。当时约定只放三个开关半年后替换。结果半年后没人记得替换三年后它已经承载了上千个配置项任何人改配置都要提心吊胆因为它有大量没文档化的隐式规则和互相覆盖的顺序逻辑。我们为它翻过的故障比它节省的时间多几十倍。这已经不是利息超过本金了是本金早就亏空利息还在按月计复利。所以我给自己立了一条规矩任何临时方案必须当场写清楚还款日期和替换方案。写在代码注释里还不够要写进团队的迭代看板让它像真实的任务一样被排期。没有还款日期的技术债不叫债叫埋雷。4. 不确定性下的架构投资期权思维、不可逆测试与延迟决策4.1 架构决策的本质是投资而不是考试很多架构讨论之所以变成吵架是因为大家都把它当成一道有标准答案的考题分布式一定比单块好微服务一定比大单体先进事件驱动一定比RPC更优雅。但架构决策的真实面目是投资决策——在信息不完整的情况下用现在的资源换取未来的某种能力而回报是不确定的。既然是投资就会有两种典型的死法。一种是过度投资把架构建得像一座大教堂每一块砖都是为十年后的未来准备的结果业务两年就要转向教堂还没完工就成了文物。另一种是投资不足系统搭得像违章建筑每次变化都要拆东墙补西墙积累到临界点之后一次小改动就能引发连锁事故。正确的姿势不是选最好的架构而是回答一个问题以现在掌握的信息值的做这个决定吗如果把问题从哪种方案更优秀换成现在是否到了必须决定的时刻一半的架构争论会自动消失。4.2 用不可逆测试给决策分级我处理架构决策的一个核心工具是给决策按不可逆程度分级。可逆的决策不妨做得快、做得糙、做得便宜不可逆的决策才值得花重金买信息、买时间。决策类型示例应对策略容易可逆缓存策略、路由规则、功能开关快速决策随时调整别在可逆的事情上内耗中等可逆模块拆分粒度、接口设计拆成一个能随时合并的最小单元保留变更空间很难可逆数据模型、核心事务边界、团队归属放慢做兼容层为以后再选保留机会这个分级表救过我很多次。以前我总把所有决策都当成终身大事连缓存换不换都要讨论两周。后来发现这种严谨用错了地方——可逆的事情等不起不可逆的事情急不得。把精力从什么都想选对变成该快的快该慢的慢整个团队的决策效率会立刻上一个台阶。4.3 期权思维为选择权付费但要确认底层资产存在好架构的另一个价值是提供选择权以后能拆、能扩、能换、能改。但选择权是有价格的而且价格要先于收益支付。买选择权的原则是确认底层资产真实存在否则就是买空气。这就是架构宇航员的典型症状——为一个从未发来信号的未来做周密设计假设十年后会有千万级并发所以今天就要上最复杂的集群假设将来一定会做某个功能所以现在就要预留一堆用不到的扩展点。这些假设如果没有任何业务信号支撑花出去的每一分复杂度的钱都是在买一个没有标的物的期权。真正值得买的选择权通常是有现实锚点的某一模块的团队正在扩张拆分选项就有价值新的合规要求让数据边界存在临近的变化隔离能力就值得投资。我挑选架构方案的标准里这个选择权未来会不会被行使和现在这个期权贵不贵同样重要。4.4 延迟决策不是不决策而是主动设计暂缓区最后要澄清一个误解延迟决策不等于拖延症。真正的延迟决策是要通过主动设计把那些不可逆的、信息不足的部分隔离起来让它们暂时不影响主线。具体做法包括不确定的第三方依赖全部藏在接口后面不确定的业务规则用开关包裹不确定的数据模型先做最小约定暴露尽量少的字段。这套做法的前期成本并不低但它换来的东西很珍贵——在信息系统尚不明朗的那段时间里整个团队不用反复推翻重量级决策。我做过一个项目核心争议集中在要不要上分布式事务。各方吵了两周没有共识。最后我们采用的方案是先规定哪些场景绝不允许跨服务事务其余未知场景一律走异步补偿路径把分布式事务这个决策彻底推迟。三个月后业务方向调整了当初买了分布式事务的假设根本不成立我们等于用很小的隔离成本替团队省掉了一次方向性返工。5. 白话版鸣谦架构宣言五条原则与一个核心问题5.1 五条原则系统性的思考整理下来我愿意以鸣谦的名义认领下面五条原则。它们不新但每一条都是我拿真金白银的工时验证过的。第一架构首先是预算然后才是蓝图。任何架构图都应该有一张对应的成本表逐项列出它的持有成本、隐性开销和回收周期。没有成本表的架构图价值要打个对折。第二没有免费的复杂度。每个抽象都必须交租——交租的对象是未来所有要读懂它的人。如果一个抽象说不清自己换来的是什么它大概率只是在收税。第三好的架构是这个季度能自信交付两年内不被它折磨的架构。这两个目标冲突时优先保证两到三年内的可持续演进能力。十年后的完美不值得用明天的停滞来换。第四说不清经济逻辑的方案说明你还没理解自己的架构。架构评审会上最该被反复追问的不是哪个更先进而是成本和收益分别是什么谁在承担何时兑现。第五为你实际拥有的团队设计而不是为理想中的团队设计。康威定律是一个经济定律沟通成本是真实存在的预算项忽略它的架构设计最后一定会由加班来买单。5.2 那一个核心问题把这些原则收拢成一个问题就是这篇文章标题的答案当我们谈论架构时我们谈论的其实是——我们愿意为那个也许会发生的未来付出多少今天的代价以及这笔代价由谁来付。过去我会为谁用哪个框架、谁的方案更优雅争到面红耳赤。现在我更愿意把讨论挪到成本表上对着数字说话。数字不会照顾情绪但数字能让我们从品味之争走进工程谈判而后者才是一个团队真正成熟的表现。最后分享一个小习惯我会为每个重要系统维护一份架构账本里面记录每一项被接受的架构决策——当时的预期收益、预估成本、回收期以及半年后复核的实际数字。起初我的预测错得离谱但两轮复盘之后我对一个设计到底贵不贵的判断准确度高了很多。这套账本不需要什么工具一个共享文档就够。架构经济学不是一门高深的理论它只是要求你对自己和团队的时间诚实一点。