1. VPC概述
专有网络VPC可以帮助用户基于阿里云构建出一个隔离的云上网络环境，并可以自定义IP 地址范围、不同网段、路由表和网关等。此外，也可以通过专线连接方式实现云上VPC与传统IDC的互联，构建混合云业务。基于以上VPC的优秀特性，用户可以通过点击鼠标等简单操作，一分钟内便可“交付”一整套网络平台，大大节约用户网络基础设施建设的成本和时间。
2. VPC规划背景
对于专有网络VPC，用户可以完全掌握自己的虚拟网络资源的管理和操作，结合用户业务实际场景进行创建。然而，当用户在专有云上根据资源申请规范创建VPC实例时，有时对创建平台资源的容量和用户自身业务的联系比较模糊，从而产生种种疑问。例如某用户考虑业务上云前，需要创建多少个VPC？每个VPC创建多少个vswitch？每个VPC创建需要使用多少个地址段？VPC网络内资源能被哪些网络访问？该预留多少资源为未来的业务拓展做准备等一些问题。
反之，如不考虑规划环节，直接创建或许能短期确实能解决当时的用户业务需求，但随着用户业务的开拓和发展，业务访问的流量不断加大，业务数据量逐渐增加，云资源饱和等问题会逐步显现。针对这些问题，要么删除重建，要么业务系统迁移，而且在解决过程中仍需考虑业务数据迁移的稳定性和安全性，时时刻刻保障业务在不中断不故障的情况下正常运行。种种问题追根溯源是当初规划设计不合理，导致重复的工作量或风险，最终发出一声早知如此何必当初的感叹。
总而言之，良性的资源规划能让用户业务和平台系统更加稳固，运行更加长远和高效。非良性的资源规划，后期发生种种的大小问题只是概率问题。所以我们要用架构师的思维意识去思考，去解决万事“开头”的问题，即首次规划的问题。
本篇文章旨在介绍VPC创建实例资源前的规划与评估，贴合用户自身业务场景，从而合理有序的规划创建VPC和后续云资源。本文内容仅做参考，不可作为具体解决方案使用。不同行业不同项目情况不同，所以用户可参考本文具体问题具体分析。
3. 行业网络架构
3.1 规划设计背景
图1:金融行业典型的整体网络逻辑结构
完整的网络系统架构需要考虑用户自身业务实际情况。如上图所示，图中展现的是某金融行业典型的整体网络逻辑结构。在实际应用中，网络架构需要遵循以下设计原则：
- 层次化设计：每个层可以看作是园区网内一个具有特定角色和功能的结构定义良好的模块，层次化的设计结构，易于扩展和维护，降低了设计的复杂度和难度。
- 模块化设计：每个模块对应一个部门、功能或业务区域，可根据网络规模灵活扩展，部门或区域内部调整涉及范围小，容易进行问题定位。
- 冗余设计：双节点冗余性设计可以保证设备级可靠，适当的冗余提高可靠性，但过度的冗余不便于运行维护。
- 对称性设计：网络的对称性便于业务部署，拓扑直观，便于协议设计和分析。
专有云网络架构（如上图专有云区域）也是根据以上原则进行设计的。VPC网络是在物理网络基础上叠加的一种虚拟网络，首先运用一种基于Overlay的技术，其技术核心是重新构建逻辑网络平面，其技术手段的关键是采用隧道技术实现L2oIP的封装。通过隧道实现各虚拟机之间的二层直连，实现大二层网络结构。其次，Overlay网络仅仅为逻辑上的二层直连网络。其依赖的物理网络是传统的路由网络，该路由网络是三层到边缘的网络。
图2:VPC逻辑隔离结构
通过以上介绍，已基本了解网络规划设计的重要性。而做为物理网络架构之上的VPC虚拟网络，又是整个云网络规划中的重要部分，前面概述介绍云网络用户可自定义的特殊性，所以该规划更贴近于用户的业务。
所以本文特别提醒，在创建VPC资源实例时，一定要多结合用户业务的实际情况，一旦创建好后就很难更改了。
3.2 VPC资源规划原则
VPC的资源规划基本遵循以下几个主要原则：
- 规划安全性：创建VPC资源的实例、数据、访问等安全性的保障。
- 对外互访性：VPC资源需要有已授权的外部访问权限，对未授权的不做访问。
- 资源预留性：对于业务的发展带来的云资源扩展，需提供预留空间。
- 资源共享性：VPC实例级的资源是否需要被其它的部门共享访问。
3.3 业务评估要素
结合VPC资源规划原则及自身业务情况，本节将以在用户使用者的角度评估创建VPC资源前的各种业务因素。具体业务因素如下：
- 业务用途：用户的业务划分是否区分生产和测试环境等类别？
- 业务互访：用户生产或测试业务内的子系统有无强互访需求？
- 业务规模：用户业务系统的规模决定了云平台实例资源的数量？
- 地址预留：用户业务拓展需考虑未来两到三年的VPC容量地址的预留？
- VPC区别：用户相同业务划分在同一个VPC下，不同业务划分在不同VPC下？
- vswitch区别：用户相同业务的子系统划分在同vswitch下，相同业务但不同子系统划分在不同vswitch下？
- 对外互访：用户云上业务是否有对云外并网访问需求？如何避免地址冲突？
- 公私模式：用户云上业务是“公有云模式”还是“私有云模式”，VPC与其它网络互访的区别？
- 五元组：用户云上业务是否具备五元组级安全访问控制能力？
- 流量控制：用户云上业务与云上其它业务互访，是绕云外专门防火墙做流管控，还是云内指定打通?
- 实例共享：总部单位用户业务的资源实例是否需要与分支单位的资源实例共享?
- 命名规范：用户云上业务的实例级资源命名是否有规范要求？
- 容灾特性：容灾多可用区场景下，用户业务应用是否需要进行冗余？
4. VPC资源规划
根据下面业务评估要素所提出的论点问题，后续将逐一给出建议性的解决方案。
4.1 业务用途
问题
用户的业务划分是否区分生产和测试环境等类别？
图3:VPC业务用途分类
推荐方案
根据用途来分，VPC创建主要分以下四大类，分别被不同的部门或人员使用。
- A类：生产VPC
特征：具备高安全性、绝对隔离性，具备等保标准。
范围：只与用户核心内网业务互通，除用户内网以外的网络保持相对逻辑隔离和物理隔离。 - B类：开发VPC
特征：具备相对安全性且与外网互通可进行流控的标准。
范围：能够与用户IDC的核心内网业务、半开放业务互通，例如测试业务等。 - C类：运维VPC
特征：具备可管理性，可视化和高可用性。一般与用户侧管控中心网络并网。
范围：将运维使用到的监控服务器、发布服务器及堡垒机等统一配置在该VPC。 - D类：租户VPC
特征：具备接入租户级对外界开放的低风险业务。
范围：适用第三方租户并网接入，对租户级客户来说核心业务。租户级的业务跟根据需求向云运维的客户方提出相关规划需求和安全需求。
4.2 业务互访
问题
用户生产或测试业务内的子系统有无强互访需求？
图4:VPC实例资源互访
推荐方案
用户生产业务或测试业务内如有两个及以上子业务，且存在强依赖互访关系，建议将两个系统划分到同一个VPC下。而生产VPC和测试VPC除非特殊业务需求，一般是强隔离。生产测试通常不建议做互访打通。
此外业务互访还涉及与用户侧的互访，这就涉及VPC并网的操作，其并网操作规范又明细涉及链路规范、地址路由规范、安全组规范、增删操作规范、并网窗口要求、并网后测试等规范，这里就不重点展开介绍，如对此感兴趣可联系本文作者。
优点
- 能直接互访。
- 避免了多次网络打通变更。
- 减少网络数据通路路径的排障点。
4.3 业务规模
问题
用户业务系统的规模决定了云平台实例资源的数量？
图5:VPC多vswitch规模
推荐方案
- 首先，即使只使用一个VPC，也尽量使用至少两个vswitch，并且将两个交换机分布在不同可用区，这样可以实现跨可用区容灾。
- 其次，使用多少个vswitch还和用户业务系统规模、系统规划、数据量有关。如果前端系统都可以被公网访问并且都有主动访问公网的需求，考虑到容灾，可将不同的前端系统部署在不同的vswitch下，而后端系统部署在另外的vswitch下。
优点
- 资源功能准确
- 业务职能分类清晰
注释
可用区是指在同一地域内，电力和网络互相独立的物理区域，在同一地域内可用区与可用区之间内网互通。
4.4 地址预留素
问题
用户业务拓展需考虑未来两到三年的VPC容量地址的预留？
图6:VPC地址规划预留
推荐方案
在业务满足当前需求的前提下，考虑未来业务的发展预期，一般未来业务发展通常可预见一到三年范围内为参考，五年以上待定。需预留几个大段空闲地址段容量。例如VPCA.B.C.0/23，创建时扩展更新为A.B.C.0/20。这样从2个C变成16个C，剩余14个C做备用给未来三年的资源业务使用。
优点
- 避免实例地址资源饱和，引起资源铲掉重部或迁移到新创的大段地址。
注释
VPC一旦创建，私网地址段不可以更换
4.5 业务异同
问题
用户相同业务类别，划分在同一个VPC下，不同业务划分在不同VPC下？
图7:VPC用户业务环境分类
推荐方案
根据用户不同且没有依赖关系的业务，建议规划独立VPC，进行隔开，不建议全部在同一个VPC内或同一个vswitch内。
优点
- 安全隔离
- 灵活管理
- 方便运维
- VPC并网范围精确
4.6 vswitch区别
问题
用户相同业务的子系统划分在同vswitch下，相同业务但不同子系统划分在不同vswitch下？
图8:VPC用户资源分类
推荐方案
例如，vswitch-1下部署ecs，vswitch-2部署rds等。
rds经典网络类型可根据实际需求去部署。
优点
- 地址比较在统一范围。
- 方便区间地址段地址管理。
- 识别度高，地址区间固定。
4.7 对外互访
问题
用户云上业务是否有对云外并网访问需求？如何避免地址冲突？
图9:VPC用户资源互访
推荐方案
列举出有对外访问需求的VPC，并将该类地址进行“私有云模式”，该类的VPC地址段使用不同网段。
创建VPC资源前要考虑下用户侧的网络地址段、云内地址段、以及其它VPC的地址段。尽量不要有相同或地址重叠的现象。
优点
- 避免因地址产生冲突，导致相同地址段“二选一”。
- 避免多一层nat地址转换层的维护。
- 避免业务访问受到影响。
补充
- “公有云模式”，公有云上的VPC相互之间没有关联关系。任意定义网络资源都不影响其他的VPC的访问或被访问需求。
- “私有云模式”，VPC相互之间有地址段的关联关系，创建时需要考虑别的VPC地址段是否一致。否则业务相互访问时会因地址相同而冲突，引起网络不通。
4.8 公私模式
问题
用户云上业务是否确定“公有云模式”还是“私有云模式”，VPC与其它网络互访的区别？
图10:VPC用户环境公私网互访
推荐方案
公有云模式：所有VPC内保持绝对隔离和独立，没有任何VPC与VPC、VPC与IDC之间的互访需求。全部采用公网地址为源访问的方式，类似现在的公有云。
私有云模式：VPC对外有互访需求，前提是地址段不冲突。
两种模式二选一，选了公网地址（数据流经过ISW）就不能私网（数据流经过CSW），遵循公私网原理。
优点
- “公有云模式”对于用户来说，不用顾虑云内全量地址相同的问题。
- “私有云模式”：地址不需要像公有云中间经过一层地址转换，直接寻址路由可达。
4.9 五元组
问题
用户云上业务是否有五元组级安全访问控制需求？
图11:VPC内部资源对外安全访问
推荐方案
有的用户业务有高安全等级的要求，用户业务端到端限制，使用五元组进行流控，做精确端级访问控制。
- ECS：安全组
- SLB/RDS：白名单
- 用户IDC：业务数据流经过云边界，建议使用安全防火墙。
优点
- 安全管理
- 访问控制
4.10 流量控制
问题
用户云上业务与云上其它业务互访，是绕云外专门防火墙做流管控，还是云内指定打通?
图12:VPC资源对外流量管控访问
推荐方案
用户提出云内VPC流量必须经过防火墙管控。
- 方式一：
做云外绕行变更，数据流经过云边界用户侧防火墙。并通过防火墙做流控，控制流量的出和入方向。
- 方式二：
云内做高速通道打通，中间会经过地址转换，终端级做流控。
优点
- 经过防火墙，安全策略限制更加完善，需用户维护。
- 运用高速通道，流量绕行节点少，延迟相对较低。
4.11 实例共享
问题
总部用户业务的资源实例是否需要与分部的资源实例共享?
图13:VPC资源对上下级部门访问
推荐方案
例如总部为一级部门，分部为二级部门。
用户需求：
1.分部要看到总部的实例资源，则需要开通VPC共享。
2.分部不能看到总部的实例资源，则不需要开通VPC共享。
优点
- 鉴权隔离
注释
DT或ASCM，一级部门能够看到二/三/四级部门创建的所有VPC内资源。上级部门只对下级部门有读写权限。
不开通共享，则三级部门看不到二级部门的资源；
开通共享，则三级部门能够看到二级部门的资源。
以上内容均需根据用户的实际需求来定，例如省级用户需访问地市级用户的资源，而地市级不需要访问省级的资源或同等地市级的资源。
4.12 命名规范
问题
用户云上业务的实例及资源是否有规范要求？
图14:VPC资源命名规划
推荐方案
随着用户需求扩大，VPC逐渐增多。如果一个项目使用20个VPC，或每个VPC内都有大量的云实例资源，便需运用VPC的命名规范，通过规范进一步增强实例的可读性。
参考VPC命名规范：xxx业务_xxx系统_xxx服务
例如：
- 生产环境_考勤系统_人脸识别服务。命名：SCHJ_kqxt_RlsbServer
- 测试环境_测试系统_鉴权服务。命名：TEST_cs_JQServer
优点
- 增强识别度
- 避免误操作
4.13 容灾特性
问题
容灾多可用区场景下，用户业务应用是否需要进行冗余？
图15:VPC资源冗余规划
推荐方案
多region环境下，创建不同region的VPC，业务分别部署在不同region场景下，ecs等实例资源相应部署。
单region多zone环境下，创建VPC后再创建不同vswitch部署在不同zone下，业务分别部署在相同vpc下不同zone下，ecs等实例资源相应部署。
优点
- 资源高可用
- 业务高可用
- 有效保障用户数据安全
5. 规划连连看
如果你是项目运维onwer，请根据以下用户项目特征，该如何选择合适的规划推荐给用户？
通过对以上要素点的逐一解析，已基本掌握了VPC资源规划实例的能力，现在我们做个小游戏：连连看。假如你是项目的架构师，你会建议用户如何选择。
如图，以金融行业不同性质单位为例，通过连线的形式匹配要素。通过用户业务特征和13个要素的互联做匹配，加深对VPC资源规划的理解。
图16：连连看
图中箭头是作者尽量贴合实际场景后给出的参考答案，专有云和公有云的VPC规划基本适用。答案有很多种，更加准确的答案还需读者自己去思考去摸索。
你连对了吗？
我们是阿里云智能全球技术服务-SRE团队，我们致力成为一个以技术为基础、面向服务、保障业务系统高可用的工程师团队；提供专业、体系化的SRE服务，帮助广大客户更好地使用云、基于云构建更加稳定可靠的业务系统，提升业务稳定性。我们期望能够分享更多帮助企业客户上云、用好云，让客户云上业务运行更加稳定可靠的技术，您可用钉钉扫描下方二维码，加入阿里云SRE技术学院钉钉圈子，和更多云上人交流关于云平台的那些事。