业务迁入阿里云的网络规划与架构设计指南，助力企业实现高效上云与迁移。-云网络规划设计-阿里云帮助中心

在业务迁移至阿里云的架构设计中，网络规划往往是首要考量。
如何进行业务迁云的网络规划？基于实践，本文沉淀了一套系统性、工程化的规划流程：“现状与需求收集 → 转化为网络需求 → VPC宏观架构设计 → 场景化方案拆分 → 实施与部署”。基于该流程，可实现企业迁云网络架构从设计到落地的全链路闭环，可以供企业IT负责人、系统架构师、云运维工程师、解决方案架构师等实践参考。

前言

以云计算为核心驱动力的数字化时代，企业上云进程正在全面加速。数据表明，全球范围内已有超过60%的企业IT工作负载部署在云环境中，并且这一比例仍在持续攀升。这一趋势的背后，是人工智能、大数据等新兴技术对海量算力的迫切需求，而云计算正是承载这些前沿技术创新的最佳土壤，这也关乎着企业的业务创新与发展战略。

相较于传统IDC的重资产投入和僵化运维，云计算通过提供弹性、敏捷、按需付费的服务化能力，使企业能够摆脱基础设施的束缚，聚焦于核心业务的快速创新。

1 业务上云，网络先行

不管是传统数据中心还是云计算系统建设，网络规划都需要最先被考虑到。传统IDC建设时，要优先考虑网络架构设计，再进行系统架构设计和服务器存储数据等资源的入网；云计算系统建设时，私有网络VPC也几乎是所有云产品开通过程中必要的配置项，因此云计算系统围绕VPC的网络规划也要优先进行。

网络架构是最容易被忽略的环节，架构设计不当极易对业务的发展埋下隐患。如服务地址冲突会导致无法相互通信、服务之间隔离无法有效控制、应用跨可用区容灾设计不当等，这些问题都会对业务的当下或未来发展埋下隐患。如果前期规划不当，后续再做调整，往往会更加费时费力。

网络架构规划的核心价值，在于能够充分发挥云计算在弹性扩展、资源整合和成本优化等方面的优势。通过合理的架构设计，企业可以构建更加稳定、高效且可扩展的 IT 基础设施，从而提升业务响应能力，在激烈的市场竞争中获得更大的发展空间。

2 业务上云，网络设计流程概览

在业务上云过程中，网络的规划设计是一个系统性的工程。整个流程可以分为以下几个关键步骤：

步骤流程	关键内容
业务现状分析和需求收集	深入了解客户当前业务环境及未来规划。一方面需要盘点所有业务系统，另一方面也要梳理整个网络拓扑、识别关键网元节点以及业务流路径。
业务需求转换为网络需求	基于业务需求，抽象并转化为云网络建设需求。明确VPC的划分及VPC的类型、构建以VPC为中心的网络架构（包括每个VPC内的网络需求、VPC与公网的通信需求、VPC之间的通信需求、VPC与云下环境的通信需求等）。
围绕VPC拆分网络架构 (High Level Design)	基于收集到的网络需求，构建高层次的网络架构。如VPC划分设计（需要几个，分别部署哪些Region，互通关系如何），每个VPC的公网互通如何设计（哪些VPC有公网、是入还是出）、云上跨地域如何设计（哪些Region要互通及带宽、哪些地域有专线及规格，哪些地域有VPN及规格）等。
将高层架构拆解为可实施的网络场景并设计方案 (Low Level Design)	在高层次架构确定后，对架构各环节进一步拆分与细化，贴合真实业务场景并明确设计细节。如：VPC 划分完成后，需进行各VPC内部网络设计，涉及公网交互的VPC需明确公网方案；确定VPC的互通关系后，进一步细化VPC间互联方案，以及VPC与其他云/IDC/办公区等的互联方案。
基于网络场景方案完成实施和部署	围绕各网络场景方案，制定可实施的步骤，完成资源创建与配置、联调测试、验收与上线投产，确保方案按预期交付与稳定运行。

3 业务上云，网络设计流程详解

接下来的篇幅，针对业务上云过程中的网络设计每一个步骤和环节进行一个详细的说明。

3.1 业务现状分析和需求收集

客户业务现状分析和需求收集环节，需要深入了解客户的现有业务环境和未来规划，盘点业务系统及其整体拓扑结构，同时也要进入拓扑结构内部，梳理业务流转链路，识别关键网元节点的配置与特性。

通常，我们可以参考以下模板和信息，对业务现状和需求进行一个全面的盘点：

维度	关键点
业务系统	本期上云所涉及的业务系统情况：有多少个业务系统，分别是什么类型的业务？业务系统的关联性和部署模式：哪些业务系统需要做严格的隔离、哪些业务系统无需严格隔离甚至交互性较强希望部署于同一网络环境内？
业务服务端	每一类业务系统的服务端情况：所在地域、当前和未来所需的服务器资源规模数量、是否需要高可靠性（跨机房/AZ可用区级、多地域Region级、多云级）服务端系统架构中涉及的其他组件：当前服务端系统的架构中，涉及了哪些其他关键组件的部署，如网络、数据库、存储等组件，分别的资源数量和使用情况
业务访问端	业务客户端：每一类业务系统的对应客户端情况，业务系统是否需要被对应Client所访问、Client所在地域、Client群体是互联网、办公区还是VPN客户端？希望通过公网还是私网方式访问？有无时延和跨境访问等方面的需求？通信带宽方面的要求（带宽、并发等）？其他业务交互场景：业务是否存在与其他上下游伙伴互访的情况，希望基于公网还是私网？
其他需求	是否有其他方面的需求：如时延要求、跨境访问需求等
整体拓扑	当前拓扑结构：当前网络的整体拓扑业务流转链路：拓扑中，客户端与服务端、服务端之间等关键业务流量的流转链路情况关键网元节点：业务流转链路中，关键网元节点的配置与特性识别

【实战案例01：某IDC客户业务迁移至阿里云】①IDC的业务现状和需求收集

首先对IDC的业务现状和需求进行了盘点收集，如下：

业务系统方面：本次迁云涉及多套业务系统，主要是官网和商城类业务，各业务系统之间无需严格隔离，且部分业务系统交互频繁，所以在IDC都部署于同一网络数据中心环境中。
业务服务端：
1. 业务部署方面：①目前部署于河北，上云后可以考虑北京地域，业务IDC目前部署了700+物理服务器；核心商城会员类业务部署于河北同地域的两个机房，做了跨机房级别的容灾；还有一些非核心业务则采用单节点模式，无需容灾设计。②IDC中关键组件包含了F5 GTM、FW防火墙(主要是NAT作用)、F5 LTM私网负载均衡、Nginx服务网关、业务服务器、数据库服务器等。
2. 资源规模方面：目前，两个业务IDC1/2分别部署了700+物理服务器，大数据IDC3部署了800+物理服务器。但，为了保障业务的扩容容量，目前三个IDC均使用了xx.xx.xx.xx/16私网地址（分别是10.4.0.0/16、10.5.0.0/16、10.7.0.0/16）。
业务访问端：
1. 业务客户端：业务面向中国内地用户，主要通过公网进行访问，暂时无时延和跨境访问等方面的需求
2. 其他业务交互场景补充：业务存在与上下游伙伴互访的情况，也是基于公网（白名单）方式
整体业务拓扑等情况，如下所示：
1. 包含了3个IDC、1个POP点。其中，2个IDC1/2为对外业务（本次迁云重点，主要是官网和商城类业务，有公网出入口）、IDC3为私网业务（主要是大数据业务）、1个POP节点（主要用于连接3个IDC之间的网络互通）。
2. 两个IDC的容灾型业务流转链路：
  1. 入方向流量：
    1. 当用户访问业务域名时，DNS服务器域名解析至F5 GTM
    2. GTM基于运营商IP进行第一层业务调度将流量转发至两个IDC的公网带宽层
    3. 数据流量进入IDC后，会通过FW-DNAT规则先做一层公网地址到私网地址的转化，将流量转发至F5 LTM设备
    4. LTM基于调度规则，完成对业务服务器的监听，根据转发规则将流量准确调度至业务服务器
    5. 业务服务器完成业务处理，同时也会与数据库层进行数据查询和交互
  2. 出方向流量：
    1. 部分业务服务器也需要主动访问外部网络，IDC路由会将流量调度至FW
    2. 基于FW SNAT地址映射，统一出公网实现互联网访问
  3. 服务器之间的流量互访
    1. 这部分流量数据私网互访，如服务器与服务器之间的访问
    2. 主要通过BGP路由+私网LTM实现服务器之间的私网互访
3. 两个IDC的单节点型业务流转链路：
  1. 单服务器网络架构相对简单，独立的业务服务器也绑定有独立的公网IP，不管是入方向还是出方向，都可直通公网与互联网进行通信。
