从DUA与Hydra看云计算抽象层设计：简化复杂系统的核心路径

1. 从复杂到简单云计算的抽象化革命如果你在数据中心或者大规模分布式系统里摸爬滚打过几年一定会对“复杂性”这个词有切肤之痛。机器从几百台变成几万台任务从每天几百个变成几十万个资源类型从单一的CPU扩展到CPU、GPU、FPGA、内存、存储的异构混合体。这时候最头疼的往往不是单个组件的性能而是如何让这些庞杂的组件高效、可靠、简单地协同工作。这就像管理一支庞大的交响乐团每个乐手计算资源技艺都很高超但如果缺乏统一的乐谱抽象层和指挥调度框架最终只能得到一片混乱的噪音。最近在NSDI 2024上微软的两篇论文恰好就戳中了这个痛点。它们没有去追逐某个单项性能指标的极致提升而是回归本质思考如何为日益复杂的云计算基础设施构建更优雅的“抽象层”。一篇聚焦于让FPGA这类硬件加速器能像软件一样被轻松调用和互联Direct Universal Access, DUA另一篇则重新设计了超大规模数据分析集群的资源管理器架构Hydra以应对每天数万亿任务调度的挑战。这两项工作的核心思想一脉相承通过创造更高层次的抽象将底层令人望而生畏的复杂性封装起来为开发者和系统管理员提供一个更简洁、更统一的操作界面。这不仅仅是技术上的优化更是一种设计哲学的体现——真正的强大往往源于极致的简化。2. 核心思路拆解抽象的价值与实现路径为什么“抽象”在系统设计中如此重要我们可以把它理解为在用户开发者、运维与复杂硬件/软件基础设施之间搭建的一座桥梁。一个好的抽象应该像高级编程语言一样让使用者无需关心底层是x86还是ARM架构内存是如何编址的网络数据包是如何被拆解和重组的。它提供了一套稳定、统一的接口API让创新可以发生在更高的应用层面。2.1 直面异构资源互联的“巴别塔”困境让我们先深入DUA所要解决的问题。现场可编程门阵列FPGA因其硬件级的并行处理能力和可重构性在数据中心里扮演着越来越重要的角色特别是在网络功能虚拟化、机器学习推理、数据库加速等场景。然而它的潜力一直被一个根本性问题所束缚通信困境。想象一下在一个数据中心里你有成千上万的服务器每台服务器内部可能有CPU、GPU、FPGA、大容量内存和NVMe存储。现在的典型情况是本地通信同一台服务器内FPGA通过PCIe总线与CPU、GPU或本地内存通信。这套协议栈是高速但封闭的。远程通信FPGA想访问另一台服务器上的资源比如远端内存或另一个FPGA则需要通过以太网走的是完全不同的TCP/IP或RDMA协议栈。命名混乱本地资源用物理地址或PCIe BDF号标识远程资源用IP地址和端口标识。两套命名体系互不相通。复用低效一个FPGA可能需要同时与多个本地和远程资源对话。现有的架构很难高效地复用这些异构的物理链路。这就导致开发者想构建一个跨多机、多FPGA的协同应用时不得不编写大量胶水代码来处理不同通信路径的差异相当于为每种资源组合都重新发明一次轮子。开发周期漫长且极易出错。DUA的目标就是终结这种混乱建立一个统一的通信平面。2.2 拆分治理超大规模调度中的“分而治之”哲学再看Hydra面临的挑战它体现了软件工程中另一个经典权衡集中式与分布式。资源管理器的核心职责就两件事1.任务放置决定一个具体任务该在哪台机器上运行。2.份额确定公平、高效地在众多用户和作业间分配集群的总资源CPU、内存等。在集群规模较小时比如几千台机器一个集中式的调度器可以同时很好地处理这两件事。它拥有全局视野能做出最优的调度决策。但是当集群规模膨胀到数万甚至数十万台每天处理百万级作业、万亿级任务时集中式调度器就会成为瓶颈。它的决策延迟会变高吞吐量跟不上一旦宕机整个集群就瘫痪了。完全分布式是另一个极端把调度决策完全下放到每台机器。这虽然解决了扩展性问题但会导致全局性的资源分配策略如公平性、优先级难以实施容易出现“局部最优全局混乱”的局面。Hydra采用的联邦式架构是一种精妙的折中。它没有非此即彼而是创造性地将“任务放置”和“份额确定”这两个问题解耦并交给不同的、松散协调的组件去处理。这背后的逻辑非常清晰任务放置需要快速响应和精细的本地信息比如某台机器当前的内存碎片情况适合本地决策而份额确定需要全局视野来保证公平和效率适合集中决策。这种“拆分治理”的思路是应对超大规模系统复杂性的一个典范。3. DUA详解为数据中心硬件打造“通用语言”DUA的本质是在异构的数据中心资源之上构建一个类似于互联网协议IP层的覆盖网络。IP层屏蔽了底层是光纤、铜缆还是Wi-Fi的差异为所有设备提供了一个统一的“IP地址”命名和路由通信能力。DUA想做同样的事情但是对象变成了FPGA、CPU、GPU、内存和存储。3.1 架构的三重核心设计DUA的架构设计围绕三个核心支柱展开它们共同构成了这个“通用语言”的语法和语义。第一统一的通信接口。DUA为所有资源访问提供了一组一致的、基于消息传递的API。无论开发者是想让FPGA访问本地DDR内存还是访问远端另一台服务器上的GPU显存抑或是读取一个分布式文件系统中的数据块他们都使用同一套函数调用。DUA在底层自动处理与PCIe、以太网、NVMe-oF等各种协议栈的适配。这极大地降低了编程门槛。第二全局统一的命名方案。这是打破资源孤岛的关键。DUA为数据中心内的每一个可寻址资源一块FPGA板卡、一片内存区域、一个存储卷分配一个全局唯一的、与位置无关的标识符UID。这个UID类似于IP地址但它不仅标识网络位置还标识资源类型和能力。通过这个UID应用程序可以透明地访问资源完全无需知晓该资源具体位于哪个机架、哪个服务器。第三底层网络服务路由与复用。这是DUA的“神经系统”。它包含两个核心功能路由当一个FPGA想通过UID访问一个资源时DUA的网络服务能根据全局资源目录自动计算出最优的通信路径是走本地PCIe还是通过RoCE网络跨机访问。复用在FPGA内部DUA实现了高效的硬件虚拟通道。单个物理网络端口如一个100G以太网口可以被虚拟成多条逻辑链路同时服务于多个不同的资源连接请求并且保证隔离性和服务质量。这解决了传统FPGA架构中链路复用效率低下的问题。注意DUA作为一个覆盖网络其最大优势在于可部署性。它不需要更换现有的网卡、交换机或FPGA硬件而是在现有硬件和协议栈之上增加一个软件/固件层。这意味着企业可以以渐进的方式部署DUA逐步享受其带来的简化红利而不必进行“休克式”的硬件换代。3.2 从理论到实践两个应用案例论文中展示了基于DUA构建的两个实际应用充分证明了其价值。第一个是正则表达式匹配Regex Matching用于数据包检测。这是网络安全和网络监控中的经典需求计算模式固定但非常密集。传统做法要么用CPU软件处理性能是瓶颈要么用多块FPGA硬编码不同的规则灵活性和可扩展性差。利用DUA研究人员构建了一个分布式的FPGA正则表达式匹配引擎。多台服务器上的FPGA通过DUA组成一个资源池统一加载规则库。当网络流量进入时可以被动态调度到池中任意空闲的FPGA上进行匹配。DUA的统一访问接口使得流量调度和规则更新变得像操作一个单一的逻辑设备一样简单同时获得了硬件加速的吞吐量和软件级的灵活性。第二个是深度交叉网络Deep Crossing机器学习推理。这是一个用于点击率预测的模型其特征交叉层计算复杂。研究者将模型的不同部分部署在由DUA互联的多个FPGA上。例如将嵌入表查找放在靠近大容量内存的FPGA上将密集矩阵乘放在计算单元更强的FPGA上。DUA使得这些分布在不同的物理设备上的计算单元能够高效、低延迟地交换中间结果仿佛它们是在同一块芯片上一样。这种“异构计算图”的轻松实现为未来更复杂的混合精度、混合硬件AI应用打开了大门。4. Hydra深度解析联邦式资源管理的艺术如果说DUA解决了“资源怎么连”的问题那么Hydra解决的就是“任务怎么跑”的问题。作为微软内部大数据分析集群的支柱Hydra每天调度着海量任务其设计充满了工程智慧。4.1 联邦架构的精妙分解Hydra的联邦架构并非简单地将集群物理分割而是逻辑上和功能上的解耦。子集群Sub-Cluster—— 负责“任务放置”的快速反应部队。一个庞大的集群被逻辑上划分为多个子集群每个子集群管理几千到上万台机器。每个子集群内部运行一个本地的“放置管理器”。它的职责非常专注以毫秒级的速度为本子集群内的机器分配具体的任务。它只关心本地状态哪台机器CPU空闲、哪台机器有足够的内存、有没有数据本地性优势。这种设计带来了极高的吞吐量和低延迟因为决策范围小需要协调的信息少。全局资源管理器Global Resource Manager—— 负责“份额确定”的总指挥部。这是一个集中式的组件但它不处理具体的、细粒度的任务放置请求。它的核心工作是“宏观调配”。它维护着整个集群所有子集群的全局资源视图并执行高层的调度策略。例如公平性确保团队A和团队B按照预先设定的配额如30% vs 70%使用集群总资源。优先级高优先级的生产作业可以抢占低优先级的实验性作业的资源。工作负载管理根据集群整体负载动态调整不同队列的资源上限。全局管理器定期例如每秒向各个子集群的放置管理器下发资源“预算”或“指导方针”。子集群的放置管理器必须在这个预算范围内进行本地调度。例如全局管理器告诉子集群A“接下来一秒你最多可以给‘视频处理队列’分配1000个CPU核心。” 子集群A的本地调度器就会在这个约束下尽可能高效地安排任务。4.2 策略驱动的灵活调度Hydra的强大之处在于其策略引擎。集群运营者可以通过配置策略而不是修改代码来调整调度行为。这些策略可以基于多种维度用户/队列为不同部门或项目组设置资源保障和上限。作业特性长时间运行的批处理作业和短时间交互式作业可能采用不同的调度策略如后者对延迟更敏感。集群状态当检测到某个机架网络负载过高时策略可以自动避免向该机架分配新的数据密集型任务。资源类型对CPU密集型、内存密集型、GPU密集型任务设置不同的安置偏好。这种策略驱动的方式使得Hydra能够适应微软内部极其多样化的工作负载从Cosmos、Scope这样的大规模内部系统到Spark、TensorFlow这样的开源框架都能在其上和谐共处。4.3 实战考验平滑迁移与惊人规模论文中最令人印象深刻的细节之一是Hydra的部署过程“在飞行中更换飞机引擎”。微软的旧有调度系统服务着海量的任务任何停机都是不可接受的。Hydra团队实现了实时、在线的用户迁移。他们逐步将用户作业从旧系统引流到Hydra期间保证服务不中断最终完成了99%用户的迁移。这本身就是分布式系统工程能力的一个壮举。部署后的数据证明了其成功Hydra管理着单个超过5万台机器的集群调度决策的速率比之前的资源管理器高出10到100倍。累计调度了数万亿任务处理了超过一个泽字节Zettabyte的数据。这些数字背后是联邦架构在可扩展性与调度质量之间取得的完美平衡。实操心得在设计大规模系统时“解耦”往往是应对复杂性的第一法宝。Hydra将“放置”快速、局部决策和“份额”慢速、全局决策解耦DUA将“逻辑资源访问”与“物理通信路径”解耦。这种思路告诉我们当一个问题过于复杂时试着分析它的不同维度或时间尺度看看能否将它们分离用不同的、更专注的组件来处理。这比试图用一个“万能”的巨无霸组件去解决所有问题通常要有效和可靠得多。5. 抽象层设计的通用原则与避坑指南从DUA和Hydra这两个案例中我们可以提炼出一些为复杂系统设计抽象层的通用原则和常见陷阱。5.1 优秀抽象层的四大特征透明性这是最高目标。DUA让资源位置透明Hydra让子集群的存在对用户透明。好的抽象应该尽可能多地隐藏底层细节让用户专注于业务逻辑。用户不应该需要知道他的任务跑在了哪个数据中心的哪个机架上。统一性提供一致的接口或模型。无论底层资源多么异构给上层的接口应该尽可能统一。DUA的统一命名和API就是典范。这减少了用户的学习成本和代码的冗余。可扩展性抽象层本身不能成为新的瓶颈。Hydra的联邦架构和DUA的覆盖网络设计都确保了其自身可以随着底层资源的增长而平滑扩展。抽象层的引入不应以牺牲系统规模为代价。可演进性底层技术日新月异比如新的硬件加速器、新的网络协议上层的抽象接口应该相对稳定。DUA作为覆盖层可以逐步集成对新硬件的支持而无需让上层应用重写。这保护了开发者的投资。5.2 实施过程中的常见陷阱与应对策略陷阱一抽象泄露。这是最经典的问题。当你试图隐藏所有复杂性时总有一些底层细节会“泄露”到上层破坏抽象。例如DUA虽然提供了统一访问但远端访问的延迟依然可能比本地访问高几个数量级。如果应用对延迟极度敏感这种差异就无法被完全隐藏。应对策略不要追求绝对完美的透明。可以在抽象接口中提供一些“提示”或“能力查询”机制。比如DUA可以允许应用查询某个资源的“访问延迟类别”本地/跨机架/跨数据中心让有特殊需求的应用进行优化。好的抽象是“大部分时候透明关键时候可控”。陷阱二抽象过度性能损耗过大。每一层抽象都意味着额外的间接层可能带来CPU开销、内存拷贝或延迟增加。如果抽象层设计得过于厚重其性能损耗可能会抵消掉它带来的开发便利。应对策略性能必须作为设计的一等公民。DUA将核心路由和复用逻辑用硬件描述语言实现部署在FPGA上就是为了将性能开销降到最低。Hydra的联邦架构将决策路径局部化也是为了减少通信开销。在设计初期就要建立性能模型并对关键路径进行极致优化。陷阱三管理复杂性转移。系统复杂性不会消失只会转移。DUA和Hydra简化了开发者和用户的体验但将复杂性转移到了抽象层本身的开发和运维中。构建和维护DUA这样的覆盖网络或Hydra这样的联邦调度器本身就是极其复杂的工程。应对策略承认并管理这种复杂性转移。这意味着需要一支强大的平台团队来专门负责抽象层的稳定性、性能和演进。同时抽象层的设计要尽量做到自身模块化、可观测性好提供丰富的监控和调试接口以便于自身的管理。陷阱四拥抱变化与兼容性挑战。技术栈在快速变化新的硬件如CXL互连、DPU、新的框架层出不穷。抽象层需要有良好的扩展机制来集成这些新事物同时还要保证对已有应用的向后兼容。应对策略采用插件化或驱动架构。定义清晰的核心接口和扩展点。新的资源类型或通信协议可以通过实现一个“驱动”插件来集成到DUA中。新的调度策略可以通过配置文件注入Hydra。这保证了核心架构的稳定同时保持了系统的生命力。6. 对未来的启示简化是通往下一代云计算的钥匙回顾DUA和Hydra的工作它们的意义远不止于几项具体的技术创新。它们指向了云计算基础设施演进的一个清晰方向从提供原始的、碎片化的资源到提供智能的、一体化的“计算织物”。未来的云平台在用户视角下可能不再是一个个孤立的虚拟机、容器、GPU实例或FPGA加速卡。它更像是一个统一的、巨量的、异构的计算力池。用户用高级语言描述他们的计算需求例如“我需要运行一个包含Transformer模型训练和实时特征处理的流水线对延迟敏感预算为X”云平台的抽象层由无数个类似DUA和Hydra的组件构成会自动地、最优地将这个需求分解、映射到底层最合适的物理资源上并处理好所有的通信、容错和伸缩问题。这要求云系统软件栈进行深刻的范式转变。我们需要更多像DUA这样横向的、跨资源类型的统一抽象层来打破CPU、内存、存储、加速器之间的壁垒。也需要更多像Hydra这样纵向的、全局协调的调度与编排框架来智能地管理这池化的资源。开源是推动这一进程的关键。DUA即将开源Hydra也已作为Apache YARN的扩展开放。这能让学术界和工业界更广泛地验证、改进这些思想加速整个生态的成熟。对于开发者和架构师而言现在的启示是当你面对一个复杂系统时在埋头优化某个局部指标之前不妨先退一步思考是否可以通过引入一个恰当的抽象层从根本上降低系统的熵让复杂性变得有序。这往往能带来事半功倍的效果也是区分优秀工程师与卓越系统设计师的关键所在。云计算的未来属于那些善于“把复杂留给自己把简单交给他人”的创造者。