作业帮老是说网络有问题（作业帮多云网络的探索与实践）

谈到多云建设，多云互通是绕不开的话题，也是多云架构能取得成功的关键基石。

作业帮从成立之初就一直扎根在公有云上，没有自建机房，即使是工区的办公服务95%以上也都实现了云化部署。在作业帮的多云网络建设过程中，历经多次架构重塑，最终摸索出一套双环星型组网 CPE管控的多云网络互通方案。本文将会通过「网络建设」、「质量提升」、「持续运营」三个阶段来介绍作业帮网络团队在多云网络建设过程中的探索与实践。

接下来会按照时间 架构的维度将网络建设的过程拆解成三个不同的阶段来展开介绍：

时间回到2019年底，当时公司所有业务都是单云部署，在经历过多次云厂商故障后，开始深刻意识到单云故障时的无能为力。为了规避因单云故障导致的服务不可用，公司开始积极尝试双云架构。考虑到当时云上网络没有专职网工，且北京工区的IT老师因历经多次工区互联建设已经有了比较丰富的专线建设经验，所以最终决定复用工区的专线资源和IT能力，以工区为中心打通双云网络。

大家也可以看到，这个架构并不完美。在建设完成后，随之而来的问题也开始暴露。因为双云网络是依赖工区网络实现的互通，工区网络就成为关键依赖，任何一点风吹草动都会被放大。而且公司刚处于双云架构的早期阶段，双云网络的不稳定就会影响到双云建设的进展，同时打击到业务方对双云建设的信心及热情。仔细分析了下，双云网络不稳定主要是因为存在如下2个因素：

• 双云网络链路长，不可控因素太多，任何一个环节出问题都会导致网络不可用，且没有逃生能力。另外，工区网络的保障是办公级别，双云网络的保障是生产级别，将工区网络放在双云网络的核心链路上，会拉低双云网络的保障级别。
• 
  
• 双云网络和工区网络严重耦合，导致双方团队的职责边界变模糊，存在IP地址规划冲突、路由管理混乱、变更相互影响等一系列问题。

在意识到上述架构存在的问题后，我们开始着手改造，在两个云之间建设直连的专线并采用双链路冗余的方案，解除对工区网络的依赖，并将工区网络作为故障时的兜底。

时间回到2020年底，双云网络的故障次数有了大幅度的收敛，有效的支撑了业务进行双云部署。但是随着业务双云部署的规模加大，新的问题开始暴露：

• 专线采用静态路由方式，无法实现互备。虽然双云网络的故障次数减少了，但是故障时长依旧很长。原因是虽然建设了双链路专线，但是为了实现双链路承载不同的业务以及某云厂商不支持BGP协议，所以双链路采用的是静态路由的方式、无法起到热备的作用，需要手工将链路A的路由全部切到链路B，再加上静态路由使用不收敛、配置不规范等情况，导致在故障时切流切干净，人工排查处理成本高，拉长了故障时间。
• 
  
• 专线带宽经常被跑满，缺乏感知管控能力。随着业务双云部署的规模加大，开始频繁出现专线带宽被跑满的情况。每一次出现这种情况都会搞的很被动，原因在于现有的架构下只能看到专线带宽的整体使用，但是拿不到跨云流量的明细数据，只能一个业务一个业务的问，非常耗时且低效。同时，就算已经知道是哪个业务导致的专线带宽突增，但是专线上没有任何限流能力，只能推动业务方解决。
• 
  
• 想要引入更多的云厂商，架构改造成本高。为了进一步提高对云厂商的议价能力，同时也希望使用到某些云厂商的特有产品，需要再引入1~2家新的云厂商，发现现有的网络架构不具备扩展能力。

基于上述架构存在的问题，我们开始进行新一轮架构改造：

我们对多云组网方案进行了调研，主要分为如下4类：

线形网络：将新接入的云厂商与现有的云厂商串联起来。

环形网络：将新接入的云厂商与现有的几个云厂商组成一个环形。

网状网络：将新接入的云厂商与现有的几个云厂商两两互联。

星型网络：通过专线供应商的城域网将多家云厂商互联起来。

为了方便对网络方案进行对比，我们从成本、质量、性能、效率这4个维度归一化出4个指标，然后进行横向对比：

综合对比后，我们发现网状网络的质量最好但是成本极高，线形网络的质量最差，环形网络的可扩展性差。最终我们选用扩展性更好的星型网络方案，同时为了提高网络质量引入2家专线供应商实现互备，两家专线供应商的pop接入点分散在北京的一南一北，采用ECMP协议实现链路冗余。