4. 关键网元节点的网络特性
  1. GTM+运营商多IP调度：因为IDC基本以单线为主，所以通过GTM+多运营商IP实现多运营商线路接入
  2. 公网IP+FW防火墙DNAT+F5 LTM（+Nginx/OpenResty）：在IDC中，公网IP接入后，首先通过FW-DNAT地址转化将公网访问转发至LTM，再结合LTM调度规则将流量转发至对应的自建Nginx/OpenResty转发层，进而实现对于业务的访问和调度
  3. F5 LTM私网调度：LTM同时还承载了服务器之间私网互访的流量调度
  4. FW防火墙SNAT+公网IP：FW-SNAT主要实现了IDC内服务器主动访问互联网时，统一互联网出口的管理

【实战案例02：某他云客户业务迁移至阿里云】①其他云的业务现状和需求收集

首先对用户在其他云的业务现状和需求进行了盘点收集，如下：

业务系统方面：本次迁云涉及的主要是GPS定位服务系统，业务范围覆盖了欧洲和美国，所以在欧美两地域各基于一个VPC进行了公有云形式的部署。
业务服务端：
1. 业务部署方面：业务部署在欧洲和美国两个VPC，①两VPC之间业务是独立的，分别服务于欧洲和美国的用户；②两个VPC之间的业务数据会做数据同步。
2. 资源规模方面：VPC内的业务资源通过容器承载，POD节点规模达4000+。
业务访问端：
1. 业务客户端：①主要访问业务的客户端在欧美两地，主要是终端设备和管理员APP，通过公网进行接入；②开发人员主要在中国内地办公，需要基于公网跨境访问海外业务进行试用和测试。
2. 其他业务交互场景补充：业务主要提供GPS定位服务，其定位信息接入了多家上游数据服务商伙伴，目前主要通过私网Peering方式互通。
整体业务拓扑等情况，如下所示：
1. 主要业务部署欧美两个Region VPC。每个VPC内采用同地域多可用区的部署模式，属于同地域跨可用区级别的容灾架构。欧美两地域VPC通过Peering实现数据同步私网通信，与上游伙伴之间目前也是基于Peering进行私网互通。
2. 由于用户原先也使用了标准的云服务架构，所以整个业务的架构已经很符合“卓越架构”的标准，如下图拓扑所示。其中，两个VPC的业务流转链路如下：
  1. 入方向流量：通过ALB构建了负载均衡的业务公网入口架构，当用户访问业务域名时，DNS就近解析至欧美VPC的NLB公网入口。
  2. 出方向流量：POD也需要主动访问外部网络，通过NAT网关统一出口架构实现，目前使用的是单AZ NAT没有考虑容灾。

3.2 业务需求转换为网络需求

将业务现状和业务需求，继续提炼上云后对应的网络建设需求。

基于业务系统，明确VPC划分和VPC类型。同时，进一步以VPC为中心，梳理网络架构的设计需求，包括需要设计多少个VPC、每个VPC内的网络如何设计、VPC之间的通信需求、VPC与其他平台的通信需求等。通常，我们需要明确几类信息：

1、划分VPC：

1）VPC划分原则：

基于业务系统和架构现状，首先需要考虑云上VPC的划分，需要设计多少个VPC？

通常情况下，VPC划分原则如下：

多个VPC的划分模式
- 最佳实践的体系下，建议考虑多VPC的划分方式，即每个业务系统一个或多个VPC。
- 多个VPC有诸多优势，如VPC间天然划分出多个安全域；业务模块独立、强隔离、弱互通（类似于白名单）；每个VPC是一个故障域，业务故障域更小、发生故障后影响范围小；多个VPC财务独立结算和分账更容易；多VPC扩展性更好。
合并VPC的划分模式
- 如果有特殊情况，也可以考虑合并VPC
- 如合并VPC可以节省跨VPC间通信成本；大VPC内资源更容易扩展；业务系统较少时合并VPC更好管理；多业务容器POD混部，资源利用率更高。

总的来讲，VPC划分应遵循“安全优先、平衡管理”原则，既要考虑故障域最小化与安全强隔离，又要考虑到资源共享与跨业务协同效率。通常，如果一个集团性企业、不同组织业务严格隔离、业务规模庞大且需要严格隔离等情况，建议划分多个VPC进行管理。如果是企业业务系统较少、业务交互性强等情况，也可以考虑合并VPC进行部署。

2）常见VPC类型：

作为公网与内网之间安全缓冲、承载对外服务组件（如DDoS/WAF/NAT/负载均衡等）的DMZ区域VPC；
为多环境提供统一能力（如身份认证、集中日志、内部DNS等）的共享服务区VPC；
承载线上业务、具备最高安全与监控要求且可按业务/项目拆分的生产环境VPC；
与生产隔离、供开发编码与初测且可按业务/项目拆分的开发环境VPC；
用于集成/性能/UAT等更深度测试并尽量模拟生产的测试环境VPC；
部署安全工具（如东西向防火墙、IDS、漏洞扫描等）以监控与防护整体架构的安全VPC；
以及用于运维人员安全远程接入与云环境管理（如VPN、无影等）的运维&VPN接入区VPC等。

VPC类型的划分，可以对不同安全等级与职责的资源进行分区分域，形成清晰的网络边界与标准化访问路径，从而降低风险与故障扩散、提升合规审计可控性、实现更高效的运维治理。

在实际业务过程中，并非一定要划分如此全面的VPC类型。往往只有超大规模的企业网络会做如此细粒度的设计，中小规模的企业中更常见的是按照业务隔离要求进行划分即可，该划分原则需要灵活使用。

2、梳理网络架构的需求

明确了VPC划分后，进一步基于“业务现状和需求收集”步骤中的信息，完成以VPC为中心梳理网络架构的需求，主要包含了以下几个方面。

网络需求

说明

VPC划分

需要划分多少个VPC、每个VPC的类型（分别承载什么类型的业务）；

基于上一步骤调研信息中的业务系统环节，“有多少个业务系统，业务系统是什么类型，业务系统是强隔离还是希望部署同一网络环境内”，可以完成对VPC的划分和类型定义。

围绕VPC的网络需求

基础需求：VPC Region、可用区AZ、IP地址数量等

容灾需求：跨地域容灾、跨可用区容灾、不考虑容灾

地址规划和子网划分需求：VPC私网地址、vSwitch子网规划等

公网通信需求：VPC是否需要公网交互，公网入口架构、公网出口架构

私网通信需求：VPC与哪些资源之间需要私网通信，如与其他VPC、办公区、IDC/其他云等

使用上一步骤调研信息中“业务服务端、业务访问端”等信息，可以提炼出VPC网络设计的需求：

基于“每一类业务系统服务端所在地域、资源规模数量、是否需要高可靠性”等信息，可以判断VPC的基础需求和容灾需求；
基于“服务端系统架构中涉及的其他组件”层级信息，可以判断交换机子网的层级划分需求；
基于业务与访问端的连接需求，可以判断公网通信和私网通信的需求；

【实战案例01：某IDC客户业务迁移至阿里云】②将IDC上云需求转换为网络需求

前置信息：基于上文“实战案例01”，已经完成了“①IDC的业务现状和需求收集”步骤，那么接下来就要从需求中提炼网络需求。

本次业务的终极目标是将IDC全栈搬迁到云上，但由于线下机房老旧和复杂的配置，需要分阶段对业务上云进行规划。最终确定了“一期先将网络和业务资源先迁移至云上，二期再将数据库和大数据业务搬迁上云”的节奏规划。所以，云上网络的设计既要满足当下业务需求，又要满足未来业务发展。

从整体需求出发，我们将IDC上云需求中网络需求明确如下：

VPC划分设计需求：需要划分多少个VPC、每个VPC的类型（分别承载什么类型的业务）
1. 在IDC中，虽然有大量的集群式和单节点的业务，但都统一部署于同地域跨机房的两个IDC1/2，属于同地域跨机房级别的容灾，同时业务之间会有频繁的交互，也不需要做严格的私网隔离；IDC3中只有大数据业务。
2. 所以，业务上云后只需要划分1个业务VPC即可，在1个VPC中将集群业务部署于多个可用区，这样的方式也对应了线下IDC同地域跨机房的容灾设计。
VPC网络设计需求：
1. 基础设计：VPC地域选择就近河北的Region，由于需要同地域跨机房容灾所以可用区需要规划2个，根据当下和未来服务器等资源的规模需要规划10000+个IP地址规模。但为了保障业务的扩容容量，目前三个IDC均使用了xx.xx.xx.xx/16私网地址（分别是10.4.0.0/16、10.5.0.0/16、10.7.0.0/16），所以希望云上也保持xx.xx.xx.xx/16的地址段规模。
2. 容灾设计：使用同地域跨可用区级别的容灾设计，所以网络/计算/数据库等资源也需要对应跨可用部署。
3. 地址规划和子网规划：同上，参考IDC地址段设计，云上VPC私网地址也保持xx.xx.xx.xx/16；可用区A/B的网络/计算/数据库规划vSwitch子网在该VPC地址段下进行分配。
4. 公网通信：VPC需要与公网进行通信，集群式业务需要统一公网出入口架构，单节点业务可以直通公网。
5. 私网通信：在搬迁过程中，由于数据库和大数据业务短期会保留在线下，所以VPC需要与IDC进行私网打通。
6. 其他需求：暂时没有跨境时延方面的特殊需求

