本文最初发布于 Computer World 博客，由 InfoQ 中文站翻译并分享。

早在 2016 年，Spotify 就宣布将全力投入谷歌云平台（GCP），据报道，该公司承诺在三年内投入 4.5 亿美元。谷歌之所以能够获得 Spotify 这个固定客户，不仅仅是因为它的品牌和规模，还因为它作为一个以数据驱动、以工程为中心的公司的声誉。

在完成复杂的迁移工作后，2018 年年底，他们就不再提供内部基础设施。

本文源自参与迁移的 Spotify 和谷歌云团队成员的大会演讲，介绍了他们的迁移过程，以及从中汲取的一些主要的经验教训。

为什么迁移？

Spotify 的工程总监 Ramon van Alteren 首先解释了为什么 Spotify 决定全力投入云基础设施。

他说：“对于一家服务于 1.7 亿用户的全球性公司来说，维护计算、存储和网络能力需要花费大量的精力，工作量相当大。”

他补充道，“说实话，我们真正想做的是，让 Spotify 成为世界上最好的音乐服务，说实在的，数据中心的工作对此没有任何直接的贡献”。

Van Alteren 表示，开发人员不用再考虑配置和维护基础设施，而公司也希望能够利用谷歌云的一些创新，特别是 BigQuery 云数据仓库、发布/订阅消息传递和用于批处理和流处理的 DataFlow。

Van Alteren 还表示，向云迁移的动力来自负责维护这些数据中心的工程师，这多少有些令人惊讶。“其中很大一部分人会问，一旦我们转向云计算，他们的工作变成什么样子，”他说。“最终的结果是，一群工程师——其中一些是 Spotify 最受尊敬的人——成为了我们云战略的倡导者。”

服务迁移

实际的迁移计划是 2015 年制定的，大致分为两个部分：服务和数据。

服务迁移的重点是将 1200 个微服务从本地数据中心迁移到谷歌云平台。

根据 van Alteren 的说法，迁移期间的三个主要目标是尽量减少对产品开发的干扰，尽快完成工作以避免在混合环境中运行的成本和复杂性，最后是清理工作，用以确保 Spotify 的数据中心没有任何遗留的服务。

谷歌和 Spotify 做的第一件事就是建立了一个由 Spotify 工程师和谷歌人员组成的小型迁移团队，并构建了整个迁移状态的实时可视化，以便工程师能够自己查看项目的进展。

该可视化看起来像是一组红色（数据中心）和绿色（谷歌云）的气泡，每个气泡表示一个系统，气泡的大小表示涉及的机器的数量。

“这有一些有趣的副作用，其中一个是为我节省了很多时间，作为项目经理，我不用再更新状态，”van Alteren 说，“然后，它为实施迁移的团队带来了真正的成就感，他们可以看到自己产生的影响。”

服务迁移从映射依赖开始，因为在 Spotify 的架构中，每个微服务都依赖于 10 到 15 个其他服务来满足客户的请求。这意味着，“大爆炸”式迁移（即一切都停止），并不是我们的选项，因为客户不希望服务中断。

相反，Spotify 工程团队的任务是通过为期两周的集中冲刺把服务迁移到云上，期间，他们实际上暂停了所有的产品开发。这也让开发团队可以着手评估他们的架构，并停用任何不必要的东西。

在迁移过程中，谷歌云专门为 Spotify 提供了虚拟私有云（VPC）选项。

van Alteren 说，“这让你可以建立类似于一个内部网络，连接多个项目，让它们彼此之间可以通信”。

“这让团队能够很好地掌握自己的命运，他们可以做自己的服务需要他们做的事，如果他们搬起石头砸了自己的脚，那也只是砸了自己的脚，而不是整个公司。”

第二个障碍是由虚拟专用网（VPN）引起的延迟。当 Spotify 开始迁移时，他们发现，转移 1200 个左右的微服务占用了大量的 VPN 带宽。

他说：“老实说，当时的 VPN 服务基本上是为一个 25 人的办公室量身定做的。当我们带着 4 个数据中心出现时，它就不是很奏效了，通过与谷歌合作，我们很快就让它可以很好地工作了。我们在数据中心和谷歌云之间建立了多个 GB 的网络管道，消除了这个依赖问题。”

在消除了这些障碍后，Spotify 就可以开始将用户流量转移到云上了。van Alteren 说：“服务迁移的另一个关键实现是，我们可以将服务迁移与用户流量的转移分离开来。”

“所以，我们有意地分离出了那些专注于让这些应用程序可以在谷歌云上运行的路线图，并有一个单独的路线图，让我们可以逐步地将用户连接到 GCP 上，从而让我们可以控制可靠性、用户体验、迁移速度，以及有多少流量流经这些 VPN 链接。”

一旦服务迁移全部完成，核心迁移团队就开始秘密地在这些云系统中引发故障，记录团队在新架构上如何反应和恢复。

