1. 画图之前先想清楚：架构图到底在表达什么
先说个很多人踩过的坑。我见过不少同学打开Draw.io就急着拖形状，画到一半发现布局乱了、层级乱了、连线的方向也乱了，最后只能推倒重来。5分钟画完一张专业级微服务架构图，真正的前提不是手速快，而是动手之前心里有谱——这张图到底要给谁看，想传递什么信息。
微服务架构图的读者通常只有三类。第一类是团队内部的开发，他们要看清服务边界、调用关系、数据流向，这张图是他们写代码、排查问题时的导航图。第二类是技术Leader或架构评审委员会，他们要判断你的方案是否合理，服务的拆分粒度、依赖关系、瓶颈风险都在图上一目了然。第三类是非技术背景的业务或管理层，他们不看细节，只看整体：你是几个服务、走什么协议、挂了会不会全瘫。
这三类读者决定了同一张图有着完全不同的画法和详略程度。给开发看的图，服务名、端口或协议、关键依赖必须写清楚；给评审看的图，数据存储与服务的归属关系、同步/异步调用要足够显式；给业务看的图，太多细节反而是噪音。所以我建议你在开始画之前，先在脑海里过一遍：谁是受众，我要让他看完图之后得出什么结论。想清楚这两点，“5分钟搞定”才有可能，否则就是把步骤背下来也快不了。
另外，画图前还应该在心里给这张微服务架构图做一个分类。常见的分类方式有两种：一种按运行视角画，叫部署架构图，强调实例、集群、网络分区；另一种按设计视角画，叫逻辑架构图，强调服务、职责、数据归属。绝大多数技术人最早想画的其实是逻辑架构图，也就是把服务层面上的调用关系讲清楚。本文默认以逻辑架构图为主，因为它最常用，也最能体现微服务设计的思想。你把这套思路吃透了，往后画部署架构图时只要换上节点和网络元素就行。
2. 工具选型：为什么我一直推荐Draw.io而不是其他绘图软件
微服务架构图不是画得好看就完了，关键是能快速迭代、多人协作、免费商用。在这个前提下，Draw.io的优势非常明显。它完全免费开源，没有像某些绘图软件那样把大量功能锁在订阅墙后面；它支持网页版与桌面客户端，数据保存在本地而不是某个平台手里。这两点对于经常需要把架构图放进文档、Wiki、代码仓库里的团队来说，太重要了。
Draw.io的网页版本打开浏览器就能用，适合临时画点草稿，也适合几个人快速在线编辑。它的实时协作能力虽然不如专门的在线协作白板那么顺滑，但对架构图这种低频编辑的场景完全够用。不过我更推荐装一个draw.io桌面客户端（官方也叫drawio-desktop，各平台都有安装包）。桌面版有几个网页版替代不了的优势：离线环境下完全不依赖网络；上百个节点的超大图操作更流畅；导出文件直接落到本地，配合Git做版本管理非常舒服。每次架构调整，改完保存提交一版，随时能看到这个架构演进的完整历史，这一点在线工具很难做到。
还有一个细节可能没人提醒你：Draw.io桌面版本质是一个Electron应用，它内部渲染图表的引擎和网页版完全一致，所以你完全不用担心桌面版和网页版之间出现兼容问题。日常我个人的习惯是，在公司给同事做在线评审时用网页版共享链接，自己画复杂图时优先用draw.io桌面版。如果你在浏览器里能正常访问Draw.io的网站，网页版就很省事；如果希望彻底追求资料本地化、离线可用，桌面版更踏实。两个版本的功能操作基本对标，本文所有操作两类版本通用，不用纠结。
3. 画之前必须先做的三件事：网格、图库、图层规划
5分钟画完一张专业架构图，靠的不是一个个手动摆形状，而是把Draw.io当成一个“工程”来用。真正的高手在拖出第一个形状之前，一定会先做三件事：打开网格吸附、把常用图库固定到侧边栏、建好几个图层。这三步看起来不起眼，但决定了你这5分钟是行云流水还是手忙脚乱。
首先是网格。打开Draw.io后，先确认菜单栏“View”里“Grid”是开着，同时“Snap to Grid”也是开启状态。网格吸附的意思是，你拖动形状时它会自动贴齐到网格线上，这样所有服务框在垂直和水平方向天然对齐。别小看这个功能，架构图之所以看起来“专业”，很大原因就是所有元素的间距一致、对齐规范。如果没有网格吸附，手动微调会浪费大把时间，而且今天对好了、明天加个节点又全乱了。
其次是图库侧边栏。默认情况下Draw.io左侧有多个图库分类，但常用的其实就那么几个。画微服务架构图，我建议把“General”“Network”“Azure”或“AWS”这类云厂商形状库提前打开并固定。Draw.io对主流云厂商都有现成图标，比如Kubernetes、数据库、负载均衡、消息队列等等，用现成图标比用纯色方块专业得多。当然，如果你画的是纯逻辑架构图，不依赖特定云厂商，那“General”里那些基础形状其实就够了。图标越多不代表图越好，关键是统一。
第三是图层规划。很多人没用过Draw.io的图层功能，其实它很实用：可以理解成在同一个画布上叠了多张透明的纸，你在不同纸上画不同内容，最后合并展示。画微服务架构图时，我强烈建议至少开三个图层——底层放“基础设施/中间件”，中间层放“平台/公共组件”，最顶层放“业务服务”。这么做的直接好处是，当图变得复杂时，你可以临时隐藏某一层单独检查服务之间的连线，而不需要删除任何元素。还有一个更好的应用场景：一套架构图出两个版本——技术详版和业务简版，详版显示全部图层，简版只显示业务图层，一张源文件多种用途。这比每次重新画一张图高效太多。
4. 主体框架布局：按层级画是微服务架构图的“骨架定律”
微服务架构图之所以经常会画乱，是因为大家习惯从某个服务开始，画着画着发现另一个服务该放上面还是下面、左右该放什么都不确定了。我的经验是，微服务逻辑架构图必须按层级布局，这个框架定下来之后，剩下的填充都是体力活。
一个比较通用的分层模型是这样的，从上到下依次是接入层、网关层、业务服务层、支撑服务层和数据层。接入层是对外的入口，一般画在最顶部，比如移动端App、Web前端、开放API对外的SDK。网关层紧接着接入层，负责路由、鉴权、限流，是流量的门卫。业务服务层是整张图的核心，通常占中央最大面积，放你的各个业务微服务，比如用户服务、订单服务、商品服务等。支撑服务层紧挨业务层，放配置中心、注册中心、消息中间件、任务调度这类被业务服务依赖的公共服务。最底部是数据层，放各种数据库、缓存、搜索引擎。这个分层思路和微服务设计的职责边界天然匹配，画出来不会显得乱，而且很自然地带出流量从哪里进、依赖向哪里走的视觉顺序。
以一套常见的电商微型项目为例子，我习惯这样设计核心元素。接入层画一个手机图标和一个浏览器图标，分别代表移动端和PC端入口。网关层放一个API网关图标，它连接上层所有入口。业务服务层放四个服务：用户服务、商品服务、订单服务、库存服务。这四个服务之间两两可能有调用关系，但为了图面清爽，我只画出必要的跨服务调用，比如订单服务调用户服务、订单服务调库存服务。支撑服务层放注册中心、配置中心、消息队列。数据层放每个服务对应的数据库，以及Redis缓存和ES搜索引擎。这里有个关键的画图原则：数据层的内容必须通过竖线明确地连回它所属的服务，而不是统一画在底部让读者猜。服务与数据库之间的归属关系，很能体现一幅微服务架构图是否专业。
层级的纵向布局还有一个隐藏优势，画完之后你可以沿每层做水平分组，把同一层的服务用虚线框或轻底色背景圈起来，并在左上角标注“业务服务层”“支撑服务层”这类名称。视觉上一下子就有了体系感，别人看这张图不再只是看一个服务的细节，还能快速理解整体分层的逻辑。这一步看起来是装饰，实际上是信息传达的关键。
5. 实操拆解：从空白画布到一张完整微服务架构图的完整流程
前面所有准备工作做完，下面就是真正的实操了。我尽量按操作的先后顺序写，跟着做就能画出来。整个过程大概分为四步：搭骨架、填服务、连线、标注美化。
第一步，搭骨架。新建画布后，先把图层的概念用起来。切到“接入层”思考。从左侧图库里拖一个矩形到画布顶部，鼠标点中矩形边缘的箭头可以快速拉伸大小，规划好整张图的可用宽度。画布顶部区域可以用一个较大的浅色背景框来承载所有入口元素，这个背景框在Draw.io里就是一个普通矩形，你把它的填充色改成极浅的灰或蓝，边框设成虚线或无边框即可。背景框首先拖出来，因为后续的图标都放在它上面。用这种“大框套小框”的方式表示分组，是Draw.io里最核心的布局手段。
第二步，填服务。开始往对应的分组里填充服务图标。选中顶部入口框后，点左侧图库里的App图标，拖入到框内。如果你用的是桌面版，拖拽过程会有预览位置，非常跟手。业务服务层的四个服务，我建议全部使用同一类型形状，比如圆角矩形，大小也保持一致。这个细节很重要：同一层级的视觉重量必须相等。Draw.io默认拖出来的矩形可能大小不一致，你可以先放一个，后面用复制粘贴（Ctrl+C/Ctrl+V）生成其他几个，再分别改文字。复制出来的形状会保留原样式的所有属性，包括颜色、圆角、字体大小，比一个一个重新画高效得多。改文字时双击形状内部就行，进入编辑状态后输入服务名，比如“订单服务”，按Enter确认。注意文字默认会居中显示，可以保持。
第三步，连线。这是很多新手容易出问题的地方。微服务架构图里的连线，本身是有语义的，不要随便用带箭头的线。我的建议统一采用实线箭头表示同步调用（如Feign或HTTP调用），虚线箭头表示异步消息。比如订单服务调用用户服务查用户信息，就用一条实线带实心箭头的连接线，从订单服务的边界拖到用户服务的边界。Draw.io里将鼠标移到形状边缘，会出现一个十字箭头，按住它拖到目标形状上就自动生成连线。默认生成的连线可能带路由点，先用着。生成后选中连线，在右侧“Style”里可以改颜色、线型和箭头样式。为了区分同步和异步，我会把异步消息统一设为虚线。这里你需要记住一个小技巧：按住Alt拖动连线的中间点可以添加额外的路由点，把本来歪七扭八的线整理成横平竖直的直角线，这个操作在画复杂图时出镜率极高。
第四步，标注和美化。连完线后，在每条线上双击，可以直接输入文字，比如HTTP或MQ。文字会跟随连线走向，如果方向不对，可以右键文字选择“水平”调整角度。服务分组右上角用较小字号标注“业务服务层”这类层级名称，左下角标注服务的职责备注。为了让整张图的视觉风格统一，建议把字体统一成同一种（我常用Helvetica或Arial），字号控制在14px左右，同一层级的服务图标统一填色。Draw.io支持在选中多个形状后右键选择“Format”里一次性修改多项样式，很方便。但记得：颜色不宜超过三种，否则会显得非常花哨，反而掩盖了架构本身的信息。
最后一个小步骤是设置画布背景。在空白处单击右键，在“Background”里设置一个极浅的颜色，或直接保持白色。架构图放进技术方案文档时，白色背景永远是最稳的选择。如果偏好类似深色模式展示，也可以设置深色底、浅色图形，但这只适合演示场景，不建议放进文档。
6. 连接线不是随便画的：一条线的正误，直接暴露你的架构水平
很多人把架构图画完自己觉得很顺眼，但评审时被揪出问题，十有八九出在线上。连线最能够体现微服务架构的调用关系和依赖方向，画错了就不是美观问题而是技术错误了。这里我总结几个跟线相关的原则，希望你从第一次画就养成习惯。
第一，明确线的方向。微服务架构图里，一条线的箭头方向指的是调用发起方指向被调方。举例来说，订单服务调用用户服务，那么箭头应该从订单服务指向用户服务。很多新手倾向于把箭头指向数据流的方向——比如用户数据从用户服务流向订单服务——导致整张图箭头五花八门，看的人完全无法判断依赖。记住：微服务图里的主视觉是调用关系，不是数据流向，数据流向在图中用辅助线单独表达。面向团队评审时，我也会特意在图的左下角加一行注：“箭头方向为调用发起方指向服务提供方”，一行字就省去一整轮沟通。
第二，别画满天飞的线。微服务架构图之所以专业感弱，往往不是因为节点丑，而是线条乱飞。线条交错的本质是布局设计没规划好。做法是，尽可能让被依赖的服务放在视觉中心，比如所有服务都依赖注册中心和配置中心，那这两个支撑服务就别放在边角，放在业务服务层正下方，这样所有连线以近似垂直的方向往下走，视觉要清爽得多。另外，不要在多个服务之间反复来回画线，如果两个服务间包含多次调用，合并成一条线并标上多个语义即可。
第三，利用连接点控制线的落点。Draw.io默认的连接点是形状四条边的中点，如果你拖着连接线直接落到形状边上的任意位置，线尾附近容易出现一个较大的吸附偏差，最终导致两张图的连线对齐不一致。最好的做法是，把同一层里所有输出端都固定到形状底部的中点，所有输入端都固定到顶部中点，这样全局的线条流向从上到下，异常统一。操作上也很简单，把鼠标悬停在形状的边缘直到出现十字形连接点，从那个点拖动连线，Draw.io会自动把线的端点固定到该连接点上，后续就算你拖动整个形状，线和形状之间的连接依然保持正确，不会断掉。
最后，真的不要放弃治疗手动调节连线。Draw.io自动生成的线模板不一定符合这张图的布局，所以画完连线后一定要花时间选中它们，配合Alt拖动路由点，把线变成垂直和水平方向上的折线。大部分专业架构图里的线条都是正交的直角线，很少有倾斜的斜线，这是“专业感”的一个重要来源。如果你发现连接线比较多，一条条调整太累，也可以用Draw.io的“Layout”自动布局功能，前提是你的形状都位于不同的层级区域，自动布局能省不少事。
7. 样式细节：一套统一规则，半小时打造“看着就很贵”的架构图
架构图的内容是骨，样式是皮。皮不重要吗？非常现实地说，同样一张图，样式统一会不会直接影响到评审人和合作方对“专业程度”的判断。我自己见过太多架构设计完美但被样式拖累的案例。好在Draw.io提供了非常充足的样式定制能力，花半小时定一套统一规则，后续每次画图都直接套用。
首先选一套主色系。微服务架构图最简单的配色方案是“一个主色+一个辅助色+一个强调色”。比如主色用深蓝表示业务服务，辅助色用灰色表示支撑服务，强调色用橙色标记网关或关键依赖。你在Draw.io选中形状后，右侧“Style”里可以设置填充色、边框颜色、边框线宽。为了一致性，建议业务服务图层里的所有服务框，全部使用同一个填充色和边框色，支撑服务层全部使用另一个填充色。别画成彩虹图，否则图面混乱到根本找不到重点。如果团队有统一的品牌色，那就按品牌色系走。
其次是字体。Draw.io默认字体在不同操作系统下渲染不一致，这会导致你在Windows上画得好好的，到了同事的Mac上文字被撑出框。稳妥的做法是在全图绘制完成之后，Ctrl+A全选，统一在右侧“Text”里设置字体和字号，再把“Word Wrap”开启。你以为这没什么，但只要经历一次评审现场发现字体歪了的尴尬，就会明白这一行设置有多重要。字体大小根据层级来定，大分组标题用18px，服务名称用14px，线上的标注用12px，形成清晰的文字层级。
图标的使用也有讲究。Draw.io对AWS、Azure这类云图标都做了成套支持，但同样一套图里最好不要混用不同云厂商的图标风格，否则视觉上很乱。如果只是画服务模块，没有特定的云厂商依赖，那更建议全部用基础的圆角矩形，再在内部放一个该服务类型对应的小图标。混合风最容易翻车，宁愿统一素一点。服务图标保持同宽同高，也会让图面显得整齐。操作上，一次框选所有服务框，在右侧“Geometry”里统一设定宽度为120、高度为60，两步解决。
还有一个不容易注意但非常加分的细节：对齐与间距的守恒。同一分层内的多个服务，彼此水平间距保持一致；不同分层之间的垂直间距也保持一致。手动画很难保证每一个间距都一致，所以我通常会用辅助线工具：从左侧标尺拖出一条参考线，把服务框的边缘或中轴吸附上去。虽然Draw.io不像某些设计软件有智能参考线那么强大，但配合网格吸附也能达到相近的效果。画完之后，把所有辅助线拖回标尺删除即可，不影响导出。
8. 一台电脑两份图：如何利用图层同时维护“技术版”和“简化版”
这个经验我真的是在项目里吃过大亏之后总结出来的。最初我给团队画了很详细的版本，所有服务、中间件、依赖关系密密麻麻，拿来给业务领导汇报时，对方看了半天也没理解为什么订单服务和支付服务要分开，场面很尴尬。后来我就开始用图层功能，一张源文件同时维护技术详版和业务简版两套图，效率非常高。
具体做法是这样的。在Draw.io的右下角或菜单“View”里打开图层面板，先建立三个图层，分别命名“Base_Legend”“Tech_Detail”“Biz_Simple”。Base_Legend放整张图的标题、图例和版本号，不管哪一版都会显示。Tech_Detail放完整的服务、中间件、数据库和全部连线，给技术评审用。Biz_Simple放合并简化后的服务模块，比如把用户、商品等服务的内部细节全部收拢，只显示一个“业务服务”组块，用于向业务方讲清楚大方向。当你需要导出技术版时，关闭Biz_Simple图层、打开Tech_Detail层；需要导出业务简版时，反过来操作。由于共用同一个Base_Legend，两版本之间的视觉风格天然统一，不会出现两个版本看着不像一个系统的情况。
用图层的另外一个场景是画部署架构图。把逻辑架构图画完之后，在原文件里新建一个“Deployment”图层，将已有的服务图标按所在主机或K8s Pod重新分组一遍。因为有了图层机制，你不需要复制一遍业务服务，而是在原图上做映射。不过坦白说，这个操作对新手有一定门槛，初次尝试时容易把两层元素混在一起。我的建议是，刚开始可以只做技术版和简化版的区分，部署图另存一个文件画，等对图层操作熟练了再合并到一个文件里。
图层还有一个隐藏好处，就是帮助排查图里的依赖错误。当图很复杂时，一个一个核对服务调用关系容易看花眼。你可以在图层面板里将其他图层全部隐藏，只留业务服务图层，单独审视每一个服务之间的连线是否有重复、反向、跨层跳转，也能选中所有连线后快速查看连线数量是否与预期一致。相比在一张全图里反复缩放找线头线尾，这种方式要高效得多。
9. 导出与分享：不同场景选择不同格式，别只会导出PNG
画完图，最后一步是把成果分享出去。这里其实也有讲究，不同的使用场景要导出不同格式，否则要么清晰度不够，要么后续没法编辑，给自己埋坑。
最常见的需求是把架构图贴到技术方案文档或Wiki里。这种情况下，导出PNG就够了，但有两个参数必须留意。一个是“Zoom”缩放倍数，Draw.io导出对话框里有一个缩放选项，默认是100%，对于包含大量小字号文字的架构图，建议缩放到200%甚至300%再导出，生成的PNG分辨率才够清晰。别人把图放大看时不会糊成一团。第二个是“Border”边距，可以调整导出图片外圈的留白宽度，建议设置为10到20，图片观感更舒适。
如果你的架构图要投放到网页或在线文档中，更推荐导出SVG格式。SVG是矢量图，在任何分辨率下都清晰，而且文件体积小。Draw.io导出SVG时，默认的选项可能比较冗杂，如果只是展示用途，可以在导出设置里勾选“Include a copy of my diagram”这个选项来保留可编辑性，但注意这会增加文档体积。一般来说，放到技术方案里的图不需要让别人编辑，选择纯SVG即可。另外，Draw.io也支持导出PDF，适合放进正式的设计评审材料中，PDF在打印或者转成其他格式时最不容易出错。
还有一种情况是你的架构图需要嵌入Notion、语雀、Confluence这类知识库。不同产品的支持能力不一样。有的平台支持插入SVG，有的只支持PNG，建议按平台的能力选择。Draw.io官方也没有特别完美的统一方案，所以我个人的建议是：文档平台尽量用相对稳定的PNG 200%缩放版本，确保显示效果不依赖平台的解析能力。如果你需要把可编辑的源文件存档或分享给团队同事，可以直接导出Draw.io的.xml格式，或者干脆把drawio源文件保留在项目的docs目录下，用Git做版本管理。每次架构调整后提交一次，你就会有一份架构演进历史，这比在聊天记录里传来传去可靠太多。
还有一个很多人问的问题：Draw.io画的图能不能嵌入Markdown文档。可以，但过程不算无脑。较稳妥的办法是把架构图导出为SVG或PNG后在Markdown里用图片链接引用。不建议直接粘贴数百行的XML内容到Markdown里，会让文档可读性急剧下降。所以请记住这个结论：Markdown文档放图片，同事要改图则把源文件放在旁边。永远别让线上文档成为唯一可编辑的载体。
10. 常见问题与排查技巧实录：画图过程中的那些坑，我替你踩过了
本来想用Q&A形式框起来，但实在没忍住要用自由谈的方式说说这些坑。毕竟是多年攒下的经验，希望大家绕道走。
第一个坑，也是踩的人最多的，就是Draw.io画到一半发现所有形状全部偏移了。原因一般有两个。一个是无意间关闭了网格吸附，而你拖动某个大分组时，它里面的元素发生了错位。另一个是误触了全选拖拽，导致所有节点一起动了位置。解决办法是养成习惯：拖拽大分组时按住Shift只移动当前选中的形状，同时频繁保存。Draw.io虽有自动保存功能，但遇到大工程时我还是习惯多按Ctrl+S。
第二个坑，导出PNG后文字特别小，放到文档里完全看不清。这个问题的根因是从头到尾都没评估过画布的显示密度。一张宽度超过2000像素的画布上，各种小框和文字如果都以默认字号摆放，100%缩放导出后看起来就会非常吃力。补救措施是在导出时把缩放比调高。更根本的方式是绘制过程中控制画布的物理尺寸：菜单栏“File”里的“Page Setup”中可以设置画布大小，我一般会把画布宽度设成1600或1920，对应标准的16:9大屏演示画幅。这么设置之后，画图的密度天然会更合理，导出的图也基本不会出现字太小的问题。
第三个坑，协作时因为互相同步信息不足，导致同一个文件被不同的人改了样式。Draw.io桌面版不存在服务端协同，所以如果团队多人需要同时编辑，必须借助网页版的协作模式。网页版的历史记录和多人光标支持得还算不错，但如果你一定坚持用桌面版，那我建议把源文件放在Git仓库里，谁改动谁提交，通过commit记录解决冲突。真到了两个人同时改同一个文件时，Git合并drawio这种XML文档偶尔会冲突，虽然能用文本编辑器解决，但成本不小。我的建议是明确分工：架构图维护原则上一个人负责，其他人有改动提需求，避免团队里出现多个“随手改两笔”的人。
第四个坑是掉进“DRY原则”的陷阱，花大量时间试图让每一个样式都可复用。Draw.io确实支持自定义模板和自定义图库，但微服务架构图通常每张图的布局差异很大，模板的收益没有想象中高。我自己的习惯是保存几套固定颜色的形状作为图库，但不强求每个边框、每条线都变成可复用组件。画图是表达思想的工具，不是代码工程，过度工程化会让你把注意力从架构本身挪走。
还有一个非常实用的技巧：画完图后选中全部形状再检查一遍“Fill”和“Stroke”，尤其是在从网页版粘到桌面版或者反向粘贴的时候，样式经常会发生漂移。统一收尾是这个5分钟流程里最后一个黄金环节，千万别省。
11. 从5分钟到持续演进：把架构图变成团队的一等公民文档
最后聊一点不太算技术、但很重要的话题。很多团队刚开始用Draw.io画架构图时觉得新鲜，画完一张放到Wiki里就再也不更新了。等半年后回头看，架构已经演进得面目全非，图彻底失效。要让微服务架构图真正发挥价值，必须把它当成一等公民文档来维护。我个人的经验是，每次微服务版本迭代、新增服务、变更依赖，都要求变更人员同步更新架构图并在Commit Message里标注“architecture update”。这个流程看起来严苛，但一旦形成习惯，团队所有人都会受益。
另外，给架构图标上版本号和日期，也是非常有必要的。Draw.io的Base_Legend图层就可以承载这些信息。写上“v1.2 / 2025-03”，别人一看到就知道这张图是什么时候的状态。改图时顺手把版本号递增一下，成本几乎为零，但能避免很多把旧图当新图看的误解。尤其是跨团队协作时，一份非当前版本的架构图会引发大量不必要的沟通成本。
如果你还想继续进阶，可以探索给架构图里的服务图标绑定链接。Draw.io支持在形状的“Edit Link”里填上URL，这样在网页浏览器里点击图标就能跳转到对应的服务仓库或部署环境页面。这个功能在你把架构图嵌入团队知识库时非常实用，等于画图之余顺手就把系统导航做了。还有，通过Draw.io的“Extras”菜单可以编辑绘图脚本、导入自定义图库，这些进阶功能足够你玩上一阵子。
对我个人来说，用Draw.io画微服务架构图这几年，最大的感受是：真正重要的是把架构的“叙事线”理清楚。工具只是让表达变得更简单、更专业。每当我看到一个新人能花5分钟就画出一张结构清晰、样式统一的架构图，我就知道他已经理解了“表达优先”这件事。希望这篇内容也能帮你跨过这个门槛，画出一张真正配得上你系统复杂度的架构图。