【实战案例02：某他云客户业务迁移至阿里云】②将迁云需求转换为网络需求

前置信息：基于上文“实战案例02”，已经完成了第一步业务现状和需求收集，那么接下来就要从需求中提炼网络需求。

本次业务的终极目标是将业务全栈搬迁到阿里云，虽然用户原先也使用了标准的云服务架构，整个业务的架构也很符合“卓越架构”的标准，但我们还是需要整体对网络需求做细致的明确。如下：

VPC划分设计需求：需要划分多少个VPC、每个VPC的类型（分别承载什么类型的业务）
1. 需要欧美两地域的2个VPC，每个VPC都是业务VPC，架构也基本一致。
VPC网络设计需求：
1. 基础设计：VPC地域选择就近美国和欧洲的两个Region，由于需要同地域跨可用区容灾所以每个VPC的可用区需要规划2个以上，根据当下POD资源的规模需要规划5000+个IP地址规模。但为了保障业务的扩容容量，目前两个VPC均使用了xx.xx.xx.xx/16私网地址，所以希望新的VPC也保持xx.xx.xx.xx/16的地址段规模。
2. 容灾设计：使用同地域跨可用区级别的容灾设计，所以网络/容器/数据库等资源也需要对应跨可用部署。
3. 地址规划和子网规划：同上，参考VPC地址段设计，云上VPC私网地址也保持xx.xx.xx.xx/16；可用区A/B的网络/容器/数据库规划vSwitch子网在该VPC地址段下进行分配。
4. 公网通信：VPC需要与公网进行通信，且使用了负载均衡和NAT网关的架构。
5. 私网通信：两个VPC之间私网通信，两个VPC与上游服务商之间也需要私网通信。
6. 其他需求：中国内地员工需要基于公网访问海外业务进行试用和测试。

3.3 围绕VPC设计网络架构（High Level Design）

接下来根据明确的网络需求构建高层次的网络架构。如下所示，一个典型的网络架构通常包含几个主要信息：

VPC：一共规划几个VPC，分别在哪些地域Region
公网通信：哪些VPC有公网交互、是入方向还是出方向（入方向是否需要负载均衡、出方向是否需要统一公网出入口）、带宽规模多大
私网通信：哪些VPC需要互通及带宽、哪些VPC与IDC需要专线互通及规格，哪些 VPC与办公区需要有VPN及规格

【实战案例01：某IDC客户业务迁移至阿里云】③围绕VPC拆分网络架构（High Level Design）

前置信息：基于上文“实战案例01”，已经完成了“①IDC的业务现状和需求收集”“②将IDC上云需求转换为网络需求”2个步骤，那么接下来就要围绕VPC拆分网络架构。

基于以上，本IDC业务迁入阿里云的宏观网络架构包含如下几个主要信息：

VPC：一共规划1个VPC，规划在距离河北较近的北京地域Region，VPC之间的互通关系暂时不涉及
公网通信：VPC需要公网交互，集群式业务需要统一公网出入口（参考IDC LTM/FW的配置，入方向需要负载均衡、出方向需要统一公网出入口）、带宽分别需要1Gbps；单节点业务服务器可以直通公网，带宽10Mbps。
私网通信：VPC需要与IDC进行私网互通、带宽10Gbps*2

整体High Level Design的网络设计拓扑如下：

【实战案例02：某他云客户业务迁移至阿里云】③围绕VPC拆分网络架构（High Level Design）

前置信息：基于上文“实战案例02”，已经完成了两个步骤，那么接下来就要围绕VPC拆分网络架构。

基于以上，本其他云业务迁入阿里云的宏观网络架构包含如下几个主要信息：

VPC：一共规划2个VPC，规划在美国硅谷和欧洲法兰克福两个Region。
公网通信：VPC需要公网交互，本地的公网带宽均为1Gbps、员工跨境访问带宽为100Mbps。
私网通信：VPC之间需要私网互通，带宽1Gbps；VPC与上游伙伴之间也需要私网互通，带宽1Gbps。

整体High Level Design的网络设计拓扑如下：

3.4 将网络架构拆分成网络场景并设计方案（Low Level Design）

接下来，我们需要将高层架构进行细粒度的场景拆分，以便于可以对每个细粒度场景进行详细网络方案设计（采用卓越架构设计理念）。我们基于云网络实践总结了数十个云网络具体实际应用场景，基本可以覆盖上云全部网络。如下图和下表所示：

架构	场景
云上VPC网络（同地域）	VPC内网络设计（含：VPC内公网出入口设计）
云上VPC网络（同地域）	基于NAT网关构建统一公网出口
应用交付网络	SLB构建应用交付网络
应用交付网络	GA加速广域网应用交付
VPC与VPC互联网络	基于TR/CEN构建VPC互联网络
VPC与VPC互联网络	基于Peering构建VPC互联网络
VPC与其他环境互联网络	专线构建混合云/多云网络
	IPSec VPN构建分支上云网络
	SSL VPN构建移动办公上云网络
	……

这些常见场景化方案的设计，也有一个大致的顺序和思路可供参考。

完成了VPC的划分、基本网络需求的了解、宏观的网络架构设计、网络场景化拆解之后，我们通常会进入到每一个VPC的内部，对VPC内的网络架构进行设计。首先，第一步主要是围绕云上VPC网络架构进行设计。VPC网络架构设计中，会重点考虑公网出入口需求的设计。其中，在公网出口方面，通常会使用基于NAT网关的公网出口设计。在公网入口的方案设计时，通常会遇到本地公网应用交付网络架构（常见的会使用SLB构建应用交付网络）；如果涉及到跨境公网应用交付，也会使用GA全球加速的广域网应用交付方案进行设计。

完成每个VPC的架构设计之后，则需要对多个VPC互联的需求进行设计。当VPC之间需要通过私网交互时，则需要基于TR/CEN构建VPC互联网络；除了VPC之间的互联，VPC还会需要与其他环境互联。如：VPC与IDC/他云进行私网打通，此时通常会推荐专线方案；VPC与本地办公网互联，此时通常会推荐IPSec VPN方案；移动办公用户私网访问云上VPC业务，此时通常会推荐SSL VPN方案。

【实战案例01：某IDC客户业务迁移至阿里云】④将网络架构拆分成网络场景

前置信息：基于上文“实战案例01”，已经完成了3个步骤，那么接下来就要在High Level Design宏观架构的基础上，将网络架构拆分成网络场景。

基于本次IDC迁云的宏观网络架构，所拆分的场景主要涉及如下3个部分：

VPC网络架构设计
VPC内统一公网出入口架构设计，含：基于NAT网关构建统一公网出口、基于SLB构建应用交付网络
基于专线构建混合云网络

【实战案例02：某他云客户业务迁移至阿里云】④将网络架构拆分成网络场景

前置信息：基于上文“实战案例02”，已经完成了3个步骤，那么接下来就要在High Level Design宏观架构的基础上，将网络架构拆分成网络场景。

基于本次迁云的宏观网络架构，所拆分的场景主要涉及如下5个部分：

VPC网络架构设计
VPC内统一公网出入口架构设计，含：基于NAT网关构建统一公网出口、基于SLB构建应用交付网络
GA加速广域网应用交付（跨境）
基于TR/CEN构建VPC互联网络
IPsec VPN构建私网互联

接下来，我们进入主要的场景化方案设计。

3.4.1 云上VPC网络

VPC内网络设计

一个标准的VPC网络设计指南可参考同地域单VPC网络设计。整个设计主要包含了几个关键部分：

VPC地域：本VPC的地理位置
可用区规划：通常，VPC内各产品均建议多可用区冗余部署。如VPC内的负载均衡、NAT网关、云服务ECS、数据库RDS等，以提升服务的可用性。
VPC IP地址规划：VPC的私网地址段大小，通常需要参考我们之前所盘点的“业务服务端系统涉及的组件和资源规模”数据作为参考，同时也要考虑未来网络容量，建议至少选择16位掩码（超大型10.xx.xx.xx/8，大型172.16.xx.xx/12，中型192.168.xx.xx/16）。同时，我们也可以借用IPAM能力，对整个账号下面的VPC地址进行统一的规划和分配。参考：结合IPAM规划并创建专有网络
交换机规划：根据要放置的云产品分类来确定划分交换机，比如放置负载均衡的SLB交换机、放置NAT网关的NAT交换机、放置服务器的业务交换机等。
子网及地址规划：子网除了从附着在交换机角度分类之外，还分为公网子网（其交换机连接的路由表具有公网访问能力）和私网子网（其交换机连接的路由表没有公网访问能力）；参考我们之前所盘点的“业务服务端系统涉及的组件和资源规模”数据及未来组件容量，来进行子网地址段大小的划分。

