飞天（Apsara）是由阿里云自主研发的分布式云操作系统，它把散落在数据中心里的成千上万台服务器抽象成一个统一的计算资源池，对上层应用而言，整个集群就像一台性能超强的单机。要理解飞天为什么能做到这一点，关键在于搞清楚两件事：一是它如何协调海量节点的分工协作，二是它如何在业务压力变化时快速扩容和缩容。本文将从架构、核心组件、弹性机制以及常见问题四个方面展开讲解。
一、飞天整体架构：一个Coordinator加N个Worker的经典模型
飞天采用了经典的中心化分布式架构，整体上可以概括为飞行器（Apsara Center，也称Cluster Coordinator）与Worker节点两层结构。飞行器部署在若干台高可用机器上，负责全局的资源管理、任务分配和元数据维护；Worker部署在集群的每一台物理服务器上，负责具体的任务执行、状态上报和心跳维持。
这种设计的好处是架构清晰、全局视野集中。飞行器掌握了整个集群的资源视图，可以站在全局角度做最优调度决策，避免分布式系统里常见的脑裂、资源竞争问题。而它的风险点在于中心节点的可用性，因此飞天在实现上对飞行器做了多副本部署和主备切换机制，一旦主节点故障，备用节点可以在秒级完成接管，保证整个集群的管理面不中断。
在通信层面，飞天内部各组件之间通过自研的高性能RPC框架通信，所有消息都经过序列化压缩，并支持超时重传与幂等处理。这意味着即使在大规模节点同时上报状态的场景下，网络抖动也不会导致任务状态错乱，这是系统能够稳定协同的通信基础。
二、核心组件协作：盘古、伏羲、女娲各司其职
飞天的强大协同能力离不开几个核心组件的配合，它们分别解决存储、调度和协调三类问题。
盘古（Pangu）分布式文件系统是飞天的存储基石。它把所有服务器本地磁盘聚合成一个统一的存储池，向上提供高可靠的文件与块存储服务。盘古采用多副本机制，默认将数据保存三份并分布在不同的机架甚至机房，配合后台的持续数据校验与自动修复，单盘损坏、单机宕机都不会造成数据丢失。对于大数据场景，盘古还支持文件追加写与列式存储优化，能够同时满足低延迟随机访问和高吞吐顺序读写的需求。
伏羲（Fuxi）资源与调度系统负责计算资源的统一管理和任务调度。伏羲把整个集群的CPU、内存、磁盘、网络带宽抽象成可分配的资源单位，用户提交作业时只需声明需要多少资源，伏羲会根据全局负载情况把任务调度到最合适的节点上执行。它的调度算法兼顾了数据本地性，也就是尽量把计算任务分配到数据所在的节点，减少网络传输开销，这一点在大数据分析场景下能把作业执行效率提升数倍。
女娲（Nuwa）协同服务则扮演集群神经系统协调者的角色，提供命名服务、分布式锁和配置管理能力。集群里任何组件要发现其他组件、要抢锁做主备仲裁、要读取最新配置，都通过女娲完成。可以类比一个简化版的ZooKeeper，但针对飞天内部场景做了深度优化，响应延迟更低，支撑的连接规模更大。
这三个组件的分工可以用一句话概括：盘古保证数据放得住，伏羲保证任务跑得动，女娲保证大家找得到彼此。三者协同，整个集群才能像一个有机整体一样运转。
三、高效协同与弹性扩展的实现机制
高效协同的核心在于状态收敛速度。当集群规模达到十万台级别时，任何全局状态的变更（比如一台机器下线）都要尽快让所有相关节点感知。飞天通过增量心跳加版本号机制解决这个问题：Worker只上报状态变化的部分，而不是全量上报；每个元数据都带有递增版本号，节点通过比对版本号判断信息是否需要更新。这种设计把状态同步的网络开销降到最低，即使集群规模翻倍，协调层面的压力也只是线性增长而非指数级增长。
弹性扩展则体现在两个维度。第一个维度是集群规模的水平扩展。飞天采用去中心化的数据分片设计，新增服务器只需安装Worker并注册到飞行器，就能自动加入资源池，整个过程不需要停机，也不需要人工干预存量任务。据公开技术分享，飞天集群可以平滑扩展到数千个节点、乃至连接多个集群形成更大规模的计算网络，支撑双十一每秒数十万笔交易的峰值场景。
第二个维度是业务的弹性伸缩。基于飞天底座，上层云产品可以实现自动扩容：当监控发现ECS实例的CPU使用率持续超过阈值时，弹性伸缩服务会自动创建新实例并接入负载均衡，流量洪峰过后再自动释放，整个过程通常在分钟级完成。这背后依赖的正是飞天对资源的秒级分配能力和盘古对存储的快速挂载能力。
为了更直观地理解弹性伸缩的配置方式，下面给出一个基于OpenAPI调用弹性伸缩的伪代码示例：
// 伪代码：监控CPU超阈值后自动扩容
if (avgCpuUsage(instanceGroup) > 0.8) {
// 声明扩容数量与实例规格
ScaleOutRequest request = new ScaleOutRequest();
request.setScalingGroupId("sg-xxxx");
request.setCount(2); // 新增2台实例
request.setInstanceType("ecs.g7.large");
// 调用飞天底座的资源分配接口
ScaleOutResponse resp = client.scaleOut(request);
// 等待新实例就绪后挂载到负载均衡
waitForInstanceReady(resp.getInstanceIds());
attachToLoadBalancer(resp.getInstanceIds());
}可以看到，业务方不需要关心底层哪台物理机有空闲资源，只需要声明需求，协同与调度全部由操作系统层自动完成，这正是分布式云操作系统相对于传统虚拟化方案最大的价值所在。
四、常见问题与注意事项
在实际使用和运维飞天或基于飞天构建的云服务时，有几个高频问题值得提前了解。
- 扩容后资源分配不均衡怎么办？伏羲的调度以整体最优为目标，短期内可能出现部分节点负载偏高。建议开启负载均衡再平衡策略，但注意避开业务高峰期执行，因为再平衡会触发任务迁移，带来短暂的性能抖动。
- 多副本存储的成本问题。盘古默认三副本意味着存储成本是逻辑容量的三倍。如果业务以日志、备份等冷数据为主，建议选择EC纠删码存储类型，在保证可靠性的前提下把冗余开销降到1.5倍以内。
- 心跳超时与误判下线。如果网络出现长尾延迟，Worker心跳可能超时，导致节点被误判为下线并触发任务迁移。生产环境要合理设置心跳超时阈值，并确保飞行器与Worker之间走独立的内部网络通道。
- 弹性伸缩要有下限保护。自动缩容虽然省钱，但一定要设置最小实例数并配置冷却时间，避免流量突增时因缩容过猛导致服务雪崩。
- 升级与灰度。飞天自身组件升级采用灰度滚动方式，运维侧应关注升级窗口内的任务容错配置，重要作业建议开启检查点机制，失败后可以从断点恢复而不是全部重算。
总的来说，飞天通过飞行器加Worker的中心化架构保证全局调度的高效性，通过盘古、伏羲、女娲三大组件的分工协作实现存储、计算与协调的解耦，再配合版本化状态同步与秒级资源分配能力，最终交出了高效协同与弹性扩展这份答卷。理解了这套设计思路，再去学习Kubernetes、Hadoop YARN等开源分布式系统时会发现很多相通之处，这也是研究飞天这类工业级系统的最大收获。
飞天分布式云操作系统分布式架构弹性扩展修改时间：2026-08-31 02:40:48