很多人第一次听到阿里云飞天，会以为它是某个产品。其实它更接近阿里云底层的一整套分布式系统，负责调度和管理成千上万台服务器上的计算、存储和网络资源。数据库、大数据这些上层服务能稳定运行，基本都靠它托底。
飞天的起点大约在2009年前后。那时阿里巴巴的业务增长很快，交易、搜索、支付这些系统对算力和存储的需求一路往上走。采购通用软件，或者把开源组件零散拼起来，很难同时兼顾规模、成本和稳定性。团队最后选择从底层自己做，把服务器统一抽象成一个能调度、能伸缩的资源池。
“飞天”的名字取自敦煌壁画里的飞天形象，有资源在云端流动的意思。从名字也能看出，团队从一开始就打算把它做成能长期演进的基础平台。
飞天底层主要解决什么问题
拆开来看，飞天通常分成几个模块。分布式存储、资源调度和分布式协调是最常被提到的三块，分别回答数据放哪里、任务跑在哪里、多个节点怎么保持一致。
- 分布式存储：把大量数据切块，冗余存放在多台机器上。某台机器故障时，数据可以自动恢复，上层业务基本感觉不到。
- 资源调度：综合任务优先级、剩余资源和数据位置，统一分配CPU与内存。资源闲置的时候，整体利用率就是这样提上去的。
- 分布式协调与锁服务：多个服务实例并发访问时，保证状态一致。没有这一层，很容易出现重复写入，或者集群脑裂。
- 统一运维与监控：对上万台节点做批量发布、故障自愈和容量预测。机器一多，靠人一台台登录处理就不现实了。
这些能力真正的检验场景是大促和突发流量。峰值来了能不能自动扩容，节点出问题能不能快速把任务迁走，这两点基本决定了一个底层平台是否靠谱。
从内部支撑走向对外服务
飞天最早只服务阿里巴巴集团内部。业务规模上去以后，团队发现同样的能力对外部企业也有用，于是把这些能力逐层封装，做成面向开发者和企业的云服务。
大数据计算服务MaxCompute就是其中一个典型产品。它构建在飞天之上，提供PB级数据的离线计算、数据仓库和分析能力。企业不用自己搭集群，按量使用计算资源即可，原本需要几十台机器才能完成的数据加工，可以按需跑起来。
对外开放之后，难点也变了。内部系统可以围绕自家业务深度定制，面向外部客户则要把多租户隔离、安全合规、计费透明，以及不同行业的差异需求都考虑进去。这一阶段，飞天经历了不少工程层面的重构。
一个零售场景怎么用
设想一家区域零售企业，每年促销季的线上订单会在短时间内涨好几倍。过去它只能按固定规模买服务器：活动前采购太多，平时闲置；采购太少，活动时页面就卡。
如果迁到基于飞天的云平台，订单服务和数据分析任务可以拆进不同资源池。活动前，系统按历史流量模型提前预留计算资源；活动中，实时指标触发自动扩容；活动结束后，资源自动回收。运维团队不用逐台调整机器，工作重心变成在统一控制台里配置策略，并盯住关键指标。
另一类常见场景在政务和金融行业，数据治理是重点。这类客户对安全和合规要求高，往往需要专有云或私有化部署。飞天的多租户隔离和权限体系，能让它们在满足监管要求的前提下共用底层资源池，整体成本也能压下来。
选型时可以先看哪几点
如果你在考虑基于飞天的云服务，可以先从下面几件事判断。
- 流量波动：流量忽高忽低、需要快速弹性的业务，最能用上分布式调度。如果全年负载很平稳，这方面的优势就没那么明显。
- 迁移成本：先盘点现有系统的数据格式、接口依赖和可用的迁移窗口。这几项定下来，上云的节奏基本也就定了。
- 合规与部署模式：公有云、专有云还是混合部署，要看数据的敏感程度来定。别先选好模式，再回头找合规理由。
- 团队能力：云平台能减轻基础设施的负担，但团队要会用云原生的开发和监控方式，否则资源买回来也用不顺。
底层平台的实际效果，最好用真实业务的典型负载压测一轮。重点看扩容速度、故障恢复时间和成本曲线，数据比宣传更有说服力。确认无误后再正式迁移，回退路径也要提前留好。
小结
飞天从解决集团内部的资源瓶颈起步，后来支撑起公有云、专有云和大数据服务。理解它的设计思路，有助于看清云服务背后的工作方式，选型和做架构时也更有依据。