VPC内公网出入口设计

VPC网络设计中，对于有公网交互需求的VPC，还需要进一步设计公网出入口。

按照入方向和出方向进行划分，公网入方向通常建议使用负载均衡的架构（关于选择何种负载均衡将在下一节“SLB构建应用交付网络”进行详细介绍），公网出方向通常建议使用NAT网关架构。VPC公网出入口设计逻辑如下：

入方向公网连接设计（被公网访问，应用交付）
- 如果VPC中部署被公网客户端访问的服务系统，建议使用负载均衡SLB架构
- 负载均衡架构优势简述：负载均衡作为应用系统的入口，可提升整体架构的弹性能力。①负载分担：将请求合理分配到负载较轻的服务器，避免个别服务器过载，提升整体响应速度。②横向扩展：支持动态添加或移除后端服务器，轻松应对流量增长。③高可用性：当某一个可用区发生故障时，负载均衡可自动探测健康状态并将流量切换至正常可用区，保障业务连续性。
出方向公网连接设计（主动访问公网）
- 如果VPC中部署的云服务器有访问公网的需求，建议使用NAT网关架构
- NAT网关架构优势简述：私有子网中的ECS实例通常为了保障安全不允许直接绑定公网IP，但ECS需要主动访问公网(例如调用第三方接口)时，可以通过NAT网关访问公网。NAT网关可以针对不同的粒度（ECS、交换机或VPC）为VPC下的云资源提供公网NAT能力。
ECS直通公网
- 有些应用服务器是随着业务需求随时拉起和释放的、服务端口是随机的（比如游戏的战斗服、房间服，音视频会议服等）；有些应用服务器出网访问需要独立的带宽，避免共用NAT网关被其他服务干扰。对于这些服务器不经过SLB或NAT、而是通过直接绑定EIP直通公网更适合。

【实战案例01：某IDC客户业务迁移至阿里云】⑤VPC内网络设计（含VPC公网出入口设计）

前置信息：基于上文“实战案例01”，已经完成了4个步骤，完成了High Level Design宏观架构的设计，将网络架构拆分成网络场景。那么首先，我们则进入第一部分，进行VPC的网络架构设计。

基于之前的业务需求和架构规划，首先我们来设计每个VPC的设计。由于本IDC项目仅涉及单VPC，所以仅需要进行这一个VPC网络架构设计，包含几个关键部分：

VPC地域：选择距离河北较近的北京地域Region
可用区规划：选择ABC3个可用区。其中，可用区A/B用于承载集群式业务，设计了同地域跨可用区级别的容灾，业务对应的网络/计算/数据库等资源也跨可用部署；可用区C用于单独承载单节点业务。
VPC IP地址规划：虽然当前IDC只有2000+台物理服务器，但都规划了/16的地址掩码位数。与客户沟通一致后，决策云上也使用/16掩码。同时避免与IDC地址段冲突，最终VPC IP地址规划为10.20.0.0/16。
交换机和子网规划：VPC内的交换机和子网则分别从10.20.0.0/16进一步划分，整体规划如下表。
- 可用区AB的集群业务所需的SLB、NAT、Nginx/OpenRestyECS、ApplicationECS、RDS等分别规划对应的子网
- 可用区C的单节点业务单独规划业务子网
基于以上，我们则可以确定VPC的网络架构设计，拓扑和细节如下所示：

【实战案例02：某他云客户业务迁移至阿里云】⑤VPC内网络设计（含VPC公网出入口设计）

前置信息：基于上文“实战案例02”，已经完成了4个步骤，完成了High Level Design宏观架构的设计，将网络架构拆分成网络场景。那么首先，我们则进入第一部分，进行VPC的网络架构设计。

本次迁云涉及到2个VPC的网络架构设计，两个VPC的架构基本一致，包含几个关键部分：

VPC地域：分别选择美国硅谷Region、欧洲法兰克福Region。
可用区规划：硅谷目前有两个可用区，所以选择了AB2个可用区；法兰克福目前有三个可用区资源，与客户沟通后尽量保持POD资源多可用区冗余所以选择了ABC3个可用区；两个VPC均采用同地域跨可用区级别的容灾设计，业务对应的网络/容器/数据库等资源也跨可用部署。
VPC IP地址规划：当前POD只有4000+节点，但与客户沟通一致后，延续当前使用网段规模的/16掩码，同时也可满足未来业务的持续扩展。虽然当前VPC与其他云VPC无需互通，但也可尽量避免地址重叠，以法兰克福地域VPC为例，规划的VPC网段为10.128.0.0/16。
交换机和子网规划：以法兰克福地域VPC为例，VPC内的交换机和子网则分别从10.128.0.0/16进一步划分，整体规划如下表。
- 可用区ABC的业务所需的SLB、NAT、ACK Node/Pod、RDS等分别规划对应的子网；
- 按照卓越架构的规划，Node/Pod/RDS一般需要单独规划交换机做子网隔离，但客户反馈业务与数据库交互频繁，希望放在同一个子网内，所以单独规划了统一的私有子网。
- 同时，为了后续业务扩展，还分别规划了预留子网
基于以上，我们则可以确定VPC的网络架构设计，拓扑和细节如下所示：

基于NAT网关构建公网出口

当VPC内有服务器需要主动访问公网时，最简单直接的方式是直接绑定EIP，这也就是我们上文所提到的“ECS直通公网”方式。但是，当服务器台数比较多，且多台服务器都需要主动访问公网时：

逐一配置EIP会增加管理和使用复杂度
需要节省公网IP数量，减少互联网暴露面
需要节省公网的带宽成本，实现带宽复用
在生态上下游主动访问场景中，当业务上游被访问的资源有白名单限制，合作访问过程中为了减少开白频率和IP个数
服务器归业务部门管理，服务器每次创建和消亡时，业务部门不希望有额外的公网访问配置

对于以上场景类型的服务器而言，更推荐使用“基于NAT网关构建公网出口”的方式。

重要说明：NAT网关有两种“容灾类型”的产品形态

跨可用区容灾型NAT：产品本身提供主备可用区容灾能力。①用户只需要部署一套“跨AZ容灾型NAT”，当一个可用区出现故障时，系统会自动拉起备份可用区的NAT网关，实现主备切换。②备可用区由阿里云选择，用户侧无需感知。③特别注意，主备切换过程中，可能存在最长 10 分钟的切换中断。对于无法接受此中断的业务，强烈建议在不同可用区分别部署NAT网关，并在业务层面实现流量调度和故障切换。
单可用区容灾型NAT：已于2026年05月开始灰度发布（参考单可用区NAT网关发布公告）。产品本身不提供主备可用区容灾能力，但也可基于解决方案实现跨可用区容灾。①单AZ容灾型NAT不具备产品级别的主备功能，当可用区故障时，本可用区NAT不可用；②单可用区容灾型NAT网关价格门槛更低，其中CU费阶梯计费降幅可观，100万以内CU降幅20%，100万以上降幅超50%，普惠中小企业的同时，也支持业务的增长降本。③使用方面，对可用性要求不高的业务可直接使用单个实例，而可用性要求高的业务也可以采用多AZ部署单可用区容灾型NAT实现容灾。

基于不同容灾类型的NAT网关，在公网出口架构的设计时也有多种选择，主要推荐如下：

部署模式	基于“跨可用区容灾型NAT”的单台部署模式	基于“单可用区容灾型NAT”的主备部署模式	基于“单可用区容灾型NAT”的多AZ对齐部署模式
使用推荐	业务没有做多AZ对齐，但需要确保单一出口跨可用区的高可用性，同时不希望配置复杂路由。	业务没有做多AZ对齐，但需要确保单一出口跨可用区的高可用性，同时需要配置VPC主备路由。	业务有极强的跨可用容灾诉求，业务资源采用了多AZ对齐的架构，同时也需要确保单AZ故障时故障域只在本可用区
方案简述	只需购买和部署一套“跨可用区容灾型NAT”实例，当主可用区出现故障时，系统会自动拉起备份可用区的NAT网关，实现主备切换。	需购买和部署两套“单可用区容灾型NAT”实例，同时搭配VPC主备路由能力，主路由指向主NAT网关、备路由指向备NAT网关。当主可用区出现故障时，VPC路由会自动切换至备NAT网关，实现主备切换。	首先，业务资源采用了多AZ对齐的架构，与之对应的各AZ公网出口也分别部署“单可用区容灾型NAT”实例。在此架构下，业务和公网出口均保持了多AZ级别的故障隔离能力。
方案拓扑

