---

下面是演讲全文（约6000字，阅读约10分钟）：

大家下午好！

我是来自阿里云云网络的解决方案架构师，我的主要职责是给客户设计网络解决方案和推广云网络卓越架构，也会给客户解决网络架构层面的问题。2024年是不平凡的一年，我们遭受了一个灾难——新加坡的机房着火了，这是一个极低概率的事，但它确确实实发生了。我们看到有些客户业务系统崩溃了，同时也看到很多客户的业务并没有受到太大影响，他们在故障时快速逃逸了，为什么有的客户能在灾难发生时快速逃逸呢，我认为非常关键的一点在于其卓越的架构设计。

大家脑海中有一个概念，就是觉得企业上云，把计算搬到云上之后就算上完了，其实这是远远不够的。我们处理了非常多的客户问题，很多都是上云之初，忽略了网络规划和设计，给业务的长期发展埋下了隐患。举几个例子：

第1个场景，我们有一个做直播业务的客户，它的整个服务部署到阿里云的一个可用区里，当这个可用区发生故障、链路抖动的时候，它的业务就崩溃了，所以不得不停下几周的时间去升级它的架构，把业务部署到双可用区。

第2个场景，也是我们最常见的一个场景，企业一般都会有生产环境、测试环境和研发环境。但一些客户为了图方便，把多个环境混在了一个VPC里，为满足业务诉求，需要配置非常多复杂的安全组规则，但这往往很难隔离好，又会给业务带来很多隐患和故障。正确的做法是每个环境建一个VPC，通过VPC进行环境的隔离，VPC内部再进行安全组、ACL的隔离，这也是我们建议用好VPC的安全能力的原因。

第3个场景，是我们客户在做整体IP规划的时候，没有做好地址规划（虽然这是一个比较小的问题，但遇到了就很痛，对未来业务的扩展，会有非常大的制约），比如地址用的比较随意，业务和业务之间IP地址段有交叉，甚至要启用业务时，无私网地址可用了，造成了IP地址的冲突，最后又要通过NAT去解决这些冲突问题。网络的构建需要考虑到弹性可扩展，确保业务的可持续性。

第4个场景，我们客户上云，跟阿里云之间拉上专线，客户也知晓要做好高可靠，拉了两根专线，但专线的主备配置没有生效，当一个线路故障，导致线路切换失败，同样导致业务的故障。

第5个场景，运维同学在云上做一些业务的配置时，有时候会遇到批量的工作，频繁点击控制台执行重复动作，交付效率很低，很痛苦。

综上，阿里云网络总结了客户遇到的这些问题场景，归纳了服务客户的经验，定义了在做网络架构设计时需要参考的五个原则，分别是：

1. 稳定：需要去考虑整个网络的容灾准备度，设计它的高可用架构。
2. 安全：首先要用好VPC的基础安全能力，其次用好流量安全（专业的安全产品能力）。
3. 性能：包括未来弹性、扩容，以及可持续发展。
4. 可观测：观测架构的健壮性，容灾性，观测架构是否能保持最优的状态等等。
5. 自服务：如何通过代码方式、IAC的方式实现自服务，提高交付效率。

为了强化大家对这些原则的重视，我们将其定义为阿里云云网络卓越架构的五大支柱，并将这五大支柱做了进一步的细化，阐释出每一种场景，应该适应什么样的架构方案。

第一支柱，稳定

谈到稳定，第一个会想到的是容灾，容灾分为两个层次。

• 关于机房层面的容灾。你在机房里应该怎么部署，部署到两个机房，即同城多可用区部署；或者两个地域的三个机房，就是我们常说“两地三中心”的架构。
• 线路层面的容灾。比如IDC跟云之间的连接，我们要求至少要有两根专线连接到两个接入点，差一点的情况也应该用一根专线+一个VPN备份的方式。

第二支柱，安全

首先，会涉及到使用VPC产品的基础安全隔离能力，比如网络ACL，安全组、多路由表的能力，进行多网络平面的隔离。

其次，还涉及到流量安全，大家熟知的抗DDos、WAF功能，这是南北向的公网安全。

还有一个非常容易被大家忽视的是东西向流量安全，东西向流量安全应该怎么设计，这是我们要去讨论的一个重点。

第三支柱，性能

性能关注弹性的能力，比如业务高峰来临的时候，我该怎么去适应，怎么去抗压力，这需要用好产品的自适应弹性能力。再者，我们的业务如何分级去做QoS，以及在服务C端客户的时候如何做到就近服务，提升体验，它就需要低延迟的方案，包括公网上的低延迟以及跨地域传输的最低延迟等。

第四支柱，可观测

也分为两个大类：一类是如何观测我们业务之间流量，比如公网质量是否符合预期；另一类是业务不断迭代，如何保证我们的架构能够持续地稳定和优秀，需要日常进行架构层面的巡检来观测它。

第五支柱，自服务（自动化）

这也是我们很多运维同学比较痛苦的事，运维同学在批量交付项目中，重复戳控制台，既复杂又重复，这里其实有更加高效、敏捷的方式，即通过IaC的方式来进行快速交付。

