“架构设计到底在干什么”这个问题我从刚转做后端那会儿问到后面带架构组答案是一年比一年具体。早些年我以为架构就是画框图服务怎么拆、模块怎么分、接口怎么定画得好看就算完工。后来亲眼看着一版版系统在需求迭代里腐烂才慢慢意识到架构设计方法的核心不是“画出目标结构”而是“在约束条件下持续做决策并且让这些决策在代码里活下来”。这句话听起来有点绕但真放进项目里就非常实在。这篇内容就是把这些年我用过的架构设计方法、做过的方案评审、踩过的坑以及最近几年大家问得比较多的企业数据架构设计、问数智能体这类新系统的架构思路整理成一份可以直接照着思考的实践指南。适合正在做系统设计的人也适合从业务开发往架构方向转的同学。1. 先摆正一个前提架构设计是天平的决策不是拼图很多人拿到架构设计任务第一反应是找一张参考图照着把各个模块画出来。这种思路在简单系统里能出活但项目一旦超过两个团队维护、超过三个核心业务链路就很难保证每个模块边界是经过权衡的。架构设计的本质是在成本、进度、性能、可维护性之间反复做取舍而不是把功能块放到一张图里排整齐。1.1 每次架构设计都要先回答三个问题我每次接手一个新系统的架构设计都会先逼自己回答三个问题这个系统现在最需要保证的是什么是快速上线、极致性能还是长期可维护我们团队有多少人、多少运维能力、多少预算这三样决定了架构的上限。未来一年内最可能发生的变化是哪一块是数据量翻倍、交互方式变化还是组织架构导致的责任边界变化这三个答案往往是架构决策的锚点。比如一个内部工具系统最需要的是快速交付和维护成本低那你做微服务就是给自己找麻烦反过来一个面向大规模用户的服务如果为了省事做成单体后面每一次发布都可能变成事故。有一个常见的误区是架构师容易先想技术栈再想业务目标。我见过不少团队为了用某个中间件而上中间件理由是“以后一定用得上”。这个话术特别危险因为架构设计的每个组件都应该指向当下的约束和明确的发展路径而不是为想象中的未来买单。1.2 需求清单里我们最容易忽略的两种需求做架构设计时产品需求文档里通常写满了功能需求但架构真正要盯住的是两类容易被忽略的东西第一类是非功能需求比如可用性目标、性能指标、数据保留时长。这些指标如果没有写清楚后面的技术选型就是盲猜。第二类是变化方向也就是业务未来半年到一年内可能存在的新场景。不是要你预测所有需求而是要留出明确的扩展空间哪怕这个空间只是一个抽象接口也比你日后推倒重来便宜得多。我在评审时经常问团队一个问题如果这个系统上线半年后数据量变成十倍你会怎么做很多人被问住然后开始含糊地说“到时候加缓存就行”。这说明需求收集阶段根本没有把数据的量级和增长趋势纳入考虑。架构设计不是算命但至少要把量级、频率、故障容忍度这些边界条件问清楚否则后面所有设计都是空中楼阁。2. 从业务目标到架构约束用三步拆解让需求变成可评估的边界有了正确的认知之后接下来就是动手拆解。这部分很多人会跳过直接进入画模块图结果画出来的图和业务目标没有明确的映射关系。我一般用三个步骤把模糊的业务目标逐步翻译成架构能使用的硬约束。2.1 第一步把业务目标翻译成系统目标业务方说“我们要做一个数据看板”这是一个业务表述。架构设计需要把它翻译成系统目标允许多少数据延迟、支持多少用户同时查看、数据来源有哪些、历史数据要不要保留、保留多久。翻译得越具体后面做技术选型越容易。举一个实际例子。早些年我们做过一个经营分析看板项目业务方最初只说“把各渠道的销售数据汇总展示”。我们并没有急着选型而是先拉数据负责人对齐了几个指标数据每日凌晨更新即可看板并发用户不超过两百人数据源分布在七八个库。基于这些约束我们直接用定时任务加汇总表并没有引入实时计算引擎。如果当时被“实时大屏”这种概念带着走就会白花很多成本。翻译的过程最好有文档记录把业务原话、架构翻译、对应的技术决策写在一起。这样等系统上线后如果有人问“当初为什么用定时任务”你能直接给出当时的业务依据而不是用一句“当时时间紧”搪塞过去。2.2 第二步识别核心场景和峰值场景架构设计不需要覆盖所有场景但必须覆盖核心场景和峰值场景。核心场景决定了常规形态峰值场景决定了弹性边界。比如电商系统“下单”是核心场景双十一的“秒杀”是峰值场景。这两个场景对架构的要求差异巨大核心场景要求的是稳定的事务一致性峰值场景要求的则是流量削峰、降级和快速的横向扩容。如果你设计架构时只盯着常规场景峰值一来就会被打穿如果只盯着峰值场景常规阶段又会过度设计。我在设计系统时通常会让需求方描述三个最典型的用户路径再描述一个最极端的流量时刻。然后针对这两类情况分别给出架构响应。核心场景用常规链路解决峰值场景用预案和开关解决。架构设计里很重要的一件事就是给峰值场景设置“开关”而不是让它常态运行。2.3 第三步把非功能需求量化成可验收指标非功能需求如果只停留在“性能好”“高可用”这种形容词上等于没有需求。我会把它们量化成可验收指标例如用户点击首页后页面直出时间在 1 秒以内核心接口的年可用性达到 99.95%单接口支持每秒 1000 次请求尖峰时允许降级到只读数据同步延迟不超过 15 分钟。量化的意义在于后面做架构评审时你能够用测试结果和数据说话。很多架构方案争论不休本质上是双方对同一个形容词有不同的理解。你说“高可用”他理解成“不能宕机五分钟”你说“实时性”他理解成“毫秒级响应”。实际上不同的量级所需要的架构方案天差地别。先把指标定下来方案之争就变成了成本之争。我还会把这些指标写进技术验收的清单里并且安排压测和故障演练来验证。不要等到线上出问题才后悔当初没把指标定义清楚因为那时已经没有回头路了。3. 候选架构的生成与评估我常用的五维评判清单当架构约束清晰之后就可以开始生成候选方案了。这一环节非常考验经验因为你脑子里积累的架构模式多方案就多。但更重要的是不能上来就凭直觉选一个而是要把候选方案放在同一套评价体系里做比较。3.1 怎么生成候选方案而不是只凭直觉生成候选方案有两个方向。第一个方向是从需求出发自底向上构建先列出必须的组件再把组件之间如何交互画出来。第二个方向是参考同类系统的通用模式比如数据量大的查询类系统通常会引入缓存和索引定时批量处理通常会引入消息队列做削峰。我会给自己定一个规则任何架构设计任务至少给出两套候选方案。哪怕其中一套方案在初始阶段看起来明显不靠谱也要把它列出来并且写下不选它的理由。这样做的价值在于它会逼你承认每一个选择都有代价而不是假装存在完美方案。比如做查询服务候选方案一是直接查数据库加索引候选方案二是引入缓存。方案一简单直接但数据库压力大方案二能扛住更高流量但数据一致性和缓存穿透问题变复杂。如果只写方案一可能永远意识不到方案二在三个月后的流量下会变成一个刚需。但这里也有一条经验候选方案不要贪多两三套足够。超过三套评审会议就会变成辩论赛大家在细节里越陷越深反而忘了最初的目标。3.2 五维评分与权重的实操模板我评审候选方案时会从五个维度去看分别是实现成本、性能与容量、可维护性、可扩展性、风险可控度。五维不一定都重要我会根据系统类型给权重。维度权重参考内部工具型权重参考对外服务型主要观察点实现成本35%15%开发周期、团队熟悉度、基础设施投入性能与容量10%30%延迟指标、吞吐量、水平扩展能力可维护性25%15%监控难度、上线流程、问题排查成本可扩展性15%25%是否支持新业务类型、接口抽象程度风险可控度15%15%关键依赖的稳定性、数据丢失概率、回滚难度这个模板我会随着系统类型调整。内部系统更看重团队能不能低成本维护对外服务更看重容量和扩展性。权重列出来后把每个候选方案逐项打分再乘以权重相加排名通常和直觉判断接近但比直觉多了一套可讨论的依据。实际操作中提示一个坑打分时不要对着理想状态打分要对照团队的真实能力。比如某个中间件很强但团队没人熟悉那“可维护性”这一项的分数就要打低否则方案做出来没人接得住。3.3 用ADR把决策过程固定下来架构决策最怕的是没有记录。等系统上线半年后新来的同事面对一个奇怪的设计会非常困惑然后因为压力不敢改最后系统越来越复杂。解决这个问题我会让团队在每次关键决策时写一份轻量的ADR架构决策记录。一份ADR不需要很长核心是五个部分背景、决策、理由、备选方案、后果。我通常用这样的结构title: 用户数据读取采用缓存方案 context: 用户查询日均百万次数据库读压力大业务对一致性容忍秒级延迟 decision: 引入一层本地缓存加分布式缓存写操作双写并带过期兜底 alternative: 直接加只读从库扩展数据库但成本更高且无法平滑扩展 consequence: 读性能提升显著但存在缓存不一致窗口需要监控命中率和延迟ADR写多了以后你会发现它是很好的团队沟通工具。新人通过读ADR能快速理解当前架构的形成过程而不是把代码翻一遍然后盲人摸象。这也是架构设计方法论里最容易被低估的一环决策记录比系统结构图更有生命力。4. 企业数据架构设计的可落地动作从数据资产目录到血缘治理数据架构一直是企业架构设计里的重头戏。很多公司看到华为企业数据架构设计方法这类材料觉得这套体系很完整轮到自己落地却很迷茫。因为它看起来像一堆概念数据资产目录、数据分布、数据流向、数据生命周期治理不知道从哪里下手。我的经验是数据架构设计的第一步永远不是设计模型而是盘点现状。4.1 先做数据资产盘点再谈模型设计很多数据团队一上来就建数据仓库分层模型做了一堆规范文档结果业务不配合数据还是到处乱放。想避免这个问题就要先花几周时间做数据资产盘点回答三个层面的问题公司现在有哪些核心业务对象比如客户、产品、订单、合同、库存这些对象的数据分别存在哪些系统里谁是源系统谁是下游消费者数据在流转过程中做了哪些加工有没有Excel人工处理环节这份盘点结果就是你做数据架构设计的第一份图纸。它能告诉你哪些数据是核心资产、哪些数据只是中间过程、哪些数据已经重复建设。我见过不少企业同一个“客户余额”字段在五个系统里有五种口径这就是因为从来没有做过资产盘点就直接开始建模。做盘点的时候我建议用一个简单的表格来管理数据域、数据实体、源系统、负责人、更新频率、下游消费者、当前存储位置。表格不要做太复杂但要能持续更新。复杂的关系图可以后续画这个表才是真正支撑后续治理工作的底稿。4.2 数据分布与分层存储的取舍盘完资产之后会面临一个非常实际的问题同一份数据到底该放哪里这就要做两个设计动作一是数据分布设计二是分层存储设计。数据分布设计解决的是“数据从哪里产生、应该到哪里去”的问题。核心原则是单一数据源加上受控复制。单一数据源保证口径统一受控复制满足不同场景的读取需求。比如订单数据只允许交易系统写入但分析系统可以拥有一份同步副本只是这份副本的同步链路和一致性要求需要被明确设计。分层存储设计解决的是成本与性能的平衡。热数据存在高性能存储里温数据放到成本更低的存储冷数据可以归档到对象存储。不要一刀切地把所有历史数据堆在主库里因为大部分冷数据使用的频率极低占据的热存储空间却极贵。我曾见过一个团队为了查询方便把五年历史订单全部放在同一个热库里查询越来越慢扩容越来越贵最后不得不花大力气做归档。数据层级典型数据存储方案查询频率热层近30天订单、实时账户SSD数据库加缓存每秒上千次温层近一年订单明细普通数据库、数据仓库每分钟几十次冷层历史归档、日志备份对象存储、离线数仓偶尔查询或审计4.3 数据血缘与治理不是有了工具就完事数据血缘是这几年企业数据架构里的热词很多平台化工具都能自动解析血缘。但工具解决的是“看见”的问题治理解决的是“谁负责”的问题。很多企业的血缘图很漂亮一问到“这个报表指标如果算错了该找谁”没人能回答。这就是只建血缘没有建立责任机制。一个可落地的做法是给每个核心数据实体指定一个数据OwnerOwner负责定义数据口径、审核变更、响应下游问题。数据血缘图在这个基础上才有意义当字段口径要变更时通过血缘图找出所有下游使用者由数据Owner统一通知和评审。血缘图如果脱离了责任机制就是一个大型观赏品。另外数据质量监控一定要在架构设计环节就规划不要等数据跑起来再补。比如关键表的数据量波动监控、字段空值率监控、同步延迟监控。这些都是很小的动作但能在数据出错的第一时间发出信号比事后返工便宜得多。5. 现在最热的数据智能体从“问数智能体”看AI系统的架构设计最近“问数智能体”这个概念很火很多团队想做那种用户直接对话就能查数的系统。但很多人忽略的是这类系统同样需要架构设计甚至比传统系统更需要分层清晰。因为智能体的行为链路非常长从用户输入到意图理解、到查数工具、到组织答案任何一个环节出问题最后呈现给用户的结果都不会对。5.1 问数智能体的分层架构长什么样我一般把一个问数智能体拆成五层接入层、编排层、模型层、语义层、工具层。接入层负责对话管理和用户上下文编排层决定用户请求如何被拆解和流转模型层承载自然语言理解与生成语义层是账本和指标的抽象描述工具层则连接数据查询能力。其中最容易被人忽略的是语义层和工具层。很多人以为智能体就是“大模型加一个数据库查询API”结果用户问“上个月华东区卖了多少”模型生成了一大段SQL但不知道该查哪张表、字段口径是什么于是出错。语义层的作用就是把这层模糊地带标准化它定义指标的中文名、计算公式、可查询的数据范围让模型通过工具按语义去查数而不是凭空编SQL。这个分层和传统企业数据架构里的指标平台是一脉相承的。你可以先把指标口径管清楚了再去做问数智能体。指标口径没管清楚就上智能体等于给一个病历都乱写的病人做AI问诊结果肯定不靠谱。5.2 决定成败的不是模型而是记忆和工具智能体架构里有一个经常被忽视的点多轮对话中的状态管理。用户问“上个月呢”如果系统不知道“上个月”指代的是哪个查询时间段就回答不了。这种能力来自上下文记忆传统后端开发通常不关心对话状态但智能体架构必须专门设计这个模块。记忆层要分短期短期会话记忆和长期用户画像记忆。短期记忆缓存当前会话的查询意图和参数长期记忆记录用户的常用指标和偏好。这两类记忆的存取策略、失效策略都要留接口。另外工具层的设计也要提前考虑查数工具返回的结果要不要做权限过滤、要不要做数据脱敏这些不是模型能自动完成的而是架构设计阶段必须留出来的控制器。我在实际项目里的做法是先用函数调用的方式把工具层做成标准化接口每一个查数动作都对应一个工具函数函数的参数做严格定义。大模型只负责决定调用哪个函数、填入哪些参数真正的SQL生成和数据访问全部收在工具层内部。这样即使模型给出的参数不对工具层也能校验和拦截不会把错误直接放大到数据层。5.3 智能体架构的评测、降级与安全兜底智能体系统的评测方法和传统系统不太一样。传统系统看接口成功率、延迟和吞吐智能体还要看回答的正确率、拟合用户意图的比例、错误调用工具的次数。这些指标最好在架构里就埋上埋点而不是等用户抱怨了再去找日志。我建议在一开始就给问数智能体设计一套离线评测集收集一百条有标准答案的用户问题每次调整模型或升级工具后用这批问题跑一遍对比答案准确率。有评测集在前模型升级就不会变成碰运气。降级策略同样关键。当模型服务超时怎么办当查数工具暂时不可用怎么办我在设计时会预留一条兜底链路直接在语义层里面做关键词模板匹配如果大模型识别失败就走模板查询返回几条常见结果。这样至少不会让用户在系统异常时彻底拿不到数据。风险点上我最关心的是权限和脱敏。问数智能体本质上是数据查询的前端你让大模型访问数据就等于把数据权限的拦截点延伸到了模型调用上。这个拦截必须在架构层面做硬约束工具层内部强制校验用户权限模型层得到的永远是不带敏感数据的元信息描述。一旦发现查询结果涉及越权数据直接终止返回。6. 让架构设计真正落进代码评审、防腐与演进架构设计做得再漂亮最后都要落到代码仓库里。很多方案评审时所有人都点头结果开发完一看整个结构已经走样了。问题不出在开发身上而是架构设计本身缺少了落地保障机制。6.1 架构评审真正要评的是什么架构评审不是让参会者来听你介绍方案而是要逼你说清“代价和边界”。我每次做评审都会提几个固定问题这个方案在什么情况下会失效哪些组件是我们没法完全掌控的如果核心组件挂了系统降级到什么程度这些问题比“模块怎么划分”更值得花时间讨论。评审现场我会重点关注依赖方向。依赖方向是代码层面架构一致性的核心指标高层模块不能依赖底层模块的具体实现模块之间不能互相绕圈。与其在PPT上讲原则不如直接打开代码里的依赖图红色箭头就是问题本身。依赖关系清晰的系统任何一个人进去修改都敢下手依赖乱掉的系统改哪都怕踩中地雷。6.2 依赖倒置和防腐层两件落地最容易做错的事依赖倒置原则在架构设计里被认为是最基础原则之一但落实时常变形。常见的错误是为了满足依赖倒置先定义了一堆接口结果每个接口只有一个实现还到处依赖。这属于过度设计。正确做法是只在存在多种变化可能的地方抽象接口比如存储可能从MySQL切到PostgreSQL、消息中间件可能替换这些地方值得加抽象。不会变的业务逻辑直接用具体类就行抽象反而增加理解成本。防腐层的场景更实在当你的系统和外部系统对接时不要把外部系统的数据结构直接传进内部业务层。我见过太多团队因为对接了外部接口业务代码里到处出现外部字段名之后对方一改字段这边全线报错。正确做法是在入口处做一次转换把外部数据转换成内部领域模型外部结构的变化被限制在防腐层里面。做这一步要付出额外代码量但长期维护会非常省心。我接手过的老系统凡是外部依赖直接穿透到业务代码的改动成本都高得离谱凡是入口处有统一转换的哪怕外部系统换了一整个技术栈内部也是安静如水。6.3 架构演进预留演进点不要预留万能点架构设计不需要一步到位但一定要知道演进点在哪里。演进点像一个改造接口它告诉后人这个地方将来可能要替换所以这里留了边界。万能点则是另一种东西为了“以后一切都有可能”给每个模块都加上抽象层和配置项最后代码里到处是间接层读起来像是在解迷宫。我对团队反复强调一句话好的架构不预测未来是为未来保留了修改的可能。修改的可能体现为清晰的职责边界、可替换的局部模块、以及写清楚的架构决策记录。而不是靠过度设计把所有未来都实现一遍。实际操作中我每年都会安排一次架构健康度检查把核心模块的依赖图重新生成一遍、盘点每个接口的实现数量、检查各模块的测试覆盖率。这些检查不需要多复杂但能直观地暴露架构是否在腐烂。发现有循环依赖、有大一统的工具类、有外部依赖穿透就列入技术债清单排期逐步清理。架构设计的最后一道防线就是这种“日常维护的纪律”。架构不会因为某一次精彩的设计一劳永逸它更像一棵树需要定期修剪。我这些年最大的体会是真正决定架构质量的往往不是设计文档那张图有多好看而是后面每一次需求变更时团队有没有坚持住当初的边界约定有没有把新的变化放进该放的位置。如果你正在为架构设计头疼不妨先从这三个小动作开始定义好系统目标、把非功能需求量化、为每次决策留一份记录。这三步做完你的架构设计就算没有完美方案也至少走在一条可修正的路上。