【实战案例01：某IDC客户业务迁移至阿里云】⑥基于NAT网关构建公网出口

前置信息：基于上文“实战案例01”，已经完成了VPC的网络设计。那么，在VPC的网络设计中，因为有公网出口的需求，所以需要进一步规划“基于NAT网关构建公网出口”的方案。

关键需求：①集群式业务服务器需要主动访问公网，基于公网访问上下游合作伙伴业务；②为有效加强安全管控，希望对服务器的公网出口进行统一管控。③伙伴侧对访问IP进行白名单管控，为了简化管理，所以希望有效收敛业务服务器公网出口的IP地址数量；④由于业务做了跨可用区级别的容灾，所以希望公网出口也达到可用区粒度的故障域范围。

多AZ对齐NAT网关的架构设计：

在可用区A/B分别规划NAT子网，NAT网关1为可用区A的资源提供出公网能力，NAT网关2为可用区B的资源提供出公网能力，从而实现公网出口可用区粒度的故障域范围；
对可用区A/B中需要出网的业务交换机，分别创建引流到对应NAT网关的子网路由表并关联（如图，子网路由表1引流到NAT网关1、子网路由表2引流到NAT网关2）。
多AZ对齐的NAT网关架构，虽然创建了多个NAT实例，但基于NAT按量付费的计费模式，所以并不会增加CU费用。
补充，IP地址池的使用：在本业务场景下，由于业务服务器通过NAT网关访问上游合作伙伴，涉及到白名单管控操作的便捷性，所以规划了IP地址池。 IP地址池1专为两个NAT网关使用，是一个连续EIP地址段，有效减少了伙伴侧的开白频率和加白工作量。

【实战案例02：某他云客户业务迁移至阿里云】⑥基于NAT网关构建统一公网出口

前置信息：基于上文“实战案例02”，已经完成了VPC的网络设计。那么，在VPC的网络设计中，因为有公网出口的需求，所以需要进一步规划“基于NAT网关构建公网出口”的方案。

一期：《基于“跨可用区容灾型NAT”的单台部署架构》

在可用区A创建“跨可用区容灾型”NAT网关（产品本身具备容灾能力），当主可用区出现故障时，系统会自动拉起备份可用区的NAT网关，实现主备切换。
在NAT网关上为需要出网的资源配置SNAT规则，此时系统路由表会自动添加一条“0.0.0.0/0路由条目”指向NAT实例，实现对应资源出网的路由引流。

二期：考虑升级至《基于“单可用区容灾型NAT”的主备部署架构》

上文有提到，“跨可用区容灾型NAT”的主备能力由产品高可用设计所提供。在主备切换过程中，可能存在最长 10 分钟的切换中断。为了应对业务继续发展过程中对极致SLA的需求，所以我们在每个VPC预留了另一个可用区的备份NAT网关交换机，后续可将NAT网关架构升级为基于“单可用区容灾型NAT”的主备部署模式。

在可用区A创建主NAT网关，在可用区B创建备NAT网关；
同时，在VPC路由目标组中创建“路由目标组1”，主目标成员选择主NAT网关、备目标成员选择备NAT网关；
继续在VPC系统路由表中，创建一条自定义“0.0.0.0/0路由条目”指向“路由目标组1”，从而实现NAT网关主备模式的部署
重要提醒：①该方案中依赖VPC路由目标组的能力，具体详见VPC产品文档；②NAT网关主备部署模式，既可以选择“多可用区容灾型NAT”也可以选择“单可用区容灾型NAT”，本案例中升级时选择了“单可用区容灾型NAT”以节省成本。

企业服务共享设计

随着SOA（面向服务的架构）普及和企业对阿里云Landing Zone（卓越架构）的采用，企业架构趋向于模块化与多VPC部署，这也导致企业跨VPC互访需求增多，对跨VPC服务共享网络的设计需求也不断增多。

对于部分支持公网访问的服务（如支持公网访问的OSS服务），可直接通过公网调用，在此不赘述。

需要重点关注的是，为保障数据安全私密性，很多企业服务要求通过私网接入，这就需要进行合理的私网服务接入架构设计。常见的私网服务访问场景和架构设计有：

VPC基于私网访问同阿里云服务：某阿里云VPC，基于私网访问同阿里云服务，包括访问企业其他VPC内部署的服务（如 Active Directory、堡垒机、RDS 等），以及阿里云公共云服务（如容器镜像服务 ACR、对象存储 OSS 等）。此时，可通过 ENI 挂载、云企业网（CEN/TR）私网接入、PrivateLink（PVL）私网连接等多种方式实现，详细架构设计请参考设计最佳实践；
IDC或他云基于私网访问阿里云服务：某IDC或其他云，访问阿里云的服务。同上，也包括访问企业在阿里云VPC内部署的服务，以及阿里云公共云服务。此时，可通过专线（详见IDC通过专线访问云服务）或 VPN （详见IDC通过VPN访问云服务）两种方式进行服务接入。

3.4.2 应用交付网络

SLB构建应用交付网络

如何将用户请求高效、可靠地送达后端应用服务，是应用交付网络设计要考虑和解决的问题，详细可参考ECS的应用交付网络设计和ACK容器的应用交付网络设计。

在将业务迁移至阿里云时，应用交付网络的架构设计需结合原有部署环境进行考量：

若业务原部署于其他公有云：通常可沿用其已有的分层解耦、弹性伸缩、高可用的设计模式，只需适配阿里云的网络与服务组件（如ALB、NLB等），实现平滑迁移。

若业务原部署于线下IDC：此时应用交付的架构设计往往会相对复杂，需重新梳理并重构交付链路。传统IDC中的应用交付常见模式包括：
- 依赖专用物理设备（如F5、Citrix ADC、硬件路由器/防火墙）实现流量调度与安全控制；
  - 基于自建软件负载均衡（如Nginx、OpenResty、HAProxy）部署在通用服务器上，承担反向代理、SSL卸载、限流等功能；
  - 混合架构：部分核心系统使用硬件设备，边缘或测试环境采用开源软件方案。

对于业务场景相对复杂的IDC业务迁云，更建议通过云计算理念重构应用交付体系。通过阿里云ALB/NLB等提供弹性、高可用的四七层负载均衡，构建安全弹性的应用交付网络，同时降低对物理设备和自维护中间件的依赖。

应用交付架构从IDC迁移至阿里云，往往需要做如下步骤的工作：

现状评估与需求对齐
1. 梳理业务资产：明确对外提供服务的业务资产，一共有哪些域名和IP，分别是通过四层还是七层的方式提供服务。
2. 梳理现有交付拓扑：明确IDC中DNS、负载均衡硬件、代理网关、防火墙等组件的部署方式、依赖关系及流量路径。
3. 梳理现有交付配置：明确每个业务从“DNS解析-负载硬件转发规则/代理网关转发规则-业务服务器”整个链路的配置。
云上架构设计
1. 阿里云交付组件选型：四层负载NLB、七层负载ALB、搭配全局流量管理（GTM）、DNS等。
2. 网络规划：在VPC内对云服务产品组件进行网络规划，如可用区选择、vSwitch交换机子网规划设计（在VPC网络架构设计中也有提及）、安全组与ACL策略精细化控制。
适配与改造
1. 已有设备转发规则的替换和翻译：将硬件负载均衡/Nginx/OpenResty等组件的转发规则逻辑，翻译成ALB/NLB的规则（业务是基于四层/七层协议进行转发？七层业务转发规则中的转发规则，如Host/Path的路由/重写/重定向等）。
2. 域名和证书管理：结合云解析DNS，统一使用SSL证书服务，实现端到端链路的支持。
联调测试与验证迁移
1. 确定迁移范围与优先级：按业务域、流量规模、改造难度划分批次。
2. 灰度引流：通过DNS权重等配置，逐步将流量切至云上。
3. 功能与性能压测：验证新架构在高并发、故障切换等场景下的表现，并逐步完成业务迁移。

【实战案例01：某IDC客户业务迁移至阿里云】⑦基于SLB构建应用交付网络

前置信息：基于上文“实战案例01”，已经完成了VPC的网络架构设计。那么，在VPC的网络架构设计中，因为有集群业务入口调度的需求，所以需要进一步规划业务入口的方案。

关键需求：①线下IDC通过多层设备实现入方向的流量调度，分别经过了 GTM、FW-DNAT、LTM、OpenResty，这里GTM主要实现基于运营商的IP调度、DNAT实现将公网地址转化成LTM私网地址、LTM实现7层业务调度、OpenResty则实现了自定义的业务转发规则，整体调度层级相当复杂，希望结合云服务特点进行简化；②当前自建了Nginx/OpenResty转发层，自定义规则的属性极强，经评估很多配置短期无法直接迁移至标准化产品，所以将Nginx/OpenResty转发层迁移至云上并做短期内保留；③业务主要基于7层Http/Https调度，所以需求主要是面向7层调度的应用性负载均衡。

