序

• 本文基于AWS作为云厂商进行介绍，其他云平台或自建云可以参考相关替换产品。
• 这个解决思路弹性较好，比较适用于很多应用场景中，在具体场景中进行裁剪或者修改来满足需求。

基础服务

• VPC（私有网络，隔离的网络环境）
• 子网（有些称为交换机，可以通过不同的网络访问的需求类型来进行划分，来满足较复杂的场景）
• 路由表
• Internet网关
• NAT网关 （类似路由器）
• 弹性IP（不推荐使用自动分配的公网IP，需要绑定弹性的公网IP，一般应用场景中不会使用过多的公网IP）
• 安全组（实现防火墙）
• 对等网络 （aws跨区域的连接）
• VPN （用于企业网和云上环境的连接，以及跨云厂商的连接）

需求

• 环境需求：测试环境（非生产环境）（开发环境，测试环境，UAT环境等），生产环境（预发布，灰度，生产环境等），云下IDC（企业网，本地开发环境，本地联调环境等，这个案例中生产环境都是在云上环境中）
• 云上环境需求：多可用区，跨地区场景
• 满足弹性的设计需求

实践

整体设计逻辑基本是一个弹性的设置方式，既可以满足初期的快速设置的需求，又可以满足中后期的复杂场景。

在项目初期一定要做网络规划

VPC的实践

VPC主要的特点是带来了一个隔离的网络环境，所以主要的划分思路也根据他的特性来划分。

在一般的开发过程中会区分好多环境，例如测试环境，UAT环境，开发环境，灰度环境，生产环境，预发环境等等，其实总的来看就可以分成生产环境和非生产环境，两个区域把这个问题进行简化，这里可以看主要的区分依据可以是数据的隔离性，按照这个思路，这两个环境基本不会进行相互的连通，所以这两个环境就需要使用两个VPC，这里需要注意的是类似测试环境中的开发联调的环境，UAT的环境等等，可以都归属于测试环境，测试环境和生产环境的区别可以理解成生产环境，和非生产环境，这里会引发问题是不知道一些服务或者机器资源等要归属到哪个环境中，这里判断的条件是数据的环境归属，因为数据可以很简单的进行生产环境和非生产环境的区分，对于服务的区分就可以通过当前服务操作的数据进行环境的区分，按照这个思路基本就可以解决服务归属问题了。这样生产环境也就会处以一个较为封闭私有有环境中，也可能减少一些误操作导致的问题。

这里在日常的使用中，还会出现些问题，比如有些数据分析类的服务，是测试版本的代码，但是可能需要读取生产的数据进行开发。如果出现这样的场景，这里提供两个比较简单的办法，如果可以果确认这个服务是只读的，并且后续没有什么修改操作（例如需要保存数据结果），以及没有更多的测试服务依赖这个数据的场景下，那么当前服务可以直接接入到生产的数据进行开发和测试。但是有些服务会把生产上的数据进行读取分析后将结果写入到一些地方然后进行后续的操作，这样的场景在后续文章中会讨论，和本文关系不大。

这里有些使用场景，比如运维管理平台，例如gitlab，maven私服等放到非生产环境中。但是有些是独立服务于生产环境，就可以放到生产的VPC中即可。

现在把所有的环境分成了，生产环境和非生产环境两部分，也基本可以确定两个区域基本是不会进行互通的，因为数据不可能既存在于测试环境中，又存在于非生产的环境中。如果有网络连通的需求也可以通过公网环境进行连通 。

所以在一个区域中规划两个VPC，生产环境VPC，专注用于做生产环境相关服务，一个隔离严格控制的隔离环境。非生产环境VPC，用于做其他服务，例如，测试环境，运维环境等。多区域的扩展性，可以通过相同的方式进行复制，当然有可能不需要在每个区域都建立两个VPC，因为可能非生产的测试环境有几个就进行测试，生产环境可能需要在多个地区进行部署（现在多数云厂商还不支持跨区域的VPC）。

网段的设置：VPC网段必须使用私有网段，A类：10.0.0.0/8（可用 16,777,212），B类：172.16.0.0/12（可用 1,048,572），C类：192.168.0.0/16（可用 65,532）。

原则是：避免网段冲突，这里优先使用B类和C类的网段。A类网段作为备用网段，例如阿里云经典网络中使用的是10.0.0.0/8。

生产VPC使用172.16.0.0/12 私有网段，每个VPC使用172.16~31.0.0/16网段（172.16.0.0/16，172.17.0.0/16，172.18.0.0/16 等），每个地区只会有一个生产VPC，所以在B类网段中生产一共可以有15个VPC，其他网络环境使用：192.168.0.0/16，包含办公网。

这里如果可见的在一个VPC内不会包含很多的机器可以将一个172.16.0.0/16分成多个来使用，比如172.16.0.0/17，172.16.128.0/17，两个来方便VPC多区域的扩展。当然还有A类：10.0.0.0/8的备用网段，足够满足需求。

