很多团队在阿里云上跑业务，前半年问题不大。资源越开越多，VPC、交换机、安全组、SLB 绑在一起，过几个月再问哪台 ECS 走的是哪条链路，常常没人答得上来。这时候一张能对上控制台的阿里云网络拓扑图就派上用场了。它的价值不在于汇报时好看，而是排障时能快速定位，扩容时知道往哪里加，做安全检查时能看清暴露面。
这篇文章按实际操作来讲：拓扑图该标哪些要素，怎么从资源清单一步步画出来，画的过程中哪些地方容易出错。读者以有一定云上经验的运维和架构师为主，刚接手一套老环境的新同事也能照着用。
拓扑图到底要解决什么问题
传统机房的网络图基本是静态的，线路接好了，几年不动。云上不是这样。弹性伸缩会自动加减 ECS 实例，容器服务会调度 Pod，上线节奏快的团队一周新开一个 VPC 也不稀奇。拓扑图如果不跟着改，很快就成了过期文档，还不如没有。
一份能用的阿里云网络拓扑图，至少要满足三个条件。层级要清楚，从地域、VPC、可用区，一直到子网和实例，逐层展开。连接方式要标明，路由、NAT 网关、负载均衡、专线分别用什么线型表示，读图的人不用猜。每个节点还要能对回控制台里的真实资源 ID，核对时才不会对着图找不到东西。
以电商系统为例看网络分层
假设一个中型电商平台，业务包括前台商城、订单中心、支付回调和数据分析。团队在华东1（杭州）规划了两个 VPC，生产 VPC 跑在线业务，测试 VPC 用于预发布和联调。两者之间通过云企业网或对等连接互通，但只开放必要的端口，不做全网段打通。
生产 VPC 里大致分成三类交换机。第一类放公网接入层，分布在两个可用区，挂 SLB 负载均衡，对外只提供 HTTPS，安全组只放行 443。第二类是应用层，跑商城和订单服务的 ECS，只接受来自 SLB 所在网段的请求，不直接暴露在公网上。第三类是数据层，RDS 和 Redis 集群不分配公网 IP，只允许应用层子网访问数据库端口。三层之间的边界，在图上要画得一眼就能看懂。
出站流量这块最容易被忽略。应用层要调用第三方支付接口，团队给这部分流量配了 NAT 网关和弹性公网 IP，所有出站请求都从固定 IP 发出，方便支付平台做白名单。这条出站路径必须在拓扑图上单独标注。否则以后第三方回调失败，排查的人很可能先怀疑网络故障，绕很大一圈才发现是出口 IP 变了。
画完这张图，团队发现了一个问题。数据分析服务原本计划直接连生产库，但拓扑图上它位于应用层之外的独立子网里，这条连线画出来就显得很突兀。最后的做法是改走只读副本，并通过专用网段访问，生产数据层的暴露面没有扩大。这类判断，往往在图上一眼就能看出来。
绘制步骤
实际动手的时候，可以按下面的顺序来：
- 先导出资源清单。在控制台或用阿里云 CLI，把各地域的 VPC、交换机、安全组、SLB、NAT 网关、RDS 和 ECS 列出来，记下 ID、CIDR 网段和所在可用区。清单不全，画出来的图一定有缺口。
- 按层级组织，别把实例铺平。顺序是地域、VPC、可用区、子网、业务角色。一张图上放几十个 ECS 图标，读的人只会看晕。
- 区分流量路径的类型。公网入站、内网访问、出站 NAT、专线连接，用不同线型表示。关键节点旁边注明端口和协议，比如 SLB 到应用层的 8080，应用层到 RDS 的 3306。
- 标出安全组边界。给每个安全组的隔离范围加底色或编号，并在图例里写清楚。读图的人应该能直接看出哪些服务能被公网访问。
- 图源文件进代码仓库。每次网络变更后同步更新，提交时写清楚改了什么、谁改的。这样图和实际资源的差距能一直压在可控范围内。
工具上，Visio、draw.io 都能用，团队里谁熟悉就用谁。阿里云官方也提供了一些架构图模板，起稿时可以参考。工具本身不是关键，关键是图能跟着资源变，而不是做完就躺在文件夹里。
容易踩的几个坑
第一个坑是图画得太满。一张图塞进上百个节点，没人能抓住重点。比较实用的做法是拆成两层：总览图只展示 VPC 之间的关系和公网入口，分区详图再展开子网内部结构。两张图之间用编号对应，查的时候来回跳就行。
第二个坑是忽略 CIDR 规划。网段一旦重叠，对等连接或专线会直接连不通，事后修改成本很高。绘图之前先确认全局 IP 地址规划表，把关键网段直接标在图上，新同事对照起来也快。
第三个坑是只画正常路径。故障时真正需要的是备用路径。拓扑图里最好能看到 SLB 是否跨可用区部署、RDS 主备分布在哪里、NAT 网关有没有备用方案。做故障演练时，图纸本身就能告诉你先断哪条线、验证哪次切换。
还有一点要提醒：拓扑图属于敏感的架构资料，它会暴露公网入口和内部网段。最好限制访问范围，不要随手发到外部群或外部协作文档里。
收尾
拓扑图不需要一开始就完美。从一个 VPC、一张简单的分层图起步，跟着业务慢慢细化，它会逐渐变成团队里经常翻开的文档。