《基于ALB构建应用交付网络》的架构设计：

负载均衡ALB架构：在整体方案架构中，基于上述需求，保留了Nginx/OpenResty，最终形成了DNS+ALB+NG/OR的架构，整体架构得到了有效简化。①公网ALB绑定EIP，BGP带宽天然支持多运营商IP接入，简化了GTM层；②ALB通过域名方式提供接入，DNS通过CNAME解析，将流量调度至ALB域名，然后将业务流量调度至ALB VIP（虚拟IP），从而从产品化角度简化了DNAT层；③同时，ALB产品本身支持多可用区部署，在ALB选型时使用与业务系统对应的A/B双可用区部署模式，保障了业务的高可用性。
配置迁移：梳理IDC物理设备配置，并翻译成ALB调度规则
- 配置梳理和翻译：如下图所示，首先基于业务完成IDC转发配置梳理。①以业务为粒度，从流量调度链路进行配置梳理。如：www.xx.com业务，在IDC架构中从“公网IP -DNAT私网IP - LTM私网转发规则 - Nginx/OpenResty规则”进行全链路盘点。②LTM配置盘点中，也要明确每个业务所需的转发特性（如监听超时时间、是否启用HTTP2.0、长连接、会话保持、轮询算法等）
- 基于ALB迁移配置并割接业务：基于配置梳理，将业务调度规则迁移至ALB配置中。并通过DNS将业务流量切换至ALB，完成业务割接。

【实战案例02：某他云客户业务迁移至阿里云】⑦基于SLB构建应用交付网络

前置信息：基于上文“实战案例02”，已经完成了VPC的网络架构设计。那么，在VPC的网络架构设计中，因为有集群业务入口调度的需求，所以需要进一步规划业务入口的方案。

关键需求：①业务提供GPS定位校准服务，接入终端主要是物联网终端设备，通信协议是四层TCP协议；②在VPC资源规划中，硅谷选择了AB2个可用区、法兰克福选择了ABC3个可用区，所以负载均衡资源也希望尽可能对齐；③在此基础上，定位的服务对时延有一定要求，所以希望SLB调度时延可以尽可能降低；④由于终端设备会在wifi/4g/5g不同的网络环境之间切换，但接入定位计算的一些中间状态需要保持连续性，所以网络环境切换时需要保持POD的长链接和亲和性，同样的终端需要调度至原POD。

《基于NLB构建应用交付网络》的架构设计：

由于业务是基于四层TCP协议接入，所以负载均衡选择了面向4层的网络型负载均衡NLB；
NLB同样与资源的高可用性对齐，在硅谷选择了AB2个可用区、法兰克福选择了ABC3个可用区进行部署；同时，NLB转发至POD的时延，在同可用区一般在1ms内，比跨可用区降低了2ms左右，也进一步缩短了通信时延；
调度算法方面，由于需要保障调度的亲和性，所以选择了NLB基于QUIC ID的Hash算法。终端设备通过与Quic网关建立 Quic连接，并携带终端CID，同时网关与POD进行Quic通信并分配访问CID；在此过程中，NLB基于QUIC ID Hash保障调度至同一Quic网关POD；当终端设备网络环境切换时，会基于Quic原生的连接迁移能力，保障POD连接不变，从而进行继续的数据传输

GA加速广域网应用交付

负载均衡架构解决了访问请求进入阿里云之后，如何到达后端服务的服务发现和服务连通问题。

随着企业出海，有不少情况下业务需要被跨地域甚至跨国访问，此时往往会遇到公网访问服务质量无法保障的情况，如时延很高、网络抖动、丢包率高等。为了改善跨地域客户端到业务应用之间的网络质量，此时需要通过GA加速广域网应用的交付，详细设计指南可参考GA加速广域网设计。

以标准型GA加速方案设计为例，在GA方案设计时需要明确以下几点：

GA的付费方式：通常推荐按量付费模式，此时包含了“实例费、CU费、流量费”三个计费项，详细可参考按量付费全球加速实例计费。
明确需要的加速区域：加速区域是您需要进行访问加速的区域。加速区域是阿里云地域的集合，每个加速区域包含一个或多个阿里云的地域，可参考加速区域。
明确服务所在地域：服务所在地域，是业务源站所在地域。通常，在GA配置时，我们会将需要被加速访问的业务源站加入GA的终端节点和终端节点组。说明：①GA的终端节点是客户端请求访问的目标主机，一个终端节点组可以添加多个终端节点。②通过指定要分发流量的地域，可以使终端节点组与监听相关联，系统将根据监听路由类型定义的转发方式将流量分配到与监听关联的终端节点组内的终端节点上。③关于GA的终端节点组和终端节点的介绍，可参考终端节点组与终端节点。
明确GA加速的传输网络质量类型：明确了加速区域和服务所在地域后，根据Web类业务是否具备ICP备案，可以按需选择对应的传输网络质量类型。详细可参考加速配置选型（按量付费）。
明确应用源站的接入方式：GA可支持通过域名CNAME和IP两种接入方式，可根据业务需求进行选择。详细可参考加速访问指定IP的后端服务、加速访问指定域名的后端服务。
转发策略设计：GA支持精细化的转发条件（域名、路径、HTTP标头、HTTP请求方法、Cookie、SourceIP、查询字符串）或更多的转发动作（转发至、重定向至、返回固定响应、重写、写入Header、删除Header、丢弃（阻断流量）），可以自定义转发策略及匹配优先级，详细可参考添加和管理转发策略。

【实战案例02：某他云客户业务迁移至阿里云】⑧基于GA加速广域网应用交付

前置信息：基于上文“实战案例02”，已经完成了VPC的网络架构设计。当业务按照VPC的网络架构设计部署到阿里云海外region后，考虑到国内员工需要基于公网访问法兰克福站点，所以需要设计面向广域网应用交付的GA加速方案。

《基于GA加速广域网应用交付》的架构设计：

前置条件：ICP备案
- 客户业务部署于德国法兰克福、美国硅谷等海外地域，中国内地的员工和合作伙伴需通过互联网访问境外业务系统进行日常运维与运营。按照中国内地合规要求，面向中国内地用户提供互联网服务的业务域名需完成ICP备案。因此，我们首先协助客户完成了业务域名的ICP备案，为后续接入GA加速服务做好准备。
方案设计：在GA方案设计中，我们重点明确了以下几个关键环节：
- 加速区域：由于员工和合作伙伴主要分布在北京，因此选择华北2（北京）作为GA的加速区域，即中国内地用户接入GA的就近上车点。
- 源站地域：即需要被加速访问的业务系统所在地域，为德国法兰克福和美国硅谷两地。
- 终端节点与终端节点组：业务部署于海外两地域VPC内的ECS实例上，我们将这些ECS分别添加为GA的终端节点，并按地域划分为两个终端节点组。
- 监听与转发配置：源站业务系统使用HTTPS（443端口）和HTTP（80端口）协议，无其他特殊需求，因此我们基于协议和端口号配置了对应的GA监听器。针对HTTPS监听，上传了业务域名对应的SSL证书，确保传输链路的安全性与数据可靠性。
- 付费方式：GA实例选择按量付费，灵活适配业务用量，降低初期成本。
- 接入方式：采用CNAME接入方式，将业务域名指向GA分配的加速域名。
- DNS解析配置：GA实例配置完成后，在DNS中新增一条CNAME记录，将业务域名解析至GA加速域名。该记录的解析请求来源（ISP）限定为中国内地，与原有DNS解析记录并行存在、互不冲突。

完成上述配置后，当中国内地的客户端发起访问请求时，DNS会将其引导至GA北京加速节点。请求就近接入后，经监听器校验处理，再根据流量调配策略与终端节点健康状态，智能转发至法兰克福或硅谷的终端节点组，从而实现跨境访问的加速与高可用保障。

3.4.3 VPC与VPC互联网络

基于“云企业网CEN/TR”构建VPC互联网络

不同VPC内的服务器之间如果需要私网互通，先要打通VPC间的连接和路由，在大量（一般3个以上）VPC间需要互通时，通常使用云企业网CEN/TR（Transit Router）构建VPC互联网络。

云企业网CEN/TR方案，是一种基于阿里云的全局网络管理服务帮助企业构建一个集中化、可扩展且高效的私有网络架构。适用于同地域/跨地域、同账号/跨账号的多VPC、复杂网络场景，详细可参考CEN构建云上跨地域网络和不同VPC的服务器通过转发路由TR（Transit Router）互访。