2.链路添加CPE设备，具备感知和管控能力。

为了具备感知和管控能力，我们就不得不在跨云网络上嵌入自己可管控的交换机设备，简称CPE(Customer Premise Equipment )。考虑到我们没有自建机房且买设备的维护成本较高，我们采用和专线供应商租设备的方式。由专线供应商来将多云网络进行互通，并在每个云到专线供应商的网络上架设CPE设备，同时将设备的管理员权限给到我们。这样我们通过CPE设备，就具备了对跨云流量的管控能力，如路由策略、ACL策略、QoS策略等。同时也加强了对跨云网络的感知能力，如路由状态变更、BGP协议状态、跨云流量分析等。

3.全链路切到BGP，具备链路自动切换能力。

推动多云厂商的网络产品升级支持BGP协议，然后将现有的网络协议全部从静态路由切到BGP，并调优BFD配置，实现了故障秒级自动切换。

时间回到2021年底，经过如上3方面的改造后，多云网络架构基本成型。改造后的架构具有如下优点：

• 架构灵活：新增或下线云厂商的成本降低，无需对现有架构进行调整
• 带宽弹性：底层物理网络100G，上层带宽按需申请，带宽扩缩容天级完成
• 链路冗余：采用双供应商构建两条多云互通链路，采用ECMP协议实现自动负载
• 同城灾备：双供应商的pop接入点分布在北京的一南一北，分别是亦庄和顺义
• 自动切换：全链路采用BGP BFD协议，实现故障秒级自动切换
• 增强感知：通过netflow采集跨云流量并进行分析，具备带宽topN能力
• 增强管控：具备路由/ACL/QoS等管控能力，可自助完成、不再受限于人

多云网络是最基础的服务，也是被依赖最重的服务，因此它的稳定性至关重要。在经历过「网络建设」阶段后，我们已经建设起一条多云互通的链路，但是这条链路的质量怎么样，如何保障链路的高可用就成为接下来要重点投入建设的方向。

从故障的生命周期来看，我们将故障处理分为预防、发现、定位、止损、恢复这5个阶段，接下来将围绕这5个阶段介绍我们在稳定性工作上的投入及思考。

故障预防是稳定性工作的重点，故障预防做的好可将故障抹*于无形。回到多云网络上，我们主要围绕架构高可用、容量管控这2个方面展开：

• 架构高可用：在前面的「网络建设」中已经介绍过，这里不再赘述，最终要达成架构归一和架构冗余的目标。
• 
  
• 容量管控：将双链路的带宽使用率控制在50%以下，以确保当其中一条链路故障后另外一条链路能够承载全部流量。同时，通过QoS手段对DB等核心流量重点保障，对大数据流量进行限速。
• 
  

如何在故障发生时能够及时发现，最有效的手段就是监控。监控是运维最擅长的领域，也是一个值得纵向深耕的领域。这里我们围绕专线监控、CPE监控、链路监控这3个方面展开：

• 专线监控：补齐专线网关的状态监控，以及专线的出入向带宽使用监控。
• CPE监控：通过snmp/syslog等手段补齐CPE设备的监控，包括CPU/内存/风扇/光模块/BGP/BFD等的状态监控。
• 链路监控：采用pingmesh方案，在多家云和专线供应商都部署探测点，通过fullmesh-ping的方式监控跨云网络的质量。

故障定位的目标在于故障发生后能够在5分钟内定位到根因，核心点就是快和准。这里我们围绕可视化大盘、自动诊断、变更追踪这3个方面展开：

• 流量分析：通过netflow的方式采集CPE设备的流量并存入ELK中，定制流量TopN、协议分布、跨云分布等多维度大盘。
• 
  
• 质量大盘：通过上文提到的pingmesh监控数据，聚合成多维度的监控大盘，如跨云网络质量、专线供应商网络质量等。
• 
  
• 自动诊断：当监控探测点在ping探测的过程中发现丢包时，自动触发链路trace，并将trace结果发送到钉钉群中，便于记录故障现场和快速定位。

谈到故障止损，最快速的手段就是回滚。但是如果回滚也无法奏效或者迟迟无法定位根因时，切流就成为最快速有效的手段。当然，切流也是一个复杂的系统性工作，需要考虑切流的完备性、顺序性、唯一性、时效性、可行性等一堆问题。这个时候就不得不引入预案平台，通过平台来实现经验的沉淀和效率的提升。在预案平台上定义不同的故障场景，并针对不同的故障场景编排不同的预案，甚至可以将多个预案再组合成一个更高维度的预案，以此来达成一键执行、5分钟内止损的效果。

