作业帮多云架构设计与实践
邓瑞龙 作业帮SRE团队负责人
嘉宾介绍：2019年中加入作业帮，主要负责多云多活建设，推动作业帮传统业务运维进行云原生转型和能力升级。
分享概要
1. 云计算普及，稳定性及成本催生行业多云转型
2. 架构设计：先选型再设计，定目标敢挑战
3. 多云实践挑战重重，想破局，先架构建设再运营管理
4. 多云收益：成本收益可观，稳定性、效率凸显
5. 未来展望
6. 思考与总结
云计算普及，稳定性及成本催生行业多云转型
1 业务背景
作业帮的业务场景，大体有这几种，工具场景、电商场景，还有在线直播场景、智能硬件场景等。业务背后，技术复杂度突显。
2 技术现状
服务数量已达到数千级别，服务实例数量达到数万级别，计算核数已达到数十万级别，技术栈遍地开花，将近 10 个，但主要还是Go和 PHP。业界看，这个量级已初具规模。
3 多云转型
庆幸的是，作业帮一开始就建立在公有云底座之上，享受着早期云计算释放的成本红利。当然反过来，也面临云计算带来的新挑战。单云故障时，我们很无奈；单云锁定，成本优化方向，我们也很无助。
另外随着云计算的普及，别把所有鸡蛋都放同一个篮子里，这一放之四海皆准的思想，逐渐催生整个行业多云转型，作业帮也不例外。
架构设计：先选型再设计，定目标敢挑战
1 多云选型
业界多云选型有很多种，怎么选择适合业务发展的方案呢？从多云核心价值思考，我们重点关注的能力指标，无外乎就这几个：灾难恢复、故障转移、成本优化、避免锁定、数据主权、特定访问。针对这些指标，给它做个加权打分，得出以下结论，如图所示。
显然，多云多活策略，是对以上6个能力指标极致要求的产物，作业帮就是在该选型下进行架构建设和运营管理的。
2 架构设计
选型确定后，架构设计目标关键点如下：
优先从南北向入口进行流量调度，避免专线故障时，调度无能为力；流量进到本云后，其内部服务注册发现要完全闭环于本云内； 同城多云集群，基础和业务服务及其依赖，都要同构部署； 从云上RDS迁移到自建存储服务，避免云厂商深度锁定；打通多云网络低延时互通。
3 架构挑战
第一，如何保障总体服务稳定性？
多云故障率显然加大，是相加还是相乘，取决于错综复杂的服务链路及其依赖，是否都闭环在同一朵云内。若出现跨云，那么某一服务出问题便会影响到全局，故障率即为相乘，反过来则相加。另外，数据跨云部署，脑裂概率也随之加剧。这种情况下，如何保住稳定性？
第二，如何解决多云异构带来的效率问题？
为保以上稳定性，通常需更多混沌工程攻防演练，以防熵增，但人力消耗大。同时，基础设施和服务实例数量较单云成倍增加，再加上多云异构，若不加以技术管理，运维和研发效率将被大受影响，进而反作用于稳定性。
最后，如何控住多云财务成本只减不增？
如果服务冗余多云部署，比如极端情况下，每个云部署 100% 容量所需资源，那成本将成倍增加，并且极其浪费，怎样做才能有更好的收益？
多云实践挑战重重，想破局，先架构建设再运营管理
1 架构建设
自底向上，逐项建设如下。
•多云互通
要玩多云，首要做的，就是把不同云的网络打通。
现阶段，国内网络四通八达，得益于国家基础设施的红利。作业帮在实践中逐步摸索出一套双供应商组网和CPE管控的网络方案，实现在多云拓扑下网络低延时互通，并且具备带宽灵活扩缩、跨云异常流量分析、单节点单线路故障自动切换、新增云供应商快速低成本接入等特性。
星型网络拓扑，平铺抽象后，网络架构如图所示，新云加入，只需在新云上拉两条专线挂到两个环网接入点即可。
•网络规划
网络得有前瞻性规划，开弓便无回头箭，一旦规划出错，后面基本上很难扳回正道。
为了让多云能够具备灵活网络安全和断网管控能力，便结合安全域和部署环境进行网络规划。服务部署在哪个 IDC ，生产域还是办公域，亦或是其他域，其网络应是不同的。作业帮甚至细化网段到服务类型，是数据存储服务，还是其他PaaS服务。
•计算管理
任何一个具备企业级应用的云厂商，都至少会有这样的机型，裸金属、GPU、AMD、虚拟机，计算密集型、内存密集型、网络密集型、磁盘密集型等，多如牛毛。
若再加上多云的机型组合，很容易就带来运维灾难。我们把规模场景特化，得出有限应用场景，最后产出可简单枚举的有限机型。
确定机型后，接着把机型、网络和存储的组合抽象为套餐。三者笛卡尔积之下，套餐数量仍不可控，这就需要套餐管理。采购的时候，从套餐直接下单，实例化后就成为能看得见摸得着的机器。这时候，机器数量太多，超过人肉管理能力，这就需要 CMDB进行全生命周期的管理，直到它被销毁。
•数据存储
为避免云厂商深度锁定，我们率先从云上RDS迁移到自建存储服务。
在多云场景下，自建数据存储面临的主要问题，还是分布式经典的CAP问题。在出现跨云数据分区P的情况下，A可用性和C一致性无法兼得。要么保AP，要么保CP。
解法是根据业务场景做取舍，灵活选择 CP 或者 AP ，并适当牺牲第三维度能力，换来其他两个维度的最优解。场景应用和对策如下。
数据存储 - 云间主从，弱A 保CP
在交易场景中，数据强一致性是首要刚性要求。在多云主从方案设计时，根据CAP理论，适当弱化A 来保 CP。如下图所示，在正常状态下，右边分区读流量访问本云DB从服务，写流量会跨云写入主库，主从之间通过专线低延时同步数据。
故障时刻，右边数据分区DB Proxy 读写均返回失败，确保交易读写数据强一致性。
数据存储 - 云间主从，弱C 保AP
搜索批改等场景，读多写少，需优先保证数据读能力的可用性，极端情况下可接受小概率数据不一致。主从方案设计时，适当弱化C 来保 AP。正常状态下，右边数据分区读流量访问本云DB从服务，写流量会跨云写入主库。故障时刻，DB Proxy 优先可读，但不能写。
数据存储 - 云内单元化，进一步弱C 强保AP
运维预案等强控制面场景，其稳定性要比普通业务还高，最优先保证数据读写的可用性。主从方案设计时，进一步弱化C来更强一步保AP。
云内数据单元化部署，每朵云各自有主从服务，多云间通过DTS进行数据双向复制，并加上数据同步冲突解决策略。其特点是数据不一致概率大，但在运维场景中可以接受。
•注册发现
容器内服务注册发现，直接使用 K8S 原生Service 基于IPVS的能力。
容器内访问虚机的服务注册发现，通过自建 Sync服务，把虚拟化架构 ZNS 节点实例信息，实时注册到 Service ，其Endpoint指向就是ZNS实例信息，这样就可以把它当做统一的Service 看待，并且被容器其他服务所访问。
•服务通信
容器和虚机通信方式，虚拟化架构下，虚机使用水平域名，通过容器网关Ingress请求容器服务，容器网关Ingress和容器内部天然网络打通。容器内部服务间通信使用原生 Service 发现下游服务。
容器访问虚机服务，依托容器外注册发现，其Endpoint指向就是虚机服务实例，对容器调用透明。虚拟化服务间互访，通过中心式名字服务ZNS来发现下游实例。
•流量调度
流量从南北向入口进来，若直接使用传统 DNS 调度，则面临问题如下：
第一，DNS 解析生效时间太长，且长尾不可控。经实践测试，约 90%+的流量，通常可以在十分钟内解析完毕，剩下长尾就不确定了。
第二，传统DNS应答数据易被劫持篡改，有些用户访问会被路由到一些钓鱼网站。
第三，用户所在区域的LocalDNS 缓存历史或问题数据，导致网络传输不符合预期。
解法就是自建DoH服务，并遵守DoH和DoT标准协议，支持DNS over HTTP(s)等三种安全传输模式。App端上所有网络请求，经过统一SDK，该SDK 事先会埋入定制的DoH Server IP，通过该IP并带上域名参数去请求DoH服务，DoH通过权威解析后返回目标IP地址，客户端再使用这个IP通过HTTPs 协议访问后端服务。
从DNS升级到DoH调度，收益明显。DNS劫持问题不复存在，后端应用服务网络成功率提升一个数量级以上，另外多云间流量可按精准比例调度。
•容器迁移
业务关键改造之一是服务容器化，其背后的思考在于通过云原生的规范和能力，实现运维对象同构，方便后续多云部署，灵活控制成本和规模化运维。
作为拥有数年积淀的科技公司，作业帮同样也有此历史包袱：服务规模大，机器规模大；前期为了最大化资源利用率，大量模块，大量服务混部在同一个物理机或者虚机上，耦合关系大。同时，服务间依赖关系又复杂，怎么解？
首先，划分业务迁移节奏。通常，规模化服务迁移可分为三部曲，一般业务第一个吃螃蟹，先试先行；核心业务往往需要观望半年后再跃跃欲试，长尾的边缘服务最后迫于压力跟进上车。
针对一般业务，首要做的便是解除混部，服务化改造，接着把这些业务域名从www公共域名拆分出来，如此便做域名流量调度及容器化迁移。
再者，变更服务发现方式，从中心式名字服务，改为集群内自治的服务发现。
最后，服务迁移到容器环境期间，流量放量比例要可控，操作要具备回滚能力。放量初期，通过东西向按比例逐渐放量，放量比例超50%后，再从南北向入口，把所有流量调度过来，最后达到整体服务平滑迁移到容器。
•多云迁移
严格按照多云规范落地，只要业务迁移到容器环境，它天然就具备多云部署的关键能力。多云迁移，其实就是把等量的服务，在IDC-2部署一遍，然后南北向放量便可。主要挑战是：业务多云部署节奏不一致，以消息队列为代表的异步流量问题异常突显。
比如，一般业务优先双云部署到IDC-2，它生产的消息自然就写入IDC-2的MQ，这时未完成多云部署的核心及边缘业务，就需要同时跨云消费一般业务生产的消息，才能保证消息消费的完整性。
这种情况，不符合单云闭环的架构预期，而且会持续存在，直到所有服务双云部署完备。实际上，需要Proxy服务发现能力，而原生RocketMQ 4.X版本没有此能力，怎么解呢？
短期，人工修改业务跨云服务发现，过渡期跨云无法避免，这时作业帮就通过多云运营系列技术手段，防架构裂变。
中长期，自建MQ Proxy，负责异步服务注册发现。对生产和消费方来说，它只需知道本云Proxy地址，至于Proxy发现到哪朵云的Broker ，那是Proxy内部实现逻辑的事情，生产和消费使用方无需关注。这样经架构和平台进行管控，做到对业务透明。
2 运营管理
架构建设就绪后，不能生而不养，更少不了运营管理。
•多云运营
多云运营，可以按此思路展开：
上边，优先健全多云架构规范，防止架构裂变。左边，结合需求场景和架构规范，DevOps加持，落地平台能力，按规范进行需求交付，控住新增非标问题。右边，结合架构规范和架构现状，进行技术度量，暴露问题，驱动架构治理，修复存量问题。
总地来说，左右开弓，形成闭环，让价值快速流动，通过防裂变、控增量、修存量，达到运维对象同构维持，再通过运维服务化能力，低成本实现规模化运维。
•常态断网
常态断网即典型技术运营场景。背景是初期多云建设一锤子验收通过后，业务变更引入非标问题，导致多活能力功亏一篑。有待解决的是：控住增量，不因业务变更，破坏基础架构能力，所以需要在云间常态断开业务应用的跨云访问。
断网模型是只有数据存储和有限的中间件可以跨云互相访问，有限中间件可以被其他服务互访，但其他服务跨云之间不能直接互访。
断网方案主要有两种：
1)从网络层进行专线域控和虚机例控；
2)从应用层进行ACL控制。
前期Mesh覆盖度不高，主要借助网络能力进行常态断网。前面提到网络规划，此处正好应用起来。具备断网能力之后，进一步借助混沌工程攻防演练，在半夜低峰期间，模拟云间专线故障，有时直接拔断专线，并引入 QA 视角，从真实用户角度进行单云闭环能力验收。验收通过后，持续维持云间常态断网。后续业务变更，但凡它不符合单云闭环规范，首次上线就会有问题，便不会因它变更破坏基础架构能力。
•服务管理
变更类管理，主要是服务上线和运维需求交付。
服务上线无非就是对代码、配置、路由、数据的发布，既要落地运维军规，也要保证部署的一致性，即代码同构、配置同构、路由同构。
作业帮把这些发布抽象为CD流程，中间还加个统一封线管控。
多云场景下业务怎么上线呢？横向依次按照预发、灰度、全流量环境进行发布。纵向各环境按比例发布，比如先发单台，再20%，最后全量发布。同时，把发布工单事务化，在发布生命周期内，但凡哪个环节出问题，就需把工单回滚，其他变更才能继续上线。通过此设计保证多云环境同构，否则会反作用到稳定性。
运维需求交付，也是引发多云架构裂变的变量，在变更方式上，也需要平台进行标准交付。底层，我们抽象出统一工单引擎。上层，把运维场景具象化，比如服务准入、路由变更、容量变更等，接入统一工单引擎，它就变成具体的工单平台。通过平台进行需求交付，不仅符合标准流程，更多的是通过平台把运维军规优雅落地。
•服务观察
主要依托服务日志Metrics & Logging & Trace三大黄金能力，建立可观测多维视角。
首先建立服务观察能力，让多云观察看起来跟单云一样。在此基础上建立多维度观察视角，注重快速圈定故障范围能力，结合故障时间点，观察附近时间范围可疑异常场景、变更事件、异常容量问题等。宏观定位圈定异常范围后，此时就可以决策预案止损。
若问题复杂到不能果断做决策时，还可以借助微观排查，快速下钻触达异常资源、异常服务和异常链路。
•多云预案
多云建设就绪后，怎样最大化其价值？预案即最好切入点之一。
先把预案做全新定义与重构，我们觉得预案就是高度固化的复杂操作集合体，其背后有复杂技术体系支撑，最终需要抽象为一键无脑操作的能力。
实际上，运维背后有各种各样的作业，依托作业平台实现。
把一部分运维作业操作固化之后，它就可以抽象为原子预案。原子预案不直接对外提供服务，仅向上提供编排支持。把原子预案做一次编排，让它变成场景预案，此时，场景预案可应用于局部业务容灾。再把场景预案做二次编排，变成全局预案。这时，全局预案已经抹平所有差异，可应用于单云故障容灾。整体看，就是金字塔模型。
•多云度量
多云度量首要解决的是发现非标架构问题，然后数据驱动架构标准化改造。
另外，通过架构治理改造，也能辅助提高多云度量的数据质量。通过多云度量数据分析，作业帮也发现架构规范短板，反过来完善规范或者生成新规范。如此循环往复，驱动多云架构能力成熟演进。
多云收益：成本收益可观，稳定性、效率凸显
第一，最明显的即成本收益。多云架构转型后，便具备多云厂商选择权利，货比三家，遵守市场规律办事情，议价能力增强。
容量灵活扩缩。业务周期性大促，往往需要准备很多机器资源，多云多活后，大促结束即可退还冗余机器。同时，多云厂商的备货能力之和很强，再利用其竞争关系，无需业务囤积空闲机器。
近期作业帮从某云厂商市中心AZ迁移到冷启动的京郊AZ。此事加之疫情管控干扰，耗时两个多月，将所有服务迁到京郊。因为京郊土地、电力、人力等综合成本便宜，最终作业帮享受到多云多活释放的巨大成本红利。试想，若无多云多活能力，哪怕再大的红利摆在面前，也只能望而兴叹。
第二，稳定性收益。多云故障率会增加，但具备同构部署的多云多活架构后，便可以借助服务观察能力、预案能力，快速逃逸止损，最终服务稳定性有明显提升。
最后，效率收益。单云过渡到多云多活，基础设施和服务实例成倍增加，作业帮通过容器化部署，以及 DevOps 加持，除了商务沟通外，稳住多云管理的综合效率。
未来展望
数据存储进一步演进到分布式架构选型，优雅解决断网演练问题。
南北向入口流量精准比例调度。
持续探索异构多云能力，让多云红利普照业务。
思考与总结
一、多云多活，是作业帮架构转型的攻坚目标，是灾难恢复、故障转移、成本优化、避免锁定、数据主权、特定访问等指标极致要求的产物。
二、多云多活架构关键点是南北向入口流量调度，服务注册发现在集群内自治，服务及其依赖同构部署，自建存储服务避免云PaaS锁定，多云低延时互通。
三、多云多活架构挑战很大，搞得不好，就会更反作用于稳定性、成本和效率。作业帮分别从架构建设，运营管理等多个细分角度持续加以投入，达成既定目标后，享受到了多云释放的巨大红利。这背后需要有很强的技术定力。
四、多云多活，本质上是架构重塑过程，作业帮借助云原生的规范和能力，实现多云运维对象同构，灵活控制成本，并且运维服务化加持下做到规模化运维。
作业帮多云多活，重在建设，贵在运营，拼的是企业综合技术能力，是内功修炼成熟的外在表现。
除此之外，组织建设是第一生产力，忽略这点光谈技术，就很难有效落地。