后面，我将围绕这五大支柱，并挑选典型场景的设计要点，进行重点解读。

首先是架构设计中的稳定支柱，这是大家都非常关注的目标，不仅云厂商，客户也把稳定作为开展业务的第一目标。

在稳定架构设计中，大家经常会听到一个词 “同城双活”，实现同城双活是相对简单的，意味着我的业务至少要部署到两个机房，云上而言是两个可用区（AZ），将业务部署到两个AZ之后，就需要一个负载均衡来对整体流量做负载分摊，这就是同城双活最原始的雏形，这也是最基本的一个架构，也是我们所有客户首先去落实的一个架构。

这个架构可以有效避免单可用区故障，当某个可用区故障后，客户的业务仍然是活着的。

虽然架构的原理比较简单，但有些细节需要特别强调一下：关于IP地址的规划。比如10开头的私网地址，掩码是10.0.0.0/8，但我们推荐客户要采用16作为掩码用作VPC的地址，既够用又给未来的拓展留有空间，另外也要规划多个可用区的网段，比如给可用区A和可用区B定义公网Subnet (Public  Subnet)和私网的Subnet (Private  Subnet)，不同的网段承载不同的业务流量，也就是说与公网相关业务放在Public  Subnet，与私网相关的业务放在Private  Subnet，业务进行分类之后，当Public  Subnet和Private  Subnet之间要做流量隔离的时候，可以直接使用网络ACL的能力进行系统隔离；关于负载均衡，SLB产品天生就有多活的能力，将流量负载到多个可用区的ECS，解决应用单节点的问题，以上是最基本的同城双活的架构。

随着业务的成长，业务需要就近服务C端的用户，架构也会发生变化。比如业务部署在杭州，覆盖的是华东、华北的C端用户；如果想进一步覆盖华南的客户，可以选择在深圳开启双活中心；每个中心，其实都是一个同城双活的架构，这样就形成了双中心多活的架构。

这个架构有几个细节：

• 最上面是流量入口，可以根据C端用户的位置，通过DNS进行流量分流，比如哪些省份的流量分到左边，哪些分到右边；当然如果某中心遇到故障，将所有流量快速切换到另一中心，实现应用级灾备。
• 有两个中心，就需要将这两个中心的网络做打通，可以用CEN+TR，实现全局一张网，然后使用DTS同步两边的数据，确保数据的一致性。

这是我们非常多客户采用的架构，最有代表性的是金融行业客户，如国泰产险，就是采用这个架构，开启两地三中心，实现业务双活。

安全这个柱子，每个客户都会关注，尤其关注南北向公网流量的安全，包括抗DDos、WAF等。今天我们探讨一个容易被大家忽视的“东西向流量的安全问题”。由于企业分支众多，环境众多，内网通信的流量较大，一旦攻击者突破Internet边界，则会对内网安全造成较大的威胁。

比如我们企业日常生产中，至少有三套环境，分别是生产环境、开发环境、测试环境，这些环境之间是有优先级差异的，比如不能随便通过测试环境访问生产环境，他们之间绝大部分场景是不需要互通的，但也存在极小的场景需要互通，那从安全视角，怎么解决这个难题？

既要隔离，又要有限的互通；也就是说，需要有监督的情况下互通，假如将这些流量放到一个独立的区域去检测，由它去做决策能否通；那么我们定义一个可信区域，将多个环境之间的互访定义为不可信的流量，把不可信的流量导入到可信区域去检测，经过可信区域认证的流量，再送回到真正的目的地，从而实现安全的互通。基于这个原理，可信区域也就是安全VPC，里面部署云防火墙用于检测流量，剩下的就需要实现引流。

在这个场景里，可以使用阿里云网络转发路由器TR（Transit Router ）产品的多路由表能力，定义两张路由表：一个定义为不可信的路由表，这个路由表关联所有环境的VPC，并将互访的流量默认送到安全VPC去，安全VPC内的云防火墙，来对流量进行检测和观察，做出放行还是阻断的决策；再定义一个安全路由表，关联给安全VPC，配置好路由，把云防火墙放行的流量，转发到真正的目的地去，最终实现东西向的内网流量安全。

这个场景还有另一个用途，满足审计的诉求。我们知道企业需要针对网络安全进行定期的审计，满足安全合规的诉求。我们可以在TR和VPC里，开启Flowlog的能力，把业务流量以流日志的形式记录下来，再结合云防火墙，作为审计源数据，实现可审计、可回溯。像我们优秀的客户可口可乐，就是使用这个方案，既解决了东西向流量安全，又满足了网络安全审计和安全合规。

接着我们再看第三个支柱，主要是关于性能方面的。

之前大家都会卷性能、卷吞吐，比如带宽有多大、容量有多大、转发能力有多强等等，实际上阿里云网络早就卷好了这方面的性能。我们有些客户会卷另外一种形态的性能，比如说他的游戏想实现就近覆盖，比如在北京部署个节点来覆盖华北的玩家，在上海部署个节点覆盖华东玩家，以及部署华南节点和西南的节点，在全国部署4个节点分别实现游戏大区的覆盖，这会使得每个区域的玩家都能获得最低的延迟体验。这就涉及到极低时延了，需要怎么设计呢？

