只用2年完成改造、兼备高稳定性和灵活性，作业帮多云实践

云技术发展了十几年，但就算是到了今天，我们依然无法保证云服务不会发生宕机故障。另外对于成熟企业来说，数据是最宝贵的核心资产， 那么他们必然会担心会被某单一的技术提供商锁定，或担心公有云厂商进入自己的商业领域......

无论是用于平衡风险还是充分利用各种云平台的优势和用例，很多组织都会有意无意地让工作负载在多个云中运行。别把所有鸡蛋都放同一个篮子里，是放之四海皆准的思想。据统计，目前全球 81% 使用云服务的公司或组织正在使用多云，但不同的企业有不同的实践方法。

作业帮一开始就建立在公有云底座之上，享受着早期云计算释放的成本红利，也同样会面临云计算带来的这些挑战。因此作业帮从 2019 年开始，逐渐开始了多云转型。经过几年实践，作业帮形成了自己的多云架构，也应对过一些挑战，并有了一些非常有价值的思考。在组织“多云专题”的时候，我们采访了作业帮基础架构负责人董晓聪。

董晓聪：多云是指企业使用两个或更多数量云服务供应商。之所以大家认为这个概念比较开放，是因为这个定义不是那么刚性。比如企业使用多个供应商的 SaaS 服务，这个能算多云吗，这个就和当下主流的理解是不一致。当下谈到多云，更多是讲的企业使用多家云厂商的 IaaS、PaaS 产品。

在多云这个范畴下，企业架构也有多种模式，如主备多云、弹性多云、业务切分多云、数据主权多云、多活多云等等。每一种架构下的特征也不尽相同，提炼其中的共性来看，多云应该具备如下特征：

1. 具备选择权。多云给了企业选择的权限，可以选择成本更优、服务更好、功能更完备的云产品。这是对企业更有利的。

2. 对应用层屏蔽多云差异。除了给企业带来好的一面外，多云不可避免的带来了复杂性。对业务应用而言，需要有统一的 DevOps 管控面，屏蔽多云带来的部署差异、服务治理差异。

3. 网络互通。上面更多是讲的抽象的利弊特征，再来从具体的资源层和应用层看下。资源层这块多云最重要的是要把多个云厂商基础设施连接起来，不论是通过专线互通，还是通过 VPN 隧道，都要纳管到统一的网络平面。

4. 流量调度。只要在多个云上部署了应用服务，就涉及到流量的调度。其中既有用户侧的南北向调度，也有服务跨云的东西向调度。这些调度能力载体是 DNS、ingress、服务注册发现、Service Mesh 等。

董晓聪：多云具有如下优势：

1. 灾难恢复，当一家云供应商出现故障时，数据存储可以从另一家云供应商进行恢复。虽然云厂商有多地域，单地域也有多可用区，但还是存在中心化的依赖。这种依赖的故障就会导致整个云的故障。后面提到的故障主要指这种类型的故障。

2. 故障转移，当一家云供应商出现故障时，使用另一家云供应商承接服务，实现服务平稳不中断。

3. 成本优化，任意的采购只要有了两家及以上供应商，采购方就有了充分选择和议价的能力。

4. 避免供应商锁定，单一供应商，除了没有议价能力外，各种依赖也会使得变更极为困难。

5. 数据主权，企业提供服务，但产生的数据产权也是归属于服务对象。服务对象既有普通的用户（行权由国家主体代为进行），也有机构。他们对产权的需求，连带的导致企业的云基础设施选择也受其限制。

6. 特定服务访问，不同云有自己优势的服务，一般出现在 PaaS 层，如各式各样的数据库、大数据实时方案等。使用多云可以集各家之长。

董晓聪：多云存在多种架构，对企业而言也是随着不同的发展阶段去选择适合自己的架构。每种架构没有绝对的优劣之分，更多的是看是否匹配业务。这个就像是服务架构从单体到微服务。微服务架构一定比单体更优吗，这个并不一定，对于业务初期或者交付类业务，单体的优势会更明显。

说回到多云架构，其主要有如下具体架构。

主备多云：

企业的应用服务还是在一家云厂商上，用户通过 DNS 解析过来，数据沿着网关、应用、数据存储这条链路流转。企业出于数据灾备的考虑，将数据存储同步到另一家云供应商上。亦或者企业有海量对象存储归档的需求，而另一家云在存储架构上有优势，如提供更具性价比的深度归档存储能力，或直接提供更具竞争力的价格。基于这些存储，企业还可能在备份云上开一些衍生的离线的计算，用来进行二次加工等。

弹性多云：