谷歌解决方案架构师 Peter Mark Verwoerd 说：“破坏一些东西并看着团队陷入混乱很有趣，而且，它还有助于确保监控系统经过了适当地扩展，可以适用于新的云部署，如果团队没有注意到，这将是一个很大的危险信号。最后，我们有这个操作手册，他们可以从中了解以前可能没有的、云中的失败模式。”

到 2017 年 5 月，每个迁移冲刺都已完成，流量被路由到谷歌云。然后，在 2017 年 12 月 Spotify 关闭了它 4 个本地数据中心的第一个。此后，第二个数据中心也关闭了，最后两个数据中心（都位于欧洲）也在 2018 年年底关闭。

数据迁移

接下来，Spotify 机器学习基础设施高级产品经理 Josh Baer 探讨了数据迁移，描述了将欧洲其中一个最大的内部 Hadoop 集群迁移到云上的经历。

根据 Baer 的说法，由于依赖图非常复杂，所以将 20000 个每日数据作业转移到 GCP 而又不引起下游故障是一项很大的挑战。

Spotify 首先评估了“大爆炸”迁移的可能性。Baer 说，“关闭 Hadoop 集群，将所有数据复制到 GCP，然后重新启动”。

遗憾的是，即使有每秒 160 千兆的网络连接，也要花两个月的时间才能将 Hadoop 集群中的数据复制到谷歌的基础设施中。“如果我们关闭两个月，我们就没什么业务了，”他补充说。

他们采用的策略是批量数据迁移。

“当你将作业转移到 GCP 时，你会复制依赖关系，然后移植作业，”他解释道，“然后，如果你有下游用户，你可能必须将作业输出复制回本地集群，以确保它们不会被破坏。”由于我们的批量数据迁移持续了 6 到 12 个月，为了填补依赖树上的空白，我们运行了很多这样的作业。”

自然，这样的迁移会耗尽网络带宽，因此，Baer 和他的团队很快就学会了预留资源，并尽可能避免使用 VPN。

对于团队来说，每个冲刺的迁移都有两个选择：如何合适或者时间有限，他们就会直接迁移（他们称之为“叉车式迁移”）；但理想情况下，他们会重写。

“对于那些不习惯使用叉车方式移植作业的团队来说，这很有用，因为他们可能是继承了这些数据作业，而并没有真正地研究它们，如果他们深入研究了，则可能会重写，”Baer 说。

“重写的最大问题是需要团队投入更多的时间，而作为工程师，通常在他们开始写的时候，也会希望重新设计架构。”

“在迁移的中后段，我们不得不告诉所有人，停止重写，只做迁移，如果他们真的想重写，那么等迁移到 GCP 上以后再说，这样，我们仍然可以达成我们的迁移目标。”

Spotify 现在完全在 BigQuery 上运行它的数据栈，每月运行 1000 万次查询和调度作业，总共处理 500PB 的数据。

经验教训

谷歌云战略工程师 Max Charas 提醒说：“这种迁移策略在技术上和组织上都是专门针对 Spotify 定制的，因此，如果你想做类似的事情，它看起来可能会有很大的差别。”

尽管如此，我们还是从迁移中得到了一些重要的经验教训。

首先是做好准备。Charas 说：“我们在迁移前准备了两年时间，每次迁移都需要一年左右的时间。我们试图构建一个最小的用例来展示迁移到 GCP 的好处，但要展示真正的价值绝非一件小事。”

第二是专注。Van Alteren 说：“让一个工程师团队专注于一件事，所能做到的事情会让你觉得很神奇，我们每个冲刺周迁移 50 到 70 个服务。”这还能帮助到你的业务涉众，与长时间不开发产品相比，他们更喜欢短时间不开发产品。如果你试图同时做其他事情，迁移速度就会慢得像爬行一样。”

Charas 表示，第三是建立一个专门的迁移团队，“承担保障任务，帮助他们了解需要了解的东西，传授过去的经验和教训，成为他们需要的资源。”

最后是“尽快摆脱混合模式——所有这些副本作业都是昂贵且复杂的，”Baer 说。

成果

其结果是，在不牺牲服务质量的前提下，Spotify 获得了更大的规模，而开发者获得了更大的自由度。

van Alteren 说：“我们一直在度量服务质量，而且没有发现下降的情况。从中，我们获得了许多好处，包括我们的事件传输管道，它负责向版权所有者支付版税，也是我们产品开发的核心部分。在我们迁移上云的时候，该管道传输峰值是每秒 80 万个事件，看看现在，每秒传输 300 万个事件，信息如此之多，对产品开发来说太疯狂了。”

节省成本？van Alteren 承认：“当我们从集中式采购转向每个人都可以为公司花钱的分布式采购时，这是我们密切关注的一个关键事项。所以这要看实际情况。目前，我们的规模比以前大了，所以很难进行比较，我也无法提供数据。”

感兴趣的读者，可以在 YouTube 上观看完整的演讲视频：

https://youtu.be/5aBORQim-KM

原文链接：

How Spotify migrated everything from on-premise to Google Cloud Platform