作者 | 阿里云智能高级技术专家 张磊
美国西部时间 5 月 2 日下午 7 点，Twitter 公司在旧金山总部举行了一次技术发布会兼 Meetup。会上，Twitter 计算平台（Twitter Computing Platform）产品与技术负责人 David McLaughlin 正式宣布，Twitter 的基础设施将从 Mesos 全面转向 Kubernetes。
Mesos 项目发布于 2009 年，而 Twitter 公司则是 Mesos 项目的早期支持者和使用者之一。作为世界上最成功的社交媒体巨头之一，Twitter 公司以其庞大的生产集群规模（万级别节点）而备受关注。2011 年，Twitter 公司开始在 Mesos 项目的基础上开发 Aurora 项目以便同时管理其内部的在线和离线业务，逐步成为 Mesos 社区的代言人。
在持续投入 Mesos 项目近 10 年之后，Twitter公司为什么突然宣布全面转向 Kubernetes 体系？在这个令人瞩目的决定背后，是什么样的架构和设计支撑Twitter 基础设施360度的“华丽转身”呢？
Twitter 公司创始于 2006 年。时至今日，全世界每天都有至少 5 亿条推文产生。在过去十余年飞速成长和海量数据的挑战下，Twitter 基础设施架构的演进过程，一直以来都是全世界技术公司眼中的标杆案例。这其中，像 Mesos 这样优秀的老牌调度框架、 以及像 Aurora 这样启发自 Google Borg 配置管理的编排引擎，可谓功不可没。
事实上，在互联网级别的技术场景下，依托顶级工程师和成熟技术自建基础设施，一直以来都是一线非云互联网厂商的架构首选。正是在这个过程中，相对成熟并且工作层次较低的 Mesos 项目收获到了大量规模级生产环境部署案例。
不过，随着云计算的普及和 Kubernetes 这样以“云”为核心的容器化基础设施项目的迅速崛起，这种传统互联网基础技术架构选型方法逐步暴露出很多前所未有的问题。在本次发布会上， David 就以 Twitter 公司当前面临的挑战为例，对这些问题作出了简明扼要的总结：
相比于传统技术架构对存储系统的单一假设（比如一套 Ceph 打天下），云时代的软件架构为用户存储选择带来了爆发性增长。仅以阿里云为例，它在公有云上能够为用户提供的各种类型的存储服务就多达 10 余种，其中的细分方案更是数不胜数。随着互联网公司的基础架构和软件规模的不断扩张和发展，互联网软件本身对存储的需求也更加细化和专业。
比如，在 Twitter，Local Persistent Volume 这种“非典型”存储诉求，逐渐在平衡性能与成本的过程中成为一种主流方案。作为 CSI（Container Storage Inerface）的提出者，Kubernetes 社区不仅拥有最完善的 Local PV 机制，还能够凭借标准接口和 PV、PVC 体系，完全为用户抹平其它数十种不同存储服务的对接问题。这在互联网软件架构日趋复杂和面向多云的发展趋势中，无疑是至关重要的。
在传统的互联网架构中，自建数据中心和基础设施体系是整个软件系统的第一假设。而“云”所扮演的角色，更像是在流量突发时应付峰值的资源“备胎”。
在这种以“云”为辅助角色的指导思想下，多云和多集群很难成为整个架构的重中之重。这就使得多云和多集群能力，成为底层资源对接层的职责，而与更重要的应用开发、交付和运维体系失去直接关联。这种方案短期内固然可以奏效，但长期的维护和迭代成本却很容易因为上层应用本身千变万化的形态与高速迭代而超出把控。
此外，这种设计的另一个极端是让整体基础设施走向“多活”技术深渊：这实际上已经远远超出 90% 以上互联网公司的技术能力。在云原生体系普及之后，“每朵云上都有无数个 Kubernetes 集群”逐渐成为应用基础设施能够依赖的新常态。
这就为多云和多集群管理提供了一种全新的突破性思路：只要软件选择面向 Kubernetes 来进行架构、设计和实现，那么“多云、多集群”就自然而然成为应用基础设施的默认能力。在 Twitter 的业务越来越多的需要多云、多集群环境交付的趋势下， Kubernetes 这种从根本上帮助应用迅速向多云交付的“捷径”，成为 Twitter 选择变更自身技术体系的另一个重要原因。