随着合作的更进一步，第二家云供应商抛出更优厚的条件，能提供更多的弹性计算能力。企业对这家云的使用变得更多，不再仅仅满足存储备份需求，开始把一些重要的应用服务进行部署，以应对一些突增流量的弹性需求。为了确保有突发流量时第二家云可以稳定承接，所以常态下就要承接一定流量，保证服务是双活的。当流量增加时，弹性云进行快速扩容，通过 DNS 或者网关将主云上无法承载的流量转移到弹性云上。

业务切分多云：

业务切分多云，这个也很好理解。公司有多个部门，或者直接是多个子公司，各自部署到钟意的云厂商上，就形成了这样切分的局面。这种多云模式往往也是最普遍的。用户访问不同业务使用不同的域名，不同域名根据 DNS 路由到不同云的不同服务上。两家云加起来才是公司完整的服务。因为业务线强势，中台无统一规划往往会出现这种情况。当然还有就是在线业务用一家云，离线业务用一家云等等。

数据主权多云：

不同用户群体，通过 DNS 路由到不同云上，在各自内部完成网关、应用、存储的数据链路，不同云之间不进行数据互通。每个云上都是完整的应用，但数据只有各自的用户数据。主要的场景有：

• 业务出海，很多国家都限定了数据不准离境，甚至规定了专属的云供应商。企业不得不一套代码，部署在多家云上。

• 有些私有化交付项目也是类似，企业需要按照雇主的要求部署在指定的公有云或者私有云上。

多活多云：

这种也是最复杂的一种，企业将服务等量部署在两家云供应商上，通过 DNS 进行流量分配。数据存储一般采用主从模式，随着分布式数据库的逐渐兴起，也有较多的选型，这里先简单按照主从来讲。多活多云是对稳定性和成本极致要求的产物。这种模式对多云互通的网络质量要求最高。

董晓聪：多云整体的理念是国外兴起的，有几个代表公司，如 HashiCorp、Snowflake。HashiCorp，是一家多云和基础设施管理公司，通过建立一系列开源工具，成为企业通往云的 "桥梁"，帮助企业实现云基础设施自动化、代码化。HashiCorp 关注重点在基础设施的多云。Snowflake 是一家基于云计算的数据管理软件公司，核心技术能力在于实现数据的跨云储存和计算，通过在云上扩展出一体化、一站式的数据处理和数据应用方案，令客户可以便利地挖掘数据价值。关注重点在 PaaS 的多云。国内类似的企业也有不少。

如果真要说国内外的生态差异，我感觉还是侧重面会有不同。多云在效率、成本、质量等方面均有收益，但国外的多云产品，尤其是基础设施层面的，会更侧重效率一些，如 HashiCorp 的创立原因就是创始人在工作花了绝大部分时间开发基础设施工具，配置云，创建开发工具等与公司核心业务相关性不高的工作。所以决定开发一款通用性产品，将工程师们从基础设施设计这件重复的杂活中解放出来，自动化这一过程。而国内多云管理的公司对外宣传会更侧重云成本的优化，这两年还在结合 FinOps 做宣传。为什么会出现这样的差异呢，国外人工成本高，产品化标准，产业分工完备，大家更倾向于专业的人做专业的事。所以企业会基于效率作出选择。而对于国内，定制化需求过多，这时候人的效率较难衡量，但云成本的财务账是显而易见的。

除了效率和成本外，还有一类公司是以质量为重。在国内是一些数十万核到数百万核的公司，这些公司自建 IDC，从人员和资源成本上看都不划算，上云还是最优解。但因其处于垂直领域的头部竞争或快速上升期，质量对其业务发展影响较大。对于此类企业多云建设的考量会更倾向于质量。由于企业基于不同的出发点选择多云架构，技术上也会呈现一定的差异，在前面的多云方案中也有提到。

董晓聪：作业帮从 2019 年底还在虚机架构下时就要考虑核心业务多云多活的事情。这个是因为作业帮对稳定性和成本有着极致的追求。

我在加入作业帮之前，在传统互联网、工业互联网、金融互联网等行业有一定工作经历，作业帮对稳定性的要求是最高的。我认为主要是因为两点，一是之前在做传统的互联网的时候，用户离我们很远，在我们心目中的用户本质上是 UV、PV 这样的数字，但在线教育真的不一样，我们的主讲、辅导老师通过直播等形式和用户面对面在一起，更真切的感受用户。另一块是，我们用户的服务时间比较聚焦，几分钟的故障都可会影响学生整节课的学业，所以我们对稳定性的要求只能更高。单集群高可用，甚至单云多可用区高可用仍无法满足我们对稳定性的诉求。

这些问题很难一蹴而就的在虚机架构下得到很好的解决，所以作业帮选择了先进行云原生的改造，用基础设施接管业务当中大量非功能的逻辑，以此来实现弹性、可观测性、韧性、自动化、可持续等相关一些特性。再基于底层的容器技术和服务治理能力，构建起一套多云多活的架构。作业帮在线业务坚定的选择多活多云的策略，只有这样才能带来理想的稳定性和成本收益。