【实战案例02：某他云客户业务迁移至阿里云】⑨基于TR/CEN构建VPC互联网络

前置信息：基于上文“实战案例02”，已经完成了VPC的网络架构设计和公网连接出入口的架构设计。但是客户整体业务分地域部署，构建异地容灾架构，因此不同地域之间的VPC需要私网互通，最终选择TR/CEN构建跨地域网络互通。接下来则进行“基于TR/CEN构建VPC互联网络”的架构设计。

关键需求：①法兰克福和硅谷地域的VPC之间，需要基于私网进行数据互通。②后期中国内地地域也有业务部署到云上，希望跨境多VPC之间的组网简单易用。
《基于TR/CEN构建VPC互联》的全球一张网架构：
- 虽然目前只有欧美两个地域的VPC，但随着业务的发展会规划中国内地甚至更多的VPC，VPC之间均需要数据同步的私网互联。基于未来的VPC规模，对等连接的方案扩展性较弱，需要手动为每个VPC配置路由，运维管理复杂度也比较高。所以，本次迁云给客户设计了基于TR/CEN构建VPC互联架构。
- 由于VPC之间两两都需要数据同步，通过TR构建多地域VPC fullmesh互联的组网模式，通过多地域下的TR构建多条跨地域连接，本期先打通硅谷和法兰克福VPC，未来可平滑接入和打通北京VPC。

基于对等连接构建VPC互联网络

当需要互联的VPC数量相对比较少的时候，也可以通过创建VPC对等连接/VPC Peering，并为两端VPC分别配置路由，构建VPC两两互联的私网通道。对等连接功能支持同账号/跨账号、同地域/跨地域VPC互连，配置前请确保两端VPC的网段不重叠。详细可参考不同VPC的服务器通过VPC对等连接互访。

提醒：VPC对等连接通常适用于2个VPC点对点直连场景；若涉及3个及以上VPC，推荐采用云企业网CEN/TR方式。

【实战案例03：某程序化广告客户】基于对等连接构建VPC互联网络

前置信息：某广告客户，其众多上下游渠道伙伴已部署于阿里云xx地域，经过决策决定将业务迁移至阿里云，同时希望与上下游渠道伙伴的VPC建立私网互通，提升业务协同效率并降低网络带宽成本。

由于客户与其上下游伙伴业务都部署在阿里云的同一个地域，对等连接在同地域VPC互联时不收费，所以本次给客户设计了最为节省方案的《基于对等连接构建同地域跨账号之间的VPC互联网络架构》：

客户作为ADX广告交易平台的角色，通过VPC Peering对接了两个流量比较大的SSP和DSP。
分别创建了两个VPC Peering的实例，以其中一个为例：①用户在账号下创建VPC Peering“PCC-VPC0VPC1”，打通和伙伴1的VPC1的连接，由于涉及跨账号VPC打通，需要伙伴1在账号下接受连接请求；②在用户VPC0的系统路由表中添加路由条目，访问VPC1 10.0.0.0/16网段的路由下一跳为VPC Peering实例“PCC-VPC0VPC1”；③同样，伙伴1的VPC中，访问用户VPC 192.168.0.0/16网段的路由下一跳也是VPC Peering实例“PCC-VPC0VPC1”；④双向路由配置完成后，即可实现资源互访。
基于VPC Peering方案，整个RTB交易链路全程走阿里云内网，无需公网，实现低延迟、高安全、零公网带宽成本的高效协同。
特别提醒：
- 对等连接的方案虽然节省成本，但前提是两个VPC地址不能冲突。
- 同时，程序化广告行业中，业务上下游之间的访问都是单向的，这属于下游主动访问上游服务地址的场景，更推荐“基于PrivateLink 构建服务私网接入”的方案，此方案可有效解决地址冲突的问题。

CEN/TR 与 Peering方案对比：VPC互联网络构建，有VPC对等连接、场景化组网实现多VPC互联两种方式，但两者在使用场景上略有差异，需要根据“规模、功能、成本、带宽”等需求综合考虑。详细可参考：VPC互联。

3.4.4 VPC与其他环境互联

专线构建混合云/多云网络

在搬站上云的过程中，经常会遇到优先将一部分业务（如服务器）先搬迁到云上，一部分业务(如数据库/大数据)仍保留在线下。

这种云上云下业务协同或多云协同场景下，可以通过物理专线和阿里云云网络产品实现云上云下或多云之间的业务协同，快速构建安全、稳定、弹性的混合云或多云协同网络，以满足客户的云化进程，详细可参考专线构建混合云/多云网络。

【实战案例01：某IDC客户业务迁移至阿里云】⑧基于专线构建混合云/多云网络

前置信息：基于上文“实战案例01”，已经完成了VPC的网络架构设计和公网连接出入口的架构设计。但是，由于短期内仍需要保留一部分业务在线下IDC，所以此时VPC需要与IDC进行私网互通，最终选择了双专线方式构建混合云架构。那么，接下来则进行“基于专线构建混合云/多云网络”的架构设计。

关键需求：①VPC与IDC业务互通同样需要保障容灾能力；②目前云上只有一个VPC，后续随着业务增加可能会新增VPC，希望多VPC与专线互联的组网简单易用。

《基于专线构建VPC与IDC互联网络》的架构设计：

从高可用角度，设计了2*10Gbps的双专线互联的架构。同时，在VBR与IDC之间采用BGP动态路由协议，应对线路故障时的自动切换。在专线多链路情况下，也有“主备”、“负载”多种专线冗余方案可以选择，本次采用了“BGP+BFD主备冗余”的专线模式。
考虑未来业务发展，需要实现多VPC与IDC互联，所以专线VBR采用了基于ECR+CEN/TR的方式上联至VPC，后续多个VPC均可通过TR加入云企业CEN形成全球一张网的互联架构。
在申请专线的接入环节，流程上采用了“一站式上云服务”，有效提升了专线的交付效率。通过登录“高速通道产品控制台”，选择“一站式上云服务”，点击“创建一站式上云服务”，提交“一站式上云服务申请单”，按照申请单信息填写阿里云接入信息和完成线路ID创建。完成后返回和刷新控制台，点击线路ID右侧“获取帮助”，即可进群获取阿里云专家对专线交付的服务支持。

IPSec VPN构建分支上云网络

除了专线方案，也可以使用IPsec-VPN构建云上VPC与其他环境（IDC/其他云）的私网互联。

IPsec-VPN 基于 IPsec 协议，提供站点到站点的加密通信能力，用于安全连接本地数据中心与云上虚拟私有云VPC，广泛应用于混合云组网、专线容灾备份等场景。详细可参考IPsec-VPN构建分支上云网络。

【实战案例02：某他云客户业务迁移至阿里云】⑩基于IPSec VPN构建分支上云网络

前置信息：基于上文“实战案例02”，已经完成了VPC的网络架构设计。当业务按照VPC的网络架构设计部署到阿里云后，考虑到跟服务商需要私网互通，最终选择了IPsec VPN方案构建与服务商分支网络互通。那么，接下来则进行“基于IPSec VPN构建分支上云网络”的架构设计

关键需求：客户业务主要提供GPS定位服务，其定位信息接入了多家上游数据服务商伙伴，目前主要通过私网Peering方式互通。业务部署到阿里云后，需要保持跟数据服务商的私网交互，本次采用IPsec VPN的方案实现。

《基于IPSec VPN构建分支上云网络》的架构设计：

在阿里云VPC内部署 VPN 网关，作为数据服务商的上云私网入口。数据服务商部署支持标准 IPsec 协议的CPE设备，通过公网建立站点到站点的IPsec VPN隧道，每条IPsec连接采用双隧道冗余架构，加密传输双方私网流量。

SSL VPN构建移动办公上云网络

在现代混合办公与云化IT架构背景下，企业员工无论身处办公室、远程居家还是出差途中，均需安全、高效地访问部署在公有云VPC中的内部业务系统（如ERP、CRM、数据库或开发测试环境）。

此时，可采用SSL VPN构建移动办公上云网络，办公电脑/移动端安装SSL VPN客户端，通过SSL VPN接入阿里云VPN网关，实现从办公端到阿里云VPC的接入，详细可参考员工通过SSL VPN访问VPC内服务器。

【实战案例04：某客户】基于SSL VPN构建移动办公上云网络

前置信息：某机器人算法公司，利用阿里云PAI-DSW平台开展AI模型研发，涉及大量敏感数据与核心算法，对访问安全性和网络隔离性要求极高。然而，研发人员办公地点不固定，常需在出差或远程场景下接入开发环境，若直接通过公网访问DSW，不仅存在数据泄露风险，也难以满足合规审计要求。因此，客户需要一种既能打通VPC私网、实现DSW安全访问，又能灵活适配移动办公场景的远程接入方案。

基于以上背景，设计了《基于SSL VPN构建移动办公上云网络架构》。