子网、路由表、可用区的实践

子网在阿里云中也称为交换机。

基本所有的服务资源都需要在子网内启动，子网比较关注的特性是网络的连通性，因为路由表是附到子网上的，所以子网的连通需要由路由表和一些网关来进行控制。路由表中包含一系列被称为路由的规则，可用于判断网络流量的导向目的地。在 VPC 中的每个子网必须与一个路由表关联；路由表控制子网的路由。一个子网一次只能与一个路由表关联，但可以将多个子网与同一路由表关联。

总体思路是，路由表和网络进出相关，主要目的是区分有公网IP的公网进出类，和NAT的只出不入两类。子网和路由表关联，所以子网具体路由表的特性，每个可用区中都会建立这三类的子网。

所以这个方案中把子网分成三类。

1. Internet类，使用Internet网关的，特点：需要有公用IP进行公网的进和出，用途：需要具有公网入能力的服务，例如：负载匀衡服务，一些网关应用。
2. NAT类，使用为NAT网关，特点：不需要公网IP可以进行公网出方向访问，但是不能公网进入，用途：需要具有公网出的服务，例如：业务服务，绝大多数服务都可以放到这个区域。
3. 私有类，不会有公网进出，用途：不需要公网的进出已经对安全性要求比较高的服务，例如：数据库服务（这里如果是自建的RDS，这里有联网升级的需求的不要放到这个区域内），KMS服务等

网段的设置：子网建立在VPC中，例如当前VPC的网段为172.16.0.0/16。

1. 每个子网都是 掩码位 为 24，即每个子网内可以放置最多254个机器，可以扩展相同类型的子网，这样在二类私有网（172.16.0.0/16）中最多可以建立256个子网
2. 不同服务可以部署到相同的子网中，网络和业务不耦合（但是有的云平台不支持例如RDS，进行安全组的设置，只能支持对网段的控制，这个需要子网和系统耦合，需要单独给RDS建立单独的子网，子网网段可以适当进行调整）。

安全组的实践

Aws 中提供了ACL这个服务，也可以用于做访问控制，当前方案中没有使用。

有一些云服务的云厂商，无法对自己的服务比如数据库进行安全组的设置，这样的场景，需要通过建立独立子网，然后对子网IP段进行单独控制

安全组是一种虚拟防火墙，可以通过配置安全组规则，允许或禁止安全组内访问策略。在这个方案中，上述的VPC，子网，路由表等都是在给网络分类，都没有和具体业务服务相关的，业务和网络的关联性通过安全组的方式来实现。

可以通过安全组来进行业务系统的划分。比如运维管理区等等，这里还需要注意的是不宜将安全组划分的过细，比如一类系统就有一个安全组，因为接口上也会有安全限制，所以安全组一般会用于公网访问相关，SSH，RDP等访问，敏感系统的访问等。但是比如后台系统中有内容管理系统，用户中心系统等，这类系统不需要分别单独使用安全组中。

案例：

1. 安全组：WebPub 规则 公网允许入：80，443。（公网的子网类型）
2. 安全组：Backend 规则 允许WebPub组所有入。Backend允许Backend 大于 1023端口 的访问。（NAT的子网类型）

一个典型的应用场景。有NGINX（Aws LB）等做负载均衡，然后转发到内部的系统中。这样我们把NGINX安装在带有Internet网关的子网中，然后比如用户中心部署到NAT的子网类型中。WebPub会形成DMZ区。这样如果Backend中也可能会有使用了80端口的应用，如果这样的话就可以防止了访问控制策略的失效。Backend组需要允许自身的访问，但是自身的访问需要限制在业务端口（这个实际场景来确定，公认端口 0-1023 注册端口，也可以设置比如5000以上端口）

1. 按照业务系统的特性来语义话的来创建安全组，比如：WebPub只公网的web访问，Backend是指后端的服务组。

2. 内部服务允许规则需要尽可能的使用安全组，不要使用指定IP，或者IP段。

IP规划参考

• 生产VPC：172.16.0.0/12

  • AWS-东京区域：172.16.0.0/16

• AWS-弗吉尼亚北部区域：172.17.0.0/16

  • AWS-伦敦区域：172.18.0.0/16

• AWS-北京区域：172.19.0.0/16

• 非生产网络：192.168.0.0/16

  • 云上环境（测试环境等）：192.168.0.0/17
    • AWS-东京区域：192.168.0.0/20
    • AWS-弗吉尼亚北部区域：192.168.16.0/20
    • AWS-北京区域：192.168.32.0/20
  • 企业网（办公环境等）：192.168.128.0/17

• 备用：10.0.0.0/8，扩展策略：保持相同的规则进行扩展，可扩展到多倍。

如有问题欢迎留言或者私信