做架构评审这些年我见过太多画了等于没画的架构图。最常见的一幕是一个团队花了三天时间用专业工具画出一张密密麻麻的框图箭头横飞、色块堆叠投到大屏上之后业务方看不懂开发觉得没信息量运维看了直摇头。问题不在于画得丑而在于画之前没想清楚一件事——这张图到底是给谁看的要回答什么问题。软件架构图不是艺术品也不是文档装饰。它本质上是一种沟通工具而沟通对象决定了图的类型、粒度和表达方式。业务架构图、应用架构图、技术架构图、数据架构图这四类图恰好对应四类不同的沟通场景和四类不同的读者。把这四类图混为一谈或者只画其中一张就宣称架构图已完成是绝大多数架构文档失效的根源。这篇内容适合正在做系统设计、准备架构评审、或者需要向不同角色解释系统全貌的从业者。不管你是刚接手一个新项目的开发还是需要向管理层汇报系统现状的技术负责人下面这套四类图的拆解方法和实操细节都能直接拿去用。我会把每类图的核心目的、画法要点、常见错误和实操心得讲透重点放在为什么这样画而不是用什么工具画。1. 先搞清楚四类图各自回答什么问题很多人画架构图的第一步是打开绘图工具这是本末倒置。正确的第一步是问自己这张图要回答谁的什么问题四类架构图之所以要分开画根本原因是它们服务的读者和回答的问题完全不同。把这个问题想清楚后面用什么图形、什么颜色、什么粒度都是自然推导出来的结果。1.1 业务架构图回答系统支撑了哪些业务能力业务架构图的读者是业务方、产品经理和管理层。他们不关心用了什么数据库、部署在几台机器上他们关心的是这个系统到底覆盖了哪些业务环节各环节之间是什么关系哪些能力已经具备、哪些还缺失。所以业务架构图的核心元素是业务能力和业务流程而不是技术组件。画的时候应该用业务语言命名比如订单履约会员权益结算对账而不是OrderServiceMemberController。我见过不少团队把业务架构图画成了应用架构图满屏都是服务名和接口名业务方看完一脸茫然这张图就失去了存在的意义。一个实用的判断标准如果这张图拿给一个完全不懂技术的业务负责人看他能不能在五分钟内指出我们这块业务在系统里对应哪一块能就是合格的业务架构图不能就是画错了。1.2 应用架构图回答系统由哪些应用/服务组成如何协作应用架构图的读者是开发人员、架构师和技术管理者。它要回答的是系统被拆分成了哪些应用或服务每个应用的职责边界是什么它们之间通过什么方式交互。这里的核心是职责划分和交互关系。一张好的应用架构图应该能让人一眼看出某个功能应该落在哪个应用里以及改动一个应用会影响哪些上下游。它关注的是分而治之的边界而不是部署细节。应用架构图最容易犯的错误是粒度失控。要么拆得太细几十个服务挤在一张图上连线像蜘蛛网要么太粗一个大方块写着业务系统等于什么都没说。合理的做法是按业务域或限界上下文来组织一张图控制在十几个核心应用以内细节用分层或分图展开。1.3 技术架构图回答系统跑在什么技术底座上技术架构图的读者是运维、基础设施团队和技术负责人。它关注的是部署形态、网络分区、中间件选型、高可用和容灾策略这些运行时层面的东西。技术架构图的核心元素是部署单元、网络区域、中间件和基础设施。它要能回答应用部署在几个区域数据库是主从还是集群缓存和消息队列放在哪一层外部依赖有哪些故障时如何降级。这类图最忌讳的是把业务逻辑画进去。技术架构图应该只关心东西跑在哪、怎么连、怎么保障一旦开始画业务流程就说明画串了。我通常建议技术架构图单独成册和业务、应用图分开维护因为它的变更频率和变更原因跟另外几类图完全不同。1.4 数据架构图回答数据从哪来、到哪去、怎么存数据架构图的读者是数据工程师、后端开发和数据分析人员。它关注的是数据的产生、流转、存储和消费全链路包括核心数据实体、数据流向、存储选型和数据治理策略。核心元素是数据实体、数据流、存储介质和数据生命周期。一张合格的数据架构图要能说清楚核心业务数据有哪些它们在各系统之间怎么流转哪些是主数据、哪些是派生数据数据在哪里落地、保留多久。数据架构图常被忽略很多团队画完前三类图就收工了结果数据口径混乱、重复建设严重。实际上数据架构图对于排查这个字段到底以哪个系统为准这类问题价值极高。为了更直观地对比四类图的差异我把关键维度整理成下表维度业务架构图应用架构图技术架构图数据架构图核心读者业务方、管理层开发、架构师运维、基础设施数据、后端开发回答的问题支撑哪些业务能力由哪些应用组成跑在什么底座上数据如何流转存储核心元素业务能力、流程应用、服务、接口部署单元、中间件数据实体、数据流命名语言业务术语服务/模块名技术组件名数据实体名变更频率低中中高中常见错误画成技术图粒度失控混入业务逻辑被整体忽略这张表建议贴在团队文档的显眼位置每次画图前对照一下能避免大部分画错类型的问题。2. 业务架构图用业务语言把能力边界画清楚业务架构图是四类图里最容易被轻视、也最难画好的一类。难在它要求画图的人既懂业务又懂系统还要能把两者对应起来。很多技术出身的人画业务架构图画着画着就滑向了技术细节这是通病。2.1 从业务流程梳理开始而不是从系统模块开始画业务架构图的第一步不是打开工具而是拿一张白纸把业务流程从头到尾走一遍。比如一个电商履约场景从用户下单、支付、库存锁定、拣货、发货到签收每个环节涉及哪些业务动作这些动作由哪些业务能力支撑。这个梳理过程建议用业务能力地图的方式组织把业务按域—能力—子能力三层拆解。以交易域为例下面可以拆出下单能力、支付能力、优惠计算能力下单能力再往下拆出购物车、订单创建、订单查询等子能力。这样拆出来的结构天然就是业务架构图的骨架。我个人的经验是梳理阶段先不要考虑系统怎么实现纯粹从业务视角出发。等能力地图画完了再逐项标注已实现/部分实现/未实现以及由哪个系统承载。这个先业务后系统的顺序非常关键反过来做的话很容易被现有系统的结构绑架画出来的图只是现有系统的翻版失去了业务视角的价值。2.2 分层表达能力层、流程层、角色层怎么摆一张完整的业务架构图通常包含三个层次的信息业务能力系统能做什么、业务流程这些能力如何串起来完成一件事、参与角色谁在使用这些能力。常见的摆法是横向分层最上面是角色层标注用户、运营、客服等角色中间是流程层用箭头串起端到端的业务流程下面是能力层用方块列出支撑流程的各项业务能力。这种角色—流程—能力的三层结构业务方看起来非常直观能快速定位自己关心的部分。也有团队喜欢用业务域矩阵的摆法把能力按业务域分组成网格每个格子是一个能力用颜色标注成熟度。这种摆法适合做能力盘点和规划但不太适合讲流程。具体用哪种取决于这张图的主要用途——是讲清楚业务怎么跑还是讲清楚能力有哪些。两者可以画成两张图不必强塞进一张。2.3 业务架构图里不该出现的东西这一条值得单独拎出来说因为踩坑的人太多了。业务架构图里不应该出现具体的技术组件名如某消息队列、某缓存、接口路径、数据库表名、部署节点、代码层面的模块划分。判断方法很简单图上的每一个名词业务方能不能听懂。如果出现RedisKafka微服务这类词基本可以判定这张图已经跑偏了。业务架构图的价值在于让非技术角色理解系统一旦混入技术黑话这个价值就打了折扣。还有一个隐蔽的错误是用系统名代替业务能力名。比如图上写订单系统库存系统这其实是应用架构的表达。业务架构图应该写订单管理能力库存管理能力强调的是能力而非载体。这个区别看似细微但它决定了这张图是站在业务视角还是系统视角。提示画完业务架构图后找一个不懂技术的业务同事做五分钟测试——让他指出自己负责的业务在图上哪个位置。指不出来说明图的语言还不够业务化。3. 应用架构图把服务边界和依赖关系画明白应用架构图是技术团队日常用得最多的一类图也是争议最多的一类。争议的核心永远是粒度到底拆到多细才算合适我的答案是粒度服务于目的——这张图要用来做什么决策就拆到什么程度。3.1 按业务域组织而不是按技术分层组织很多团队画应用架构图习惯用表现层—业务层—数据层的技术分层结构这种画法在单体应用时代很常见但在服务化架构下已经不太适用了。技术分层图看不出业务边界也无法回答改这个功能会影响谁。更实用的组织方式是按业务域分组把应用按所属业务域聚成几个大块每个大块内部列出该域下的核心应用或服务块与块之间画上主要的交互关系。这样画出来的图业务边界一目了然也方便做领域划分的讨论。比如一个交易平台可以分成用户域、商品域、交易域、履约域、结算域几大块每块下面挂几个核心服务。域内的高频交互用细线表示跨域的关键调用用粗线或不同颜色标注。这种域分组关键连线的画法信息密度适中既不会太乱也不会太空。3.2 交互关系怎么标同步、异步、强弱依赖要区分应用架构图里最容易糊弄的就是连线。很多图上一根箭头了事看不出是同步调用还是异步消息是强依赖还是弱依赖。这些信息恰恰是排查故障、评估影响时最需要的。我的做法是给连线加两类标注交互方式同步/异步和依赖强度强/弱。同步强依赖用实线粗箭头异步弱依赖用虚线细箭头一眼就能区分。如果图面允许还可以在连线上标注交互的用途比如下单校验库存支付成功通知。这样画的好处在实际排障时特别明显。某次线上库存服务抖动值班同学打开应用架构图顺着指向库存服务的实线粗箭头五分钟内就圈定了受影响的调用方比翻代码快得多。这就是架构图有用和没用的区别——有用的图能在关键时刻回答问题。3.3 一张图讲不完就分层别硬塞当系统规模上去之后想用一张应用架构图讲清楚所有服务几乎不可能。这时候正确的做法是分层出图一张总览图只画业务域和域间关系每个域再单独出一张详细图画到具体服务和接口。总览图控制在十个左右的域块详细图控制在每个域十几个服务以内。这种总览分域的两级结构既保证了全局视角又保留了细节深度。我见过一些团队非要在一张图上画上百个服务结果图打印出来有半面墙那么大实际没人看纯属自我感动。分层出图还有个额外好处不同读者可以各取所需。管理层看总览图开发看自己所在域的详细图跨域协作时两张图对照着看。图的维护成本也降低了某个域内部调整只需要更新该域的详细图总览图往往不受影响。4. 技术架构图部署形态和保障策略才是重点技术架构图经常被画成应用架构图的部署版这是个误解。技术架构图的核心不是重复应用之间的关系而是讲清楚运行时环境东西部署在哪、网络怎么分区、中间件怎么选型、故障怎么兜底。4.1 网络分区和部署单元是骨架一张技术架构图第一眼应该能看到网络分区。典型的分区包括接入区、应用区、数据区、管理区不同区域之间用防火墙或网关隔开。每个分区里放对应的部署单元接入区放负载均衡和网关应用区放应用集群数据区放数据库和缓存集群。把分区画清楚的价值在于它能直观地回答安全边界和故障隔离的问题。比如数据库能不能被外网直接访问这种问题看一眼分区图就有答案。很多安全评审和等保检查第一件事就是看这张分区图。部署单元的画法建议标注实例数量和部署形态比如应用集群3节点数据库主从1主2从。这些信息对于容量评估和故障演练非常有用比单纯画个方块写应用服务器信息量大得多。4.2 中间件和高可用策略要显式标注技术架构图里中间件不能只画个图标了事要标注选型和高可用方式。比如消息队列是单集群还是多集群缓存是主从还是集群模式数据库的读写分离和故障切换是怎么做的。这些信息平时看着琐碎真出故障时就是救命稻草。我经历过一次缓存集群部分节点故障值班同学因为架构图上明确标注了缓存集群模式单节点故障自动摘除很快就判断出影响范围可控没有盲目扩容。反过来如果图上只画了个缓存图标就得临时去查配置耽误时间。高可用策略还应该包括降级和限流的标注。哪些依赖挂了可以降级降级后的表现是什么限流阈值大概在什么量级。这些内容画在图上等于把应急预案可视化了一部分。4.3 外部依赖单独成块别和应用混在一起系统依赖的外部服务第三方支付、短信、地图等建议在技术架构图上单独成块用不同颜色或虚线框标出并标注依赖方式和超时策略。这样做的原因是外部依赖往往是故障的高发区而且不受自己控制需要特别关注。单独成块之后哪些外部依赖是强依赖、哪些可以降级这个问题就变得一目了然。评审时也方便追问这个外部依赖的超时设了多久重试策略是什么对方挂了我们的表现是什么。这些问题在图上有了落脚点讨论就不会飘。5. 数据架构图把数据流转和口径统一画出来数据架构图是四类图里最容易被跳过的一类但它解决的问题恰恰是最让人头疼的数据口径不一致、重复建设、来源不清。一张好的数据架构图能让这个数到底以谁为准这类争论少一大半。5.1 核心数据实体先盘点再画流转画数据架构图的第一步是盘点核心数据实体。什么是核心实体就是那些跨多个系统使用、有明确业务含义的数据对象比如用户、商品、订单、账户。把这些实体列出来标注每个实体的权威来源系统也就是常说的主数据源这一步就把数据口径的基准定下来了。盘点完之后再画流转每个实体从产生到消费经过哪些系统在每个系统里是存储还是只读引用是原样传递还是加工派生。用箭头表示流转方向用不同线型区分写入和读取用标注说明加工逻辑。这个画法能暴露很多隐藏问题。比如经常发现同一个实体在两个系统里都有写入权限这就是口径冲突的隐患或者发现某个派生数据被下游当成了权威数据使用一旦上游加工逻辑变化就会出问题。这些问题不画图很难系统性发现。5.2 存储选型和数据生命周期要标清楚数据架构图上每个核心实体要标注存储介质和保留策略。存储介质包括关系库、缓存、对象存储、搜索引擎等保留策略包括在线保留多久、归档到哪里、是否脱敏。这些信息对于数据治理和成本优化都很关键。我见过一个系统日志类数据在在线库里堆了两年没清理存储成本高得离谱问题就在于从来没人从数据生命周期的角度审视过。画数据架构图时把保留策略标上这类问题就会浮出水面。5.3 数据流和业务流要能对上数据架构图和应用架构图之间要能互相印证应用架构图上的每次服务调用如果涉及数据写入应该在数据架构图上有对应的数据流。两张图对不上往往意味着有隐藏的数据写入路径或者有没被识别的数据依赖。我习惯在评审时把两张图并排看逐条核对关键数据流。这个过程经常能发现一些野生的数据写入——比如某个服务绕过主数据源直接写库或者某个定时任务在偷偷同步数据。这些路径平时藏在代码里只有画图对照才能揪出来。6. 四类图怎么协同维护避免画完就过期架构图最大的敌人不是画得不好而是画完就没人管半年后彻底过期。四类图要真正发挥作用必须解决维护问题。我的经验是维护机制比画图技巧更重要。6.1 建立变更触发更新的轻量机制不要指望定期大扫除式的更新那种方式坚持不了两个月。更现实的做法是变更触发当发生特定类型的变更时强制更新对应的图。比如新增一个外部依赖必须更新技术架构图新增一个核心数据实体必须更新数据架构图应用拆分或合并必须更新应用架构图。把这条规则写进团队的变更流程里作为提交评审的一项检查项。刚开始可能会觉得麻烦但坚持下来之后图的时效性会好很多。关键是触发条件要少而明确不要搞成任何变更都要更新所有图那样没人执行得下去。6.2 图要有明确的负责人和版本每张架构图都应该有明确的负责人和版本记录。负责人不一定是画图的人但要对这张图的准确性负责。版本记录至少包括修改时间、修改内容和修改原因。这个要求看似形式主义实际作用很大。当两个人对系统理解不一致时翻出图的版本记录往往能定位到分歧是从哪次变更开始的。而且有了负责人图的质量就有了兜底不会出现人人都能改、人人都不负责的局面。6.3 图和文档、代码的三角校验架构图不能孤立存在它要和设计文档、代码结构形成互相校验的关系。评审时可以做这样的检查图上画的每个应用代码仓库里能不能找到对应模块图上标的每个外部依赖配置文件里能不能找到对应配置图上画的每条关键数据流代码里能不能找到对应的写入逻辑。这个三角校验听起来繁琐但它是保证架构图说真话的最有效手段。我见过太多图上一套、代码一套的情况根源就是画完之后再没和实际实现对过账。定期做一次抽样校验图的可信度就能维持住。7. 几个反复踩过的坑和对应的处理办法最后分享几个我在实际项目中反复遇到的问题都是些文档里不会写、但实际画图时一定会碰到的细节。7.1 工具选型别纠结能协作、能版本管理最重要关于用什么工具画架构图我的观点很明确工具不重要协作和版本管理才重要。文本化的绘图方式用代码描述图形在版本管理上有天然优势每次修改都能 diff适合纳入代码仓库一起管理。图形化工具上手快适合快速沟通但版本管理往往较弱。实际项目中我通常两种都用需要频繁评审和长期维护的核心架构图用文本化方式画纳入版本管理临时沟通用的草图用图形工具快速画。不要在一开始就追求统一工具那往往是形式大于内容。7.2 颜色和图例要克制别让图变成调色盘架构图用色要克制一般不超过四到五种颜色而且每种颜色要有明确含义并在图例里说明。常见的问题是颜色用得太随意同一个颜色在不同图里含义不同读者每次都要重新猜。我的习惯是固定一套配色语义比如蓝色表示核心应用灰色表示外部依赖绿色表示数据存储橙色表示需要关注的风险点。这套语义在团队内统一所有架构图都遵循读者看多了自然形成条件反射读图效率会高很多。7.3 评审时先讲这张图回答什么问题再讲细节架构评审时很多人一上来就讲细节听众还没建立全局认知很容易迷失。正确的顺序是先花一分钟说明这张图回答什么问题、读者是谁再展开细节。这个开场看似简单但能极大提升评审效率。我通常会在图的一角放一行小字写明本图回答系统由哪些应用组成及主要交互关系读者开发与架构评审。这行字不起眼但它时刻提醒画图的人和看图的人这张图的边界在哪里避免跑题。7.4 别追求一张图包打天下该拆就拆最后一个坑是一张图情结——总想用一张图把所有信息都装进去。结果是图越来越复杂信息密度越来越高可读性越来越差。架构图的本质是沟通沟通就要考虑读者的认知负荷。一张图讲清楚一件事比一张图讲十件事但没人看得懂价值高得多。四类图分开画本身就是对一张图情结的纠正。业务、应用、技术、数据各司其职每张图只回答自己该回答的问题读者按需取用。这个思路坚持下来架构文档体系会清爽很多也更容易维护。我在实际使用中最大的体会是架构图的价值不在于画得多漂亮而在于它能不能在关键时刻被拿出来、被看懂、被用来做决策。四类图各画各的、各管各的看似增加了工作量实际上是把沟通成本前置了长期看反而省事。每次画图前多问一句这张图给谁看、回答什么问题比任何绘图技巧都管用。
做架构评审这些年我见过太多画了等于没画的架构图。最常见的一幕是一个团队花了三天时间用专业工具画出一张密密麻麻的框图箭头横飞、色块堆叠投到大屏上之后业务方看不懂开发觉得没信息量运维看了直摇头。问题不在于画得丑而在于画之前没想清楚一件事——这张图到底是给谁看的要回答什么问题。软件架构图不是艺术品也不是文档装饰。它本质上是一种沟通工具而沟通对象决定了图的类型、粒度和表达方式。业务架构图、应用架构图、技术架构图、数据架构图这四类图恰好对应四类不同的沟通场景和四类不同的读者。把这四类图混为一谈或者只画其中一张就宣称架构图已完成是绝大多数架构文档失效的根源。这篇内容适合正在做系统设计、准备架构评审、或者需要向不同角色解释系统全貌的从业者。不管你是刚接手一个新项目的开发还是需要向管理层汇报系统现状的技术负责人下面这套四类图的拆解方法和实操细节都能直接拿去用。我会把每类图的核心目的、画法要点、常见错误和实操心得讲透重点放在为什么这样画而不是用什么工具画。1. 先搞清楚四类图各自回答什么问题很多人画架构图的第一步是打开绘图工具这是本末倒置。正确的第一步是问自己这张图要回答谁的什么问题四类架构图之所以要分开画根本原因是它们服务的读者和回答的问题完全不同。把这个问题想清楚后面用什么图形、什么颜色、什么粒度都是自然推导出来的结果。1.1 业务架构图回答系统支撑了哪些业务能力业务架构图的读者是业务方、产品经理和管理层。他们不关心用了什么数据库、部署在几台机器上他们关心的是这个系统到底覆盖了哪些业务环节各环节之间是什么关系哪些能力已经具备、哪些还缺失。所以业务架构图的核心元素是业务能力和业务流程而不是技术组件。画的时候应该用业务语言命名比如订单履约会员权益结算对账而不是OrderServiceMemberController。我见过不少团队把业务架构图画成了应用架构图满屏都是服务名和接口名业务方看完一脸茫然这张图就失去了存在的意义。一个实用的判断标准如果这张图拿给一个完全不懂技术的业务负责人看他能不能在五分钟内指出我们这块业务在系统里对应哪一块能就是合格的业务架构图不能就是画错了。1.2 应用架构图回答系统由哪些应用/服务组成如何协作应用架构图的读者是开发人员、架构师和技术管理者。它要回答的是系统被拆分成了哪些应用或服务每个应用的职责边界是什么它们之间通过什么方式交互。这里的核心是职责划分和交互关系。一张好的应用架构图应该能让人一眼看出某个功能应该落在哪个应用里以及改动一个应用会影响哪些上下游。它关注的是分而治之的边界而不是部署细节。应用架构图最容易犯的错误是粒度失控。要么拆得太细几十个服务挤在一张图上连线像蜘蛛网要么太粗一个大方块写着业务系统等于什么都没说。合理的做法是按业务域或限界上下文来组织一张图控制在十几个核心应用以内细节用分层或分图展开。1.3 技术架构图回答系统跑在什么技术底座上技术架构图的读者是运维、基础设施团队和技术负责人。它关注的是部署形态、网络分区、中间件选型、高可用和容灾策略这些运行时层面的东西。技术架构图的核心元素是部署单元、网络区域、中间件和基础设施。它要能回答应用部署在几个区域数据库是主从还是集群缓存和消息队列放在哪一层外部依赖有哪些故障时如何降级。这类图最忌讳的是把业务逻辑画进去。技术架构图应该只关心东西跑在哪、怎么连、怎么保障一旦开始画业务流程就说明画串了。我通常建议技术架构图单独成册和业务、应用图分开维护因为它的变更频率和变更原因跟另外几类图完全不同。1.4 数据架构图回答数据从哪来、到哪去、怎么存数据架构图的读者是数据工程师、后端开发和数据分析人员。它关注的是数据的产生、流转、存储和消费全链路包括核心数据实体、数据流向、存储选型和数据治理策略。核心元素是数据实体、数据流、存储介质和数据生命周期。一张合格的数据架构图要能说清楚核心业务数据有哪些它们在各系统之间怎么流转哪些是主数据、哪些是派生数据数据在哪里落地、保留多久。数据架构图常被忽略很多团队画完前三类图就收工了结果数据口径混乱、重复建设严重。实际上数据架构图对于排查这个字段到底以哪个系统为准这类问题价值极高。为了更直观地对比四类图的差异我把关键维度整理成下表维度业务架构图应用架构图技术架构图数据架构图核心读者业务方、管理层开发、架构师运维、基础设施数据、后端开发回答的问题支撑哪些业务能力由哪些应用组成跑在什么底座上数据如何流转存储核心元素业务能力、流程应用、服务、接口部署单元、中间件数据实体、数据流命名语言业务术语服务/模块名技术组件名数据实体名变更频率低中中高中常见错误画成技术图粒度失控混入业务逻辑被整体忽略这张表建议贴在团队文档的显眼位置每次画图前对照一下能避免大部分画错类型的问题。2. 业务架构图用业务语言把能力边界画清楚业务架构图是四类图里最容易被轻视、也最难画好的一类。难在它要求画图的人既懂业务又懂系统还要能把两者对应起来。很多技术出身的人画业务架构图画着画着就滑向了技术细节这是通病。2.1 从业务流程梳理开始而不是从系统模块开始画业务架构图的第一步不是打开工具而是拿一张白纸把业务流程从头到尾走一遍。比如一个电商履约场景从用户下单、支付、库存锁定、拣货、发货到签收每个环节涉及哪些业务动作这些动作由哪些业务能力支撑。这个梳理过程建议用业务能力地图的方式组织把业务按域—能力—子能力三层拆解。以交易域为例下面可以拆出下单能力、支付能力、优惠计算能力下单能力再往下拆出购物车、订单创建、订单查询等子能力。这样拆出来的结构天然就是业务架构图的骨架。我个人的经验是梳理阶段先不要考虑系统怎么实现纯粹从业务视角出发。等能力地图画完了再逐项标注已实现/部分实现/未实现以及由哪个系统承载。这个先业务后系统的顺序非常关键反过来做的话很容易被现有系统的结构绑架画出来的图只是现有系统的翻版失去了业务视角的价值。2.2 分层表达能力层、流程层、角色层怎么摆一张完整的业务架构图通常包含三个层次的信息业务能力系统能做什么、业务流程这些能力如何串起来完成一件事、参与角色谁在使用这些能力。常见的摆法是横向分层最上面是角色层标注用户、运营、客服等角色中间是流程层用箭头串起端到端的业务流程下面是能力层用方块列出支撑流程的各项业务能力。这种角色—流程—能力的三层结构业务方看起来非常直观能快速定位自己关心的部分。也有团队喜欢用业务域矩阵的摆法把能力按业务域分组成网格每个格子是一个能力用颜色标注成熟度。这种摆法适合做能力盘点和规划但不太适合讲流程。具体用哪种取决于这张图的主要用途——是讲清楚业务怎么跑还是讲清楚能力有哪些。两者可以画成两张图不必强塞进一张。2.3 业务架构图里不该出现的东西这一条值得单独拎出来说因为踩坑的人太多了。业务架构图里不应该出现具体的技术组件名如某消息队列、某缓存、接口路径、数据库表名、部署节点、代码层面的模块划分。判断方法很简单图上的每一个名词业务方能不能听懂。如果出现RedisKafka微服务这类词基本可以判定这张图已经跑偏了。业务架构图的价值在于让非技术角色理解系统一旦混入技术黑话这个价值就打了折扣。还有一个隐蔽的错误是用系统名代替业务能力名。比如图上写订单系统库存系统这其实是应用架构的表达。业务架构图应该写订单管理能力库存管理能力强调的是能力而非载体。这个区别看似细微但它决定了这张图是站在业务视角还是系统视角。提示画完业务架构图后找一个不懂技术的业务同事做五分钟测试——让他指出自己负责的业务在图上哪个位置。指不出来说明图的语言还不够业务化。3. 应用架构图把服务边界和依赖关系画明白应用架构图是技术团队日常用得最多的一类图也是争议最多的一类。争议的核心永远是粒度到底拆到多细才算合适我的答案是粒度服务于目的——这张图要用来做什么决策就拆到什么程度。3.1 按业务域组织而不是按技术分层组织很多团队画应用架构图习惯用表现层—业务层—数据层的技术分层结构这种画法在单体应用时代很常见但在服务化架构下已经不太适用了。技术分层图看不出业务边界也无法回答改这个功能会影响谁。更实用的组织方式是按业务域分组把应用按所属业务域聚成几个大块每个大块内部列出该域下的核心应用或服务块与块之间画上主要的交互关系。这样画出来的图业务边界一目了然也方便做领域划分的讨论。比如一个交易平台可以分成用户域、商品域、交易域、履约域、结算域几大块每块下面挂几个核心服务。域内的高频交互用细线表示跨域的关键调用用粗线或不同颜色标注。这种域分组关键连线的画法信息密度适中既不会太乱也不会太空。3.2 交互关系怎么标同步、异步、强弱依赖要区分应用架构图里最容易糊弄的就是连线。很多图上一根箭头了事看不出是同步调用还是异步消息是强依赖还是弱依赖。这些信息恰恰是排查故障、评估影响时最需要的。我的做法是给连线加两类标注交互方式同步/异步和依赖强度强/弱。同步强依赖用实线粗箭头异步弱依赖用虚线细箭头一眼就能区分。如果图面允许还可以在连线上标注交互的用途比如下单校验库存支付成功通知。这样画的好处在实际排障时特别明显。某次线上库存服务抖动值班同学打开应用架构图顺着指向库存服务的实线粗箭头五分钟内就圈定了受影响的调用方比翻代码快得多。这就是架构图有用和没用的区别——有用的图能在关键时刻回答问题。3.3 一张图讲不完就分层别硬塞当系统规模上去之后想用一张应用架构图讲清楚所有服务几乎不可能。这时候正确的做法是分层出图一张总览图只画业务域和域间关系每个域再单独出一张详细图画到具体服务和接口。总览图控制在十个左右的域块详细图控制在每个域十几个服务以内。这种总览分域的两级结构既保证了全局视角又保留了细节深度。我见过一些团队非要在一张图上画上百个服务结果图打印出来有半面墙那么大实际没人看纯属自我感动。分层出图还有个额外好处不同读者可以各取所需。管理层看总览图开发看自己所在域的详细图跨域协作时两张图对照着看。图的维护成本也降低了某个域内部调整只需要更新该域的详细图总览图往往不受影响。4. 技术架构图部署形态和保障策略才是重点技术架构图经常被画成应用架构图的部署版这是个误解。技术架构图的核心不是重复应用之间的关系而是讲清楚运行时环境东西部署在哪、网络怎么分区、中间件怎么选型、故障怎么兜底。4.1 网络分区和部署单元是骨架一张技术架构图第一眼应该能看到网络分区。典型的分区包括接入区、应用区、数据区、管理区不同区域之间用防火墙或网关隔开。每个分区里放对应的部署单元接入区放负载均衡和网关应用区放应用集群数据区放数据库和缓存集群。把分区画清楚的价值在于它能直观地回答安全边界和故障隔离的问题。比如数据库能不能被外网直接访问这种问题看一眼分区图就有答案。很多安全评审和等保检查第一件事就是看这张分区图。部署单元的画法建议标注实例数量和部署形态比如应用集群3节点数据库主从1主2从。这些信息对于容量评估和故障演练非常有用比单纯画个方块写应用服务器信息量大得多。4.2 中间件和高可用策略要显式标注技术架构图里中间件不能只画个图标了事要标注选型和高可用方式。比如消息队列是单集群还是多集群缓存是主从还是集群模式数据库的读写分离和故障切换是怎么做的。这些信息平时看着琐碎真出故障时就是救命稻草。我经历过一次缓存集群部分节点故障值班同学因为架构图上明确标注了缓存集群模式单节点故障自动摘除很快就判断出影响范围可控没有盲目扩容。反过来如果图上只画了个缓存图标就得临时去查配置耽误时间。高可用策略还应该包括降级和限流的标注。哪些依赖挂了可以降级降级后的表现是什么限流阈值大概在什么量级。这些内容画在图上等于把应急预案可视化了一部分。4.3 外部依赖单独成块别和应用混在一起系统依赖的外部服务第三方支付、短信、地图等建议在技术架构图上单独成块用不同颜色或虚线框标出并标注依赖方式和超时策略。这样做的原因是外部依赖往往是故障的高发区而且不受自己控制需要特别关注。单独成块之后哪些外部依赖是强依赖、哪些可以降级这个问题就变得一目了然。评审时也方便追问这个外部依赖的超时设了多久重试策略是什么对方挂了我们的表现是什么。这些问题在图上有了落脚点讨论就不会飘。5. 数据架构图把数据流转和口径统一画出来数据架构图是四类图里最容易被跳过的一类但它解决的问题恰恰是最让人头疼的数据口径不一致、重复建设、来源不清。一张好的数据架构图能让这个数到底以谁为准这类争论少一大半。5.1 核心数据实体先盘点再画流转画数据架构图的第一步是盘点核心数据实体。什么是核心实体就是那些跨多个系统使用、有明确业务含义的数据对象比如用户、商品、订单、账户。把这些实体列出来标注每个实体的权威来源系统也就是常说的主数据源这一步就把数据口径的基准定下来了。盘点完之后再画流转每个实体从产生到消费经过哪些系统在每个系统里是存储还是只读引用是原样传递还是加工派生。用箭头表示流转方向用不同线型区分写入和读取用标注说明加工逻辑。这个画法能暴露很多隐藏问题。比如经常发现同一个实体在两个系统里都有写入权限这就是口径冲突的隐患或者发现某个派生数据被下游当成了权威数据使用一旦上游加工逻辑变化就会出问题。这些问题不画图很难系统性发现。5.2 存储选型和数据生命周期要标清楚数据架构图上每个核心实体要标注存储介质和保留策略。存储介质包括关系库、缓存、对象存储、搜索引擎等保留策略包括在线保留多久、归档到哪里、是否脱敏。这些信息对于数据治理和成本优化都很关键。我见过一个系统日志类数据在在线库里堆了两年没清理存储成本高得离谱问题就在于从来没人从数据生命周期的角度审视过。画数据架构图时把保留策略标上这类问题就会浮出水面。5.3 数据流和业务流要能对上数据架构图和应用架构图之间要能互相印证应用架构图上的每次服务调用如果涉及数据写入应该在数据架构图上有对应的数据流。两张图对不上往往意味着有隐藏的数据写入路径或者有没被识别的数据依赖。我习惯在评审时把两张图并排看逐条核对关键数据流。这个过程经常能发现一些野生的数据写入——比如某个服务绕过主数据源直接写库或者某个定时任务在偷偷同步数据。这些路径平时藏在代码里只有画图对照才能揪出来。6. 四类图怎么协同维护避免画完就过期架构图最大的敌人不是画得不好而是画完就没人管半年后彻底过期。四类图要真正发挥作用必须解决维护问题。我的经验是维护机制比画图技巧更重要。6.1 建立变更触发更新的轻量机制不要指望定期大扫除式的更新那种方式坚持不了两个月。更现实的做法是变更触发当发生特定类型的变更时强制更新对应的图。比如新增一个外部依赖必须更新技术架构图新增一个核心数据实体必须更新数据架构图应用拆分或合并必须更新应用架构图。把这条规则写进团队的变更流程里作为提交评审的一项检查项。刚开始可能会觉得麻烦但坚持下来之后图的时效性会好很多。关键是触发条件要少而明确不要搞成任何变更都要更新所有图那样没人执行得下去。6.2 图要有明确的负责人和版本每张架构图都应该有明确的负责人和版本记录。负责人不一定是画图的人但要对这张图的准确性负责。版本记录至少包括修改时间、修改内容和修改原因。这个要求看似形式主义实际作用很大。当两个人对系统理解不一致时翻出图的版本记录往往能定位到分歧是从哪次变更开始的。而且有了负责人图的质量就有了兜底不会出现人人都能改、人人都不负责的局面。6.3 图和文档、代码的三角校验架构图不能孤立存在它要和设计文档、代码结构形成互相校验的关系。评审时可以做这样的检查图上画的每个应用代码仓库里能不能找到对应模块图上标的每个外部依赖配置文件里能不能找到对应配置图上画的每条关键数据流代码里能不能找到对应的写入逻辑。这个三角校验听起来繁琐但它是保证架构图说真话的最有效手段。我见过太多图上一套、代码一套的情况根源就是画完之后再没和实际实现对过账。定期做一次抽样校验图的可信度就能维持住。7. 几个反复踩过的坑和对应的处理办法最后分享几个我在实际项目中反复遇到的问题都是些文档里不会写、但实际画图时一定会碰到的细节。7.1 工具选型别纠结能协作、能版本管理最重要关于用什么工具画架构图我的观点很明确工具不重要协作和版本管理才重要。文本化的绘图方式用代码描述图形在版本管理上有天然优势每次修改都能 diff适合纳入代码仓库一起管理。图形化工具上手快适合快速沟通但版本管理往往较弱。实际项目中我通常两种都用需要频繁评审和长期维护的核心架构图用文本化方式画纳入版本管理临时沟通用的草图用图形工具快速画。不要在一开始就追求统一工具那往往是形式大于内容。7.2 颜色和图例要克制别让图变成调色盘架构图用色要克制一般不超过四到五种颜色而且每种颜色要有明确含义并在图例里说明。常见的问题是颜色用得太随意同一个颜色在不同图里含义不同读者每次都要重新猜。我的习惯是固定一套配色语义比如蓝色表示核心应用灰色表示外部依赖绿色表示数据存储橙色表示需要关注的风险点。这套语义在团队内统一所有架构图都遵循读者看多了自然形成条件反射读图效率会高很多。7.3 评审时先讲这张图回答什么问题再讲细节架构评审时很多人一上来就讲细节听众还没建立全局认知很容易迷失。正确的顺序是先花一分钟说明这张图回答什么问题、读者是谁再展开细节。这个开场看似简单但能极大提升评审效率。我通常会在图的一角放一行小字写明本图回答系统由哪些应用组成及主要交互关系读者开发与架构评审。这行字不起眼但它时刻提醒画图的人和看图的人这张图的边界在哪里避免跑题。7.4 别追求一张图包打天下该拆就拆最后一个坑是一张图情结——总想用一张图把所有信息都装进去。结果是图越来越复杂信息密度越来越高可读性越来越差。架构图的本质是沟通沟通就要考虑读者的认知负荷。一张图讲清楚一件事比一张图讲十件事但没人看得懂价值高得多。四类图分开画本身就是对一张图情结的纠正。业务、应用、技术、数据各司其职每张图只回答自己该回答的问题读者按需取用。这个思路坚持下来架构文档体系会清爽很多也更容易维护。我在实际使用中最大的体会是架构图的价值不在于画得多漂亮而在于它能不能在关键时刻被拿出来、被看懂、被用来做决策。四类图各画各的、各管各的看似增加了工作量实际上是把沟通成本前置了长期看反而省事。每次画图前多问一句这张图给谁看、回答什么问题比任何绘图技巧都管用。
