1 云网络进阶要打通什么
订单 API 已经能在云上运行：入口接收请求，应用验证用户身份，再把订单写入数据库。最初，这些资源都在同个账号和同个虚拟私有云中，网络图只有几条线。后来，支付由独立团队维护，报表服务搬到另个账号，仓库系统仍在办公室机房。每项调整都有合理原因，连在一起却带来新问题：订单服务究竟通过哪里访问支付服务，数据库回包会走哪里，断开某条连接会影响哪些业务？
云网络进阶要解决的，是在资源边界增多以后，仍能解释和控制通信路径。这里的“打通”不等于让所有地址互相访问，而是让被批准的业务流量稳定到达，让没有业务理由的访问被阻止，并让团队能从证据中说明结果。网络设计需要同时回答来源、目的、路径、许可、返回和责任归属。只看到控制台中的“连接成功”，还不足以回答这些问题。
先区分几种容易混在一起的成功。域名解析成功，表示客户端得到了地址；路由存在，表示转发设备知道把匹配的包交给哪里；安全规则允许，表示某个检查点没有拒绝这类包；应用返回成功，才表示这次业务请求完成。前面的条件通常是后面的前提，却不能互相代替。访问超时时，立即扩大安全规则可能既没有解决问题，又增加了暴露面。
本课沿用订单 API，但把重点放在网络边界。账号 A 承载订单应用，账号 B 承载支付应用，办公室机房保留仓储系统。身份系统负责回答“这个调用者是谁、能执行什么业务动作”，网络负责限制“哪些来源可以接近哪些入口”。私有地址本身不代表可信；能够建立连接，也不代表拥有扣款权限。部署、身份、网络、数据与观测需要在同张方案图上交代各自的职责。
读完本课，你应当能为具体调用画出往返路径，识别对等连接不能自动传递的边界，说明策略路由改变了哪个转发决定，并为故障准备逐段验证的方法。复杂路由协议的收敛细节、设备内部转发表实现以及专用链路的底层封装暂不展开。入门阶段更有价值的能力，是拿着拓扑图、路由表和请求记录，清楚地解释为什么这条流量会到达，或为什么它应该被挡住。
2 VPC、对等与混合连接
VPC 是云上自行规划地址与网络边界的基本容器。子网把地址空间分成便于部署与管理的范围，路由表决定匹配目的地址的流量下一步交给谁。安全组等访问控制限制允许的来源、目的和端口。它们解决的问题不同：给子网增加路由不会自动开放服务端口，放行端口也不会创造缺失的路径。设计时应把“如何到达”和“是否允许”分别写明，再检查它们能否共同支持业务。
假设订单 VPC 使用 10.20.0.0/16，支付 VPC 使用 10.30.0.0/16，机房使用 172.20.0.0/16。这些是本课示例地址，不是可直接套用的地址规划。连接之前，要确认参与网络的实际地址范围没有重叠。若双方都使用 10.20.0.0/16，设备可能把远端目标当成本地地址，普通路由就难以表达预期。地址转换能缓解部分情形，但会增加排查和审计成本，应先评估重新规划地址的可能。
VPC 对等连接为指定的网络建立私有通信关系，但通常需要双方分别配置路由和访问规则。尤其不能默认关系可传递：A 与 B 对等、B 与 C 对等，并不表示 A 可以经过 B 访问 C。跨账号创建连接还涉及双方授权；账号授权解决谁能建立或管理连接，数据面规则解决哪些包可以通过。建立连接的管理员与允许访问支付接口的业务身份，也应分别管理。
当网络数量增加时，可以评估集中连接的中转结构。它让多个网络接入共同的转发中心，减少逐对连接的维护负担，却也把更多业务依赖集中到中转路由和管理权限上。并非所有接入网络都应互通：生产应用、开发环境和运维入口可以接入相同平台，同时使用不同的路由域或访问策略保持边界。具体隔离能力取决于所选产品，需要在落地时核实。
混合连接把云与办公室或数据中心连接起来。站点间 VPN 常通过公网承载加密隧道，适合需要较快建立连接的场景；专用连接提供不同的接入方式与容量选择，但仍需规划冗余、加密要求和故障切换。不要把“专用”理解为应用已经安全，也不要把隧道在线理解为业务已经可达。两端的地址、路由、规则、域名解析和回程都需要配合，具体性能还要通过实际业务测量。
网络可达后，服务发现仍可能失败。支付服务的私有域名可能只在账号 B 的解析范围中可见，账号 A 即使能访问对应地址，也可能解析不到名称。方案应说明使用何种私有 DNS 关联或转发机制，并确认解析得到的是预期入口。固定地址测试可以帮助区分解析与转发问题，但长期绕过域名会削弱服务迁移能力，不能作为完整修复。
3 流量工程与策略路由
流量工程是在业务约束下安排流量经过哪些路径。例如，订单调用支付要求低延迟和稳定性，报表同步更关心吞吐量，访问外部接口可能要求经过固定出口以便对方设置来源白名单。选择路径时，需要说明优化目标及其代价。将所有流量绕到集中检查点便于统一检查，却可能增加延迟、跨区费用和故障依赖；让业务直接通信则需要更清晰的分散治理。
理解普通路由可以从目的地址开始。在常见的目的地址路由中，设备查找匹配的网段，通常优先采用更具体的前缀。例如，10.30.8.0/24 比 10.30.0.0/16 更具体，默认路由 0.0.0.0/0 则覆盖更广的目的范围。这里先讨论通常的前缀匹配原则；同前缀的来源、优先级和等价路径规则由实际平台决定，需要查对应规则，不能靠路由表的显示顺序推断。
策略路由增加了选择依据。在支持它的设备或平台上，可以根据来源地址、入口等条件，把某类流量交给指定的路由表或下一跳。比如让订单生产子网访问机房时经过检查设备，而测试子网走另条被批准的路径。不同云资源支持的条件和动作不同，云子网路由表也不一定支持完整的策略路由能力。先确认能力范围，再表达方案，避免把概念图当作可直接执行的配置。
路径调整必须同时观察回程。请求经过检查设备进入支付服务，响应却沿另条路径直接返回，可能形成非对称路由。非对称并不必然错误，但有状态防火墙、地址转换设备等中间节点通常依赖连接状态；若看不到配套方向的流量，就可能拒绝数据。因而“请求路径更短”不是单独成立的优化理由，必须确认相关设备允许这种往返方式。
还要考虑地址转换。若出口设备把来源地址转换成自己的地址，下游看到的来源就不再是原始应用地址。安全规则、日志关联以及回程路由都要按实际可见地址设计。不能在应用日志里查到原始地址，就假设每个网络节点也看到它；代理传递的请求头与网络包的来源地址属于不同层面，且请求头只有在可信代理链中才适合作为审计依据。
改变流向前，应保留基线：当前下一跳、正常请求延迟、失败比例和流量规模。每次变更限定来源与目的范围，先用小范围流量验证，再逐步扩大。检查设备还应具备足够容量和可用性，否则新的必经节点可能成为瓶颈。入门时无需计算复杂的全网最优路径，但要能回答“新增的路径约束解决什么问题、引入什么依赖、失败后如何恢复”。
4 动手：画一条跨账号访问路径
这次动手的产物是可供复核的访问路径图和检查记录，不要求开通真实资源。设定任务：账号 A 的订单应用通过私有入口访问账号 B 的支付 API，目标端口为 TCP 443，支付数据库只接受支付应用的访问。订单应用位于 10.20.1.0/24，支付应用位于 10.30.8.0/24。先把范围固定下来，避免“打通支付网络”这种无法直接验证的需求。
先画调用者、解析器、订单子网路由表、跨账号连接、支付入口和支付应用，再画响应返回的箭头。每个箭头旁写清检查对象：DNS 查询在哪个解析范围完成，订单子网匹配哪个目的前缀，连接是否已被双方接受，支付入口实际接受什么来源。若入口会代理到后端，再补画代理到支付应用的独立连接，不能把它当作原请求无条件延长的一条线。
接着填写路由假设。订单侧到支付网段的路由指向已批准的连接，支付侧到订单来源范围的回程也指向正确连接。若中间存在转换或代理，应改用该段真正看到的来源地址。核实路由表是否关联到实际部署的子网，而不只是确认账号里存在某张正确的表。相似名称和历史遗留配置很容易造成“看对了配置，检查错了对象”。
然后列访问控制。支付入口只接受被批准的订单来源和 TCP 443；支付应用访问数据库使用另项独立规则，订单子网没有直接访问数据库的业务需要。跨账号引用安全组是否受支持、是否受连接类型限制，需要查当前平台能力；不能支持时，可以使用受管理的地址范围等机制，并补充变更同步要求。网络限制之外，订单服务仍要使用被授权的业务身份调用支付接口。
最后写出验证顺序：确认服务名称解析到预期入口，确认双方路由及关联对象，检查相关安全规则，再从批准的测试来源发起轻量请求。记录时间、来源、目标、端口、测试身份和结果。在生产环境中优先使用只读健康检查或专用测试接口，避免为了连通性验证创建真实扣款。若使用已有订单查询接口，也要遵守业务授权与数据访问范围。
完整记录应区分预期和实际。预期是订单应用收到符合接口约定的响应；实际可能是连接超时、连接被拒绝或应用返回权限不足。不同现象指向不同检查方向，不能统一写成“网络不通”。还要补充反向验证：未获批准的测试子网应无法访问支付入口，订单应用应无法直连支付数据库。允许的路径可用、禁止的路径受限，才说明边界与需求相符。
5 连通性与最小暴露取舍
最小暴露不是追求规则数量最多，而是让资源只向必要的调用方开放必要入口。对于订单调用支付，可以开放整个订单 VPC，也可以限定到订单应用子网、服务身份可识别的入口或明确的调用网关。范围越细，往往越能减少无关资源触达的机会，同时也更依赖准确的资产记录和自动化更新。规则粒度需要适合团队能够持续维护的边界。
网段允许列表容易理解，但子网中新增的资源可能自动获得相同的网络接近能力。专用服务入口可以缩小发布范围，不过可能增加入口管理、名称解析和费用。集中出口有利于固定来源地址，却会隐藏部分原始来源，需要依靠日志恢复关联。这些选择没有统一的最佳值，应围绕业务访问关系、故障影响与维护能力说明理由。
滑块中的结果用于讨论设计，不是安全评分。允许范围从服务级扩大到整个网络，示例中可接近入口的资源数会增加，但真实风险还取决于身份验证、漏洞状况和数据权限。反过来，细粒度规则也不自动带来可靠性：如果发布系统变更子网后没有更新规则，正常服务也可能被阻断。最小暴露需要与资源生命周期和部署流程连接起来。
可用性需求也会影响边界。为故障准备备用链路时，要明确备用路径是否经过同等检查、是否使用不同来源地址、是否会访问不同区域的入口。业务切换之后，白名单和 DNS 若仍只支持主路径，备用连接虽然在线，请求仍可能失败。允许备用路径应有明确条件和验证记录，不应演变成长期保留的宽泛通行规则。
评审时可以逐项讨论：这条连接支持哪个调用，最小可行范围是什么，谁更新允许列表，谁能批准临时扩展，扩展到期如何收回。再把网络限制与应用授权对应起来。支付入口即使只接受订单网络，也需要校验调用身份、请求权限和业务参数。这样，网络故障与业务拒绝有各自的处理方式，网络边界变化也不至于直接变成数据访问授权。
6 常见坑：扁平打通后难审计
扁平打通常从便捷操作开始：新系统接入时复制旧规则，为排障增加整个网段，再用默认路由把多个环境连到共同出口。短期里请求更容易成功，长期却难以回答谁依赖谁。生产、开发与运维资源能够互相接近，任何连接调整都可能影响未知调用，团队于是更不敢清理旧规则，边界继续扩大。
审计困难的核心是业务关系与网络许可失去对应。某条允许 10.0.0.0/8 的规则究竟支持订单、报表还是历史迁移，配置本身通常说不清。只有规则编号而没有业务目的、负责人和有效期，也难以判断它是否仍然必要。应把“订单查询支付状态”这样的调用关系与具体来源、入口、端口及管理对象关联，才能在服务迁移或下线时收回相应权限。
流日志能提供连接层面的线索，例如某个时间段内的来源、目的、端口和允许或拒绝结果，但字段与采样方式取决于平台。它通常不能证明用户完成了哪个业务动作，也未必覆盖每个内部转发节点。应用日志则能描述接口与业务结果，却不一定解释包在哪里丢失。将流日志、入口访问日志、应用请求标识和配置变更记录结合，证据才更完整。
时间也需要对齐。调用方报告 14:05 超时，网络记录使用另个时区，变更单只写“下午调整”，排查就会走偏。统一记录时区、时间范围和资源标识，保留观察窗口。流日志未出现某条记录时，先检查采集是否开启、是否存在延迟以及查询条件是否准确，不能立即认定流量从未发出。观测系统自身也有覆盖范围和保留期限。
收敛已有扁平网络时，不宜直接删除所有宽泛规则。先识别业务依赖，列出仍有流量的访问关系，结合负责人确认必要性，再分批建立更具体的许可并验证。日志中暂时没有流量，不等于规则无用；月末结算、故障恢复和定时作业可能尚未运行。对每次收紧保留回退方法和负责人，使审计改进能够在业务连续运行的条件下推进。
7 案例：路由环路导致区域黑洞
订单团队为访问机房仓储系统部署了中转节点与检查设备。原来的路径是订单子网到中转，再到混合连接。后来团队要求相关流量先经过检查设备，于是把中转面向机房网段 172.20.0.0/16 的下一跳改成检查设备，却遗漏了检查设备所用路由表。该表仍把同个机房网段指回中转，包就在这 2 个节点之间反复转发。
表面现象是某区域的订单处理开始超时，机房系统却报告运行正常，云上检查设备的管理界面也可以访问。由于该区域的相关子网都依赖这条中转路径，看起来像整个区域失去了仓储访问能力。实际受影响的是依赖该错误路径的流量，并非区域内所有云服务。所谓“黑洞”描述了请求没有到达目标的表现，具体原因在这里是路由环路。
网络包可经过的跳数受到限制，循环不会无限持续。跳数耗尽后包被丢弃，相关错误消息还可能因过滤或限速而无法被调用方看到。客户端因此可能只表现为超时。设备在线、连接状态正常、路由条目存在，都不能排除环路；它们没有证明连续转发最终能到达目的网段。
排查从固定样本开始：选择已批准的订单测试来源，记录访问机房测试接口的时间和目标。对照最近变更，逐段查看实际关联路由表的匹配前缀与下一跳。中转把包交给检查设备，检查设备又指回中转，这组重复关系已经足以形成关键证据。路径探测工具可以辅助，但中间设备可能不回应探测，不能只靠探测输出判断整条路径。
恢复时，团队按照预先批准的回退方案还原此次路由变更，使受影响流量恢复到原路径。若检查是必须满足的控制要求，则应按既定故障预案处理业务，不能自行绕过控制。随后在隔离的验证范围内修正检查设备到混合连接的转发，并核对回程。变更后的测试同时检查业务响应、实际路径、检查记录和错误率，避免只凭隧道在线就宣布恢复。
复盘发现，变更单只包含中转侧的配置截图，没有描述检查设备之后的下一跳，也没有覆盖该区域的实际子网关联。改进措施是把每段匹配依据、下一跳和回程列入评审，并把受影响子网作为验证范围。更复杂的路由协议机制可以在后续学习；当前最重要的结论是，每个局部配置都看似合理时，组合起来仍可能形成错误路径。
8 把云网络拓扑写进方案
方案中的网络拓扑应服务于评审和运维，不能只展示资源图标。每个网络边界标出账号、区域、VPC 与地址范围，每个连接标出类型、用途、管理方和可用性假设。对公网入口、跨账号入口、混合连接和数据访问边界分别说明。图上可以省略无关资源，但省略的范围应明确，避免读者误以为图中没有画出的访问就一定不存在。
为关键业务补充路径表，每行描述来源、目的名称与地址范围、协议端口、解析方式、经过的连接、主要许可和回程。订单到支付、支付到数据库、订单到仓储是不同的调用关系，应分别记录。若经过代理或地址转换，还要指出每段可见来源。这样，部署人员可以核对具体资源，审计人员可以理解许可依据，排障人员也能选择正确观察点。
方案还需要说明变更如何发生。应用迁移到新子网、接入新账号或启用备用链路，都可能要求同步更新路由、DNS 和规则。写明谁提出需求、谁管理跨账号连接、谁维护地址范围、谁负责验收。跨团队协作时，不能只写“由网络团队处理”；应具体到可联系的职责或值班角色，以及变更失败后的恢复责任。
验收标准应同时覆盖正常访问、禁止访问和故障恢复。正常访问要符合约定的接口结果与性能目标，禁止访问要从未授权来源验证，故障恢复要观察切换后的路径和权限是否仍符合要求。对于延迟、带宽和恢复时间，使用业务给出的目标与实际测量，不把示例数值当承诺。若某项尚未验证，明确记录待验证内容、负责人与完成条件。
最后把观测和成本放进拓扑解释。跨区域、跨连接、检查设备和日志留存都可能产生费用，实际计费口径需要核实。观测则需要覆盖关键边界，并让请求记录能够关联到部署版本和网络变更。好的方案能让接手者解释某条业务流量为何获准、经过哪里、失败时先看哪里，而不必依赖绘图者在场口头补充。
9 从云网络进阶走向云平台内核：计算（C55）
网络路径清楚后，还不能保证订单 API 始终稳定。请求已经到达入口，应用仍可能因为计算实例资源不足、启动缓慢或故障而无法及时响应。下一课进入云平台内核中的计算，讨论云上运行应用的计算资源以及平台如何提供这些资源。这里先建立边界意识：连接成功说明路径与监听条件基本满足，接口变慢还需要继续检查应用与计算层。
计算变化也会反过来影响网络。实例扩容可能增加子网地址消耗，实例替换可能改变后端地址，跨可用区部署可能改变流量分布。若网络规则依赖少量手工维护的固定地址，计算的弹性能力就容易受到限制。方案应优先使用与服务生命周期相适应的入口和管理机制，同时确认这些机制在当前跨账号、跨网络场景中确实可用。
为 C55 保留这些问题即可：应用运行在哪里，谁决定增减实例，实例不可用时由谁替换，新实例如何加入服务入口。先不用深入虚拟化内部实现和资源调度算法。把本课的路径图带到下一课，读者就能把“请求如何到达”与“到达后由什么执行”接起来，逐渐形成完整的云平台视图。
放进方案里
在订单系统方案中，新增“跨账号与混合网络”条目。写明账号 A 的订单 VPC 使用 10.20.0.0/16，账号 B 的支付 VPC 使用 10.30.0.0/16，机房使用 172.20.0.0/16，并注明这些范围已经过冲突检查。拓扑图标出区域、子网、连接类型与管理方，生产与测试的访问边界分别说明，避免把连接关系直接理解成全部互通。
访问需求限定为订单应用通过私有入口调用支付 API 的 TCP 443，以及订单应用访问批准的仓储接口。支付数据库只接受支付应用访问。分别记录名称解析、目的前缀、下一跳、实际可见来源、允许规则和回程；存在代理或地址转换时补充分段信息。跨账号连接由双方网络负责人维护，业务调用身份由对应应用负责人授权。
验收从批准的订单测试来源发起无业务副作用的请求，记录时间、目标、响应和对应日志；再从未授权来源验证访问受限，并确认订单应用不能直连支付数据库。验收附件保留实际子网关联的路由表标识与匹配条目，核对是否有更具体的前缀将流量引向其他连接；对等连接的验收范围仅含双方网段，不据此承诺经支付网络访问机房。备用连接需要单独验证解析、来源地址与规则，不能仅凭连接在线判定可用。性能和恢复目标以业务要求为准，未完成的测量列为明确待办。
每次路由变更附上变更前后的往返路径，检查中转与检查设备是否互相指回。先在限定范围验证，再扩大到相关子网，并保留符合控制要求的回退方案。流日志、入口日志与应用请求记录使用可对齐的时间，关联配置变更。规则登记业务目的、负责人和复查日期；服务迁移或下线时同步复核连接与许可，使拓扑持续对应实际系统。
10 小结：下一步云平台内核：计算（C55）
云网络进阶把关注点从单个资源的连通，扩展到跨账号、跨网络与混合环境中的可解释路径。VPC、对等连接和中转结构提供连接方式，路由决定转发方向，访问控制与业务身份共同限定使用范围，观测记录帮助确认真实结果。
检查自己的路径图：能否指出订单请求每段的下一跳与回程？能否说明未授权来源在哪里被拒绝？若检查设备把目标网段指回中转，能否在业务超时前发现问题？带着这些问题进入 C55，继续理解云平台如何提供和管理承载服务的计算资源。