• 在预案建设上，我们主要从完备性、时效性、可行性三个方面展开，分别对应预案梳理、预案平台、预案保活。
• 
  
• 预案梳理：对专线故障的场景进行演绎，并针对不同的场景制定相应的预案，最终产出可落地的SOP。
• 
  
• 预案平台：进一步加强预案平台能力建设，实现和多云专线网关、CPE设备打通，将SOP沉淀成可执行的脚本。
• 
  
• 预案保活：为了确保预案的有效性及预案平台的健壮性，会对预案进行定期演练，并引入QA做验收。

经过上面一系列的稳定性建设后，多云网络的质量终于得到保障，可以自信的承诺下99.99%的SLA目标。但是在长期的网络建设和运维过程中，还是存在着很多非标配置和历史遗留问题，如果不及时解决也会带来稳定性隐患。所以我们接下来要做的就是对现有的网络进行治理，包括路由、网关、规则等。

• 工区管控：为了优化外地工区上云的质量，我们将工区网络通过云专线网关的方式和云上网络进行了互通，方便的同时也带来了隐患。为此，我们对工区上云的路由进行了管控，只允许发布指定路由，避免工区发布非标路由与云上路由冲突。同时，在工区上云链路上添加防火墙设备，对上云的流量进行审计和管控。
• 
  
• 路由收敛：现状是每家云自身路由再加上从其它云学过来的路由，共计有400 条。一方面会触发云厂商的路由条目数限制，另外一方面当出现故障时会导致路由收敛速度变慢、拉长故障时长等。为此，我们在三家云的CPE设备上进行了出向路由汇总，将聚合后的路由发送给对端，将云上的路由条目数从400 条优化到100条内。
• 
  

随着业务从开始的多云尝试进入到了多云部署的收尾阶段，多云架构开始暴露出一些问题：

• 多云部署不完整：部分服务或下游依赖未实现多云部署，还是存在跨云请求。
• 
  
• 多云状态不持续：跨云请求不收敛，虽然通过服务治理的方式对跨云请求进行了约束，但是在故障注入验收的时候往往第一次验收通过第二次就不通过了。

为了解决上述问题，公司对多云架构提出了更高的要求：“除DB、Cache等核心数据服务外，其它服务都不应该跨云“。为了达成业务单云闭环的诉求，我们就需要在跨云网络上增强感知和管控能力，建立起跨云维度的流量度量和流量治理体系。

• 流量度量：数据驱动，对跨云的流量进行分析并打标，再结合代码和配置文件的扫描结果，最终责任到人，建立起周粒度的运营能力。
• 
  
• 流量治理：老板驱动，借助TC的力量推动各业务方整改，并限定截止时间，最后在CPE上配置常态断网策略，彻底阻断业务的跨云请求。

在经历过上面三个阶段的建设后，网络运维终于从开始的被动救火迈入了主动运营的阶段，同时也伴随着业务多云架构的成熟落地。

回顾多云网络建设的过程，虽然走了很多弯路，但是最终的建设目标和建设原则越来越清晰，可以归纳为「3个目标」和「4个原则」。

• 3个目标：建设极简、可靠、可扩展的多云网络
• 
  
• 4个原则：坚持架构归一、协议归一、链路归一、规则归一的建设原则

回到作业帮自身的业务形态上，存在很多的边缘场景，如RTC推拉流、全国工区上云、三方云私有化交付、边缘云引入等，这个时候就发现中心云的架构已经无法满足，需要构建一个能够同时覆盖中心和边缘的网络，也就是分布式云架构。（分布式云定义：一种将云服务按需部署到不同地理位置，提供统一管理能力的云计算模式。 ）

• 边缘加速场景：以中心网络为基础，将全国工区的老师和边缘RTC节点打通，实现推拉流就近接入及内网加速，简化推拉流调度的复杂性。
• 
  
• 边缘交付场景：使用客户提供的云或者IDC机房，通过隧道的方式和中心网络建连，降低交付的复杂性，同时实现运维管控面统一。
• 
  
• 边缘互补场景：引入一些二三线的云厂商，将其作为边缘云与现有的中心环网有限打通，使用其优势资源，作为中心云的补充。
• 
  

作者:侯文辉

来源:微信公众号:作业帮技术团队

出处:https://mp.weixin.qq.com/s/aYsi5WAA9uAM9U0Vd6GifA