董晓聪：作业帮多云多活架构详细如下图所示。

企业技术架构从大的层次来说，会分成两层，底下的一层资源层，包括计算、存储、网络等 IaaS 资源。应用这个层面，有底下的各种各样的 PaaS 组件，有数据存储的、有消息队列的、有安全的、有大数据的等等，然后再往就是具体的业务应用。

作业帮在实践中逐步摸索出一套多云组网 +CPE 管控的方案，实现在双云间甚至多云拓扑下的网络互通，以及诸多其他特性，如弹性 - 带宽快速扩缩、可观测性 - 跨云异常流量的分析、韧性 - 单节点单线路故障自动切换、可持续 - 新增云供应商的快速接入等。

虽然多云间网络上做了很多高可用的保证，但时延还是客观存在的，在微服务下会被成数量级放大。所以跨云的注册发现同步以及通信会有一系列问题，所以我们选择单云单集群，常态应用流量闭环在单个云机房内部的方案。如果需要跨云的话通过调度路由走边界网关进行通信。

数据存储方面，主要是用的还是经典的主从架构，不过根据业务对 CAP 不同的需求进行支持，有的业务以读取为主，数据的时效性要求不高，故障时可以牺牲一致性，要可用醒。而对于交易类型的业务，对数据一致性高度敏感，故障时宁可短时不提供服务，也不能使用不一致性的数据。除此之外，我们也在部分场景验证多主、MGR、单元化的方案。

董晓聪：每家云厂商提供的 IaaS、PaaS 能力看上去差异不大，计算无外乎是物理机、裸金属、虚拟机、Serverless。网络无外乎是 EIP、LB、NAT、VPC 等实体。PaaS 是各种持久化、内存型存储存储、大数据离线、实时计算产品。但深入到产品特性后，差异很大，管控面凹凸不齐。多云管控面要作为胶水层，对上游抹平这些差异。

我们做的时候要调研过一些开源产品和商业产品，但大家做的相对比较浅，只做了基础 API 的封装。真正麻烦的地方在逻辑的封装。如一家云厂商的某项资源管控比较宽松，仅用一个 API 即可实现功能。但另一家因为产品策略的收紧，需要结合多个产品才能实现类似功能。运维平台就需要将这些包成事务，对上层提供统一的能力。

董晓聪：作业帮在 2019 年底就开始探索多云架构，当时国内还没有成熟的多云管理产品，以及有一些个性化的需求，最终选择了自建的道路。我门对其的目标为，多云管理平台要纳管主流的云产品，对 SYS、SRE、RD 提供友好的操作界面。

在 IaaS 层，作业帮对计算、存储、网络都进行了封装。计算层面，如果无限度的开放云厂商的所有机型，SKU 过多，会给运维工作带来巨大负担。我们提炼总结了业务使用场景，定义了主力机型。这些机型再叠加上网络安全域、操作系统包装成一个个具化套餐，简化了使用流程，强化了资源管控。存储、网络等实体也进行了类似的平台建设。

容器在资源和应用中起承上启下的作用，北向接口的统一极大的便利了我们的工作。但不同云依然会有一定差异，如绑定的不同资源、不同的注解功能等。这块我们提炼共性做成统一模版，具体到单云配置实例化时再填充个性化变量。

CD 平台是业务研发使用最为频繁的系统，每一个云就对应一个 IDC，整体发布是分级的，较之前没有使用上的变化。感知体系中，日志、链路追踪、监控实现了数据的汇总，展现给研发的是统一的视角。除了统一面之外，监控还需要有分云分集群的展现，以便快速发现单云单集群级别的故障。

董晓聪：以 Kubernetes 和 Docker 为代表的容器技术极大解决了服务部署和调度的问题。容器技术对应用层屏蔽了底层资源的差异，也包括云厂商的差异。使得我们在基础部署这个层面上更换机型、更换云厂商变得容易。以作业帮为例，更换一款主力机型可以在两周内完成。变更云厂商在解决冷启动后，两千多个服务可在一小时左右完成部署，且运行正常。

在更高一层的调度能力上，容器技术作为统一平台，进而展开调度器优化、在离线混部、HPA、Serverless 的应用。这里面的一部分技术我们是选择自研的，一部分选择应用云厂商的能力。基于容器技术的平台，可以较快在云之间迁移。

董晓聪：作业帮通过 FinOps 理论和自身实践的结合，形成了一套完备的 FinOps，来指导技术成本的管理。