首先，要实现公网的延迟，阿里云已经提供了高质量低延迟的BGP带宽，在使用带宽的时候，要注意最佳的使用方式——即将公网EIP、共享带宽、SLB网元以及ECS在同一个可用区对齐，避免流量在AZ间绕行，这样就能获得最低的公网延迟。

其次，由于业务散到多个区域部署，就会涉及到多区域之间数据的同步，这里可以采用CEN跨地域铂金资源，我们的AZ之间的底层线路，一般是多路由，有非常多的物理线路，而物理线路又不允许在道路上重叠。所谓跨地域铂金资源，就是会从整个线路里，选最短的路径来获得最低的延迟，再叠加上午讲到的ZooRoute重路由技术，实现在选路中快速收敛，避免故障链路，极大的降低了跨地域传输中的抖动，最终实现延迟又低、又稳定的跨地域传输能力。

网易雷火的很多游戏都是这么区域化部署的，大家在玩雷火的游戏时，你就会感觉到他的游戏很流畅，很少遇到卡顿，背后就是使用了阿里云网络极致低延迟的公网和跨地域铂金方案。

关于可观测，是我们非常多客户的痛点。我们拜访过非常多的客户，客户的运维和CTO最关注的目标就是稳定性，但客户说，他最大的痛苦就是不知道他的业务，哪个地方有潜在的隐患。客户就求助我们，给他的业务做诊断。

我们做解决方案的同学，有着丰富的诊断和调优经验，因此我们从这些经验总结出具体的规则，并产品化，帮助客户自助诊断问题，这就是阿里云网络NIS产品的网络架构巡检能力的原型。

NIS网络架构巡检，其实是一个比较笨但又非常有效的方案。我们根据经验，总结了非常多的规则，比如说客户的业务至少要部署到两个可用区，如果业务全塞到一个单可用区，那么它的稳定性必然是有问题的；再比如，两根专线，要配置健康检查机制实现主/备或者主/主……我们的巡检，就是依赖这样的规则实现的，用这些规则去给客户的业务做体检，并提供一个汇总的报告以及网络架构评分，告诉客户当前的网络架构哪个地方是有风险，请客户关注和修复。

截止到今天，我们已经在稳定、安全、性能、成本多个维度提供了巡检规则并产品化，让客户可以观测他网络架构的卓越程度，并提醒修复薄弱点或风险点，最终保持整个架构的持续卓越。

最后一个支柱是自服务。我们有个游戏客户，它的整个架构如图所示：IDC机房跟阿里云之间拉了物理专线，形成混合云网络，并在云上实现多区域部署的环境。他们的几十款游戏，都需要部署成这个架构，既要把如此多的业务在云上快速部署起来，又要能快速完成游戏的日常扩缩容，但整体负责实施的又只有两个人，客户非常痛。

阿里云网络跟客户共创了一个方案，通过IaC自动化的方式来提升运维和管理效率。

通过Terraform实现以下逻辑：在专线上创建虚拟边界路由器VBR，并创建一个跨地域的多VPC网络，部署负载均衡SLB等等。客户之前是手工交付，每一步骤都点鼠标，但通过Terraform去交付时，交付时间从之前8个小时缩短为0.5个小时，脚本跑起来之后，喝喝茶整个环境就出来了，这是一个质的变化。

同时，由于游戏业务的峰谷业务形态，日常需要经常变配。之前变配的方式也是手动的方式，现在通过Terraform脚本，10分钟就可以搞定。基于Terraform自动化部署，让客户两个人轻松完成所有运维工作。

这里还想啰嗦两点。一个是IaC自动化部署的理念，虽然国内大多数客户还没有普遍使用，但在我们服务的国际化客户里面被普遍地使用，它的效率非常高。与此同时，我们对阿里云网络产品做了IaC能力的适配，阿里云网络的所有产品默认适配了Terraform的接入，包括API的接入，以及完整的场景级的Terraform代码。

另一个是，大家看这个场景的Terraform方案，两根上云的物理专线形成主/主方案，左边的北京VPC，右边的上海VPC，其实也形成了“两地三中心”的架构，符合我们卓越架构的设计理念。

最后，我们总结一下，我今天主要分享了网络卓越架构的五个支柱，每个支柱里又有很多具体的场景，每个场景里又有多个解决方案，我们将符合卓越架构理念的最佳实践文档已经整理出来了，形成了《云网络卓越架构设计指南》白皮书，该指南已在阿里云官网文档社区中发布。

阿里云网络卓越架构白皮书详情

 阿里云网络卓越架构 Terraform Module（Github）

另外，我们也把场景级的Terraform脚本，抽象出可复用的Module，并正式开源到GitHub的Alibaba Cloud  Automation，大家可以直接下载，复用我们的Module代码，完成业务的部署。后续我们将继续丰富卓越架构理论，并开发和开源符合卓越架构理念的Module，形成理论和实践双合璧，帮助客户实现持续卓越的网络架构。

我今天的分享就是这些。谢谢大家！