在部署DSW实例的同一VPC内创建阿里云SSL-VPN网关，研发人员通过终端设备（如笔记本电脑）使用SSL-VPN客户端安全接入该VPC，实现远程办公场景下的私网级访问（无需暴露DSW公网IP）。
通过SSL-VPN在保障端到端加密的前提下，实现研发人员随时随地以私网方式安全访问DSW进行AI模型研发。
从“远程开发、数据读取、模型训练、服务发布”的端到端业务流转，均在统一的VPC安全边界内闭环完成，仅SSL-VPN入口作为受控的远程接入点。极大降低了攻击面，同时满足移动办公灵活性与企业级数据安全要求。
- 通过SSL-VPN将终端接入VPC后，研发人员可直接在DSW中开展模型实验。
- DSW通过VPC内网访问同区域的OSS存储桶，高效读取训练数据，同时，利用VPC内的GPU资源进行本地化模型调试。
- 当代码和配置就绪后，通过云效CI/CD流水线触发分布式训练任务，任务被提交至PAI-DLC（分布式训练集群），DLC同样部署在该VPC或通过VPC对等连接/高速通道打通的可信网络中，确保训练过程全程处于私网环境。
- 训练完成后，模型通过PAI-EAS服务一键部署为API接口，EAS实例同样运行在VPC内，可对外提供受控访问，也可仅供内部系统调用。

4 业务割接实施指导

声明：本章节仅用于业务割接实施参考，详细的业务割接方案设计还需要根据业务情况进行设计。

前面的章节对业务迁云架构设计的流程做了系统性描述，基于架构设计完成云上计算/网络/存储/数据库等资源的部署和配置后，接下来则要开展迁云的具体工作。下面以最常见的互联网业务为例拆解业务割接流程。

4.1 流量割接总体策略

割接维度选择：

流量割接的核心逻辑建议以域名为最小割接单元，原因如下。

域名是业务流量的入口，天然对应一个或一组业务系统
DNS 切换是最常见、风险最可控的流量调度手段，支持灰度和回退
域名粒度便于与业务方对齐责任边界，便于沟通和验收

在域名维度之上，建议叠加 业务优先级维度 进行分批：

第一批：非核心/边缘业务（如内部管理系统、测试环境、静态资源站点）
第二批：中等重要性业务（如营销页面、非实时数据服务）
第三批：核心业务（如交易链路、用户认证、核心API）

割接模式

模式	适用场景	描述
一次性割接	非核心业务、低流量业务、无状态服务	DNS 直接全量切换至阿里云，配合监控快速确认
灰度割接	核心业务、高流量业务	通过 DNS 权重/地域解析，逐步将部分流量导向阿里云，观察稳定后再全量切换
蓝绿切换	有严格 SLA 要求的业务	新旧环境并行运行，通过负载均衡或 DNS 瞬时切换

割接时间窗口选择原则

选择业务低峰期（通常为凌晨或周末）
预留充足的观察窗口（建议至少 2-4 小时）
核心业务割接需提前与业务方确认维护窗口
考虑 DNS TTL 的生效时间（建议割接前将 TTL 降低至 60s-300s）

4.2 割接前准备工作

环境就绪确认

检查项	确认内容
计算资源	ECS/容器集群部署完成，应用已发布并通过测试
存储资源	数据已完成全量同步+增量同步，延迟在可接受范围内
数据库	数据同步链路正常，主从延迟在秒级以内，数据一致性校验通过
网络链路	VPC内路由正确，安全组/ACL等策略正确，SLB/NAT等关键网元产品的配置完成，与互联网/其他环境互联网络连通性正常
DNS	新解析记录已预配置（但未生效或权重为0），TTL 已降低
SSL证书	证书已部署至阿里云 SLB/CDN/WAF，有效期确认
监控告警	云监控、SLS等已按需部署，关键指标告警已配置

2. 数据同步确认

这是割接最关键的前提条件：

数据库：DTS/其他同步工具持续运行，确认同步延迟、数据一致性
文件存储：OSS 数据迁移完成，增量同步持续运行
缓存：Redis 等缓存需评估是否需要预热，还是依赖应用层回源重建
消息队列：确认消息不丢失的切换策略（如双写、消费位点同步）

3. 割接清单编制

编制详细的割接清单，建议包含：

割接批次：第X批

业务名称：XXX

域名：xxx.example.com

当前解析：指向 IDC IP x.x.x.x

目标解析：指向阿里云 SLB IP y.y.y.y CNAME xx.xx.com

割接模式：灰度/一次性

割接负责人：XXX

业务验证人：XXX

预计割接时间：YYYY-MM-DD HH:MM

回退方案：DNS 切回原 IP

验证项：[列出具体验证步骤]

4. 割接演练

正式割接前，建议至少完成一次全流程演练：

在测试环境或非核心业务上验证割接流程
验证回退流程的可操作性和时效性
确认各角色职责和沟通机制
记录演练中发现的问题并修正

4.3 割接实施流程

第一阶段：割接启动

召开割接启动会，确认各方就绪
建立实时沟通渠道（钉钉群/电话会议桥）
确认数据同步状态（延迟、一致性最终确认）
确认阿里云侧应用服务、负载均衡健康状态
宣布割接开始，进入变更冻结期（禁止其他变更）

第二阶段：DNS 切换

以一次性割接域名为例

步骤1：确认 TTL 已降低并生效

步骤2：直接修改 DNS 解析至阿里云目标地址

步骤3：等待 DNS 生效（1-2 个 TTL 周期）

步骤4：验证业务功能和性能

步骤5：稳定观察

以灰度割接域名为例

步骤1：降低 DNS TTL（若未提前完成）

- 将 TTL 从默认值降至 60s

- 等待至少一个原 TTL 周期，确保旧缓存失效

步骤2：小流量验证（权重 10%）

- 在 DNS 解析中添加阿里云目标地址，设置权重比例 9:1

- 或使用智能解析，将特定地域/运营商流量导向阿里云

- 观察期：30分钟-1小时

- 关注指标：错误率、响应时间、业务成功率

步骤3：扩大流量比例（权重 50%）

- 调整权重为 5:5

- 观察期：1-2小时

- 重点关注：阿里云侧资源水位、数据库连接数、缓存命中率

步骤4：全量切换（权重 100%）

- 将 DNS 全部指向阿里云

- 保留原 IDC 解析记录但权重设为 0（便于回退）

- 观察期：2-4小时

- 全面验证：功能验证 + 性能验证 + 业务指标验证

步骤5：稳定观察

- 割接后持续观察 24-72 小时

- 确认无异常后，恢复 DNS TTL 至正常值

第三阶段：业务验证

每次流量切换后，需执行标准化验证：

验证类别	验证内容
连通性验证	域名解析是否正确指向阿里云、端到端可达性
功能验证	核心业务流程走通（登录、查询、下单、支付等）
性能验证	响应时间、吞吐量与割接前基线对比
数据验证	数据读写正确性、数据同步无异常
监控验证	错误率、5xx 比例、业务成功率、资源水位
安全验证	WAF/安全组策略生效、HTTPS 证书正常

4.4 回退方案

回退触发条件

明确定义需要回退的场景，避免决策犹豫：

核心业务功能不可用
错误率超过阈值（如 >5%）
响应时间劣化超过阈值（如 >200%）
数据不一致或数据丢失
割接窗口内问题无法定位和解决

回退操作流程

步骤1：决策回退

割接负责人确认回退决策
通知所有相关方

步骤2：DNS 回切

将 DNS 解析切回原 IDC/他云地址
由于 TTL 已降低，预计 1-5 分钟内大部分流量回切

步骤3：数据回退处理

如果割接期间产生了写入数据：产生的增量数据需要反向同步回IDC或标记为需人工处理的数据
如果使用了数据库主从切换，需执行反向切换

步骤4：验证回退

确认业务恢复正常
确认数据完整性

步骤5：复盘

分析失败原因
修正方案后重新安排割接

4.5 割接后收尾

在云迁移项目的全周期管理中，还需要制定分阶段精细化管控策略以确保业务平稳过渡。通过分阶递进的管控措施，全面保障迁移过程的可控性及云环境的长效优化。

如，短期（割接后1-7天）实施增强监控机制，保留原IDC环境作为应急回退保障，持续验证未割接关联业务的数据同步完整性，并主动收集业务方运行反馈；中期（1-4周）在完成全部业务迁移后，终止IDC至阿里云的数据同步链路，开展新旧环境性能基线对比分析，同步完善云平台监控告警、数据备份及容灾体系，并将DNS TTL调整至标准时效；长期（1-3个月）基于业务稳定性验证结果释放原有基础设施资源，完成项目闭环验收与技术总结，最终聚焦云上架构持续优化，通过成本治理与性能调优实现云计算价值最大化。