整个体系包括成本的核算、分析、预测、决策、计划和考核。包含的主体不仅包括云平台运维部门、业务研发部门、云厂商，还包括财务、业务线。云平台运维部门实际上担任了二级云服务提供商的角色，是公司进行云成本管控的一号位。需要和运厂商核对云服务的现金流账单，以及给业务研发部门出具云服务的用量账单。最后根据分摊比例，把最终的费用分摊到业务线上。

在多云架构下，云平台运维要建立 CMDB，记录所有云资产。再按照云厂商的计费模式，如包年包月、按使用计费等，再叠加上一定的商务策略，计算出最终的现金流账单，每月和云厂商账单核对。比对出现科目异常时再来比对明细。而对上层出具的用量账单要抹平不同云之间商务策略的不同，归一化到统一的成本视角。基础架构和业务研发部门基于用量成本的科目纬度和业务部门纬度进行成本优化，主要的手段有冗余资源的控制、服务性能优化、资源调度的优化、弹性资源的使用等。

通过这一套成本管控机制的建设，建立了清晰的台帐，让业务线的预算制定更科学，成本管控更有抓手，最终实现了整体优化 40% 的收益。

董晓聪：在明确技术方案后，作业帮多云就开始按照目标进行建设，过程中遇到了一些执行上的困难，以及突发的挑战。具体举几个典型的 case 吧。

一、如何将众多业务线从单云架构平稳过渡到多云多活架构？

对于数十万计算核心这个体量的公司，多云多活架构相对理想的方案是多云同构部署，即所有的应用在多个云厂商上都完整部署，常态下没有跨云的东西向流量，流量通过南北向进行调度。那么从单云架构该如何一步步过度过来呢，尤其是公司还有多种不同类型的业务，流量型、直播课课堂、电商、内部增效平台等等，不同业务线很难保持同一节奏。

我们是通过服务治理中跨云的灵活特性来解决此问题的，对于新建设的云，会将缺失服务默认路由到完备的云机房。这样就需要在业务迁移过程中反复变更注册发现了。除了同步流量外，异步 MQ 这块我们也是使用了类似的方案，通过开发 MQ-proxy，代理控制面，来屏蔽迁云过程中的复杂性。

二、上层应用完成多云多活架构后，如何防止裂化？

当绝大多数存量业务完成改造后，我们又面临一个问题，业务在不断发展迭代，会有新的服务出现，如新业务的应用服务、老业务技术重构的应用服务，如何让他们都遵守常态下东西向流量不跨云的规范。我们是这么来的做的：一方面，从 CD 上进行限制，新模块至少要在两个主力云机房部署。另一方面，从流量上进行限制。一开始我们想的是用纯粹的网络隔离来做，即禁止除中间件的跨云通信。但这样太刚性，不灵活。对于一些临时局部故障要进行东西向切流无法支持。所以探索了一套兼顾灵活和严格的方案。每个云划分为两种网络区域，互通区和受限区。互通区可以和所有区域通信，不同云的受限区不能通信。

这样将所有应用服务放置到受限区，即可以避免他们常态的跨云请求。互通区中放置跨云的网关代理、数据存储的 proxy。如果业务临时需要跨云请求，在跨云网关上进行规则配置，这样就在管控的前提下实现了灵活性。

三、如何精准调度多云的南北向流量？

传统 DNS 可以根据地域和运营商分配流量，但这两个维度无法做到调度的精准。这样就会导致容量和流量的不匹配，在多数业务中这个差异是可以忽略的。但在作业帮流量型产品和直播课课堂场景下，地域的差异较大，这就对我们南北向流量调度的精准性提出了较高的要求。

在之前，作业帮为了应对 local DNS 的缓存、劫持等问题，上线了 DoH 的能力，但之前只使用在通道场景，不对 DNS 解析结果进行变更。在新的要求下，我们增强了 DoH 能力，加入了自定义分配策略。如精准的百分比随机，经过我们的测算，误差可控制在 0.1% 以内，实现了容量和流量高度匹配。

董晓聪：多云对不同群体的开发者有新的要求。

对于业务研发更多是理念上的转变。云原生是要将非功能逻辑抽离到基础设施中，基于云原生的多云架构是要在底层屏蔽多云的差异，不让其蔓延到上层应用。在这个背景下应用服务的逻辑应该和云、IDC 无关，应用镜像、服务发现配置等在多云间也应该是同构的。只要达成这样的效果，在进行云迁移时，业务只需要关心服务运行状态，不需要修改逻辑。才可以真正做了底层基础设施对上层应用透明。

对于基础架构研发会有更高的技能要求，如何在容器、中间件、管控平台等设计实现过程中，践行对应用透明的理念。

除了上述的之外，开发者积极接触学习多云的开源技术也是好的，因为在成熟公司中有明确的职责划分，而在创业期的企业经常一个人身兼数职，这种情况下多云产品能大幅度提升工作效率。