LinkedIn 是如何逐步淘汰Python 2的？

作者 | Barry Warsaw

译者 | Sambodhi

编辑 | 田晓旭

随着 2020 年 1 月 1 日的到来，长达 20 年的一代传奇 Python 2 终于落幕了，永久退出舞台。InfoQ 曾经发表过《Python 2 宣布正式退休，Python 3 时代到来！》、《从 Python 2 到 Python 3，“迁移与否”是个大问题》、《R.I.P Python 2.x：尽管风靡一时，但现在该说再见了》等多篇文章，今天我们翻译了 LinkedIn 的工程师 Barry Warsaw 的文章，讲述了 LinkedIn 是如何从 Python 2 迁移到 Python 3 的，相信对国内大规模使用 Python 的公司有所启迪。

在 Python 2 的第一个版本发布近 20 年后，在 Python 3 的第一个版本发布 11 年后，Python 开发社区已经淘汰了 Python 2.7，这是 Python 2 系列的最后一个版本。这标志着 Python 2 所有上游支持（包括 Bug 和安全修复）的终结，并让开发人员将他们的时间和精力完全投入到 Python 3 上。Python 3 速度更快，提供了更多的一致性，并为开发人员带来了许多优秀的特性（例如，asyncio、type hinting）。

1 具体的迁移过程

在 2018 年，为了全面迁移到 Python 3 代码库，LinkedIn 投入了长达多个季度的工作。在历经大约两个季度的计划和两个季度的执行后，LinkedIn 在新产品甚至现有产品的新版本中逐步淘汰了 Python 2 的使用。这次迁移是由 LinkedIn 的 Python Foundation 团队领导的，多个团队和部门扮演着一个整体的角色，以确保迁移执行的相对顺畅。这次迁移的工作总共需要迁移大约 550 个代码仓库（库、应用程序和服务）。值得赞扬的是，LinkedIn 的同事理解这次迁移的必要性，并在将 LinkedIn 的基础设施迁移至未来的过程中做出了自己的贡献。

在 LinkedIn，Python 不仅用于为 LinkedIn 的会员提供在线体验，还用于访问内部系统和服务，包括部署工具、CI/CD 框架、脚本、命令行界面、数据科学工具等。除了 Java 和 JavaScript，Python 是 LinkedIn 工程师们完成任务的关键语言。LinkedIn 并没有在其产品中使用 Python，也没有将它作为一个独立的 Web 服务来使用，而是拥有数百个独立的微服务和工具，以及数十个支持库，这些都由独立团队在单独的仓库中所拥有。这些仓库之间的关系可由复杂的依赖关系图表示。

LinkedIn 的迁移故事早在正式迁移开始之前就已经开始了。随着 Python 3 在更大的开源生态系统中变得越来越重要，LinkedIn 的大多数内部库都被移植为“双语”的，这意味着它们可以在 Python 2 或 Python 3 中使用。这一方法，长期以来一直被认为是理想的标准，因为它为这些库的使用者提供了一个平稳的过渡期。如果开发人员小心谨慎，并且库有一个非常清晰的模型，说明哪些数据是字节、哪些数据是文本（人类可读的字符串，即 Unicode），那么这也不是很难做到的事。Python 2 融合了这两个截然不同的概念，但 Python 3 迫使用户理解并明确表示文本数据模型。这是加强数据一致性和避免大多数可怕的 UnicodeError 所必需的，这些 UnicodeError 可能会困扰 Python 2 代码库。

在 LinkedIn 漫长的迁移历史中，这是成功移植所需的最关键的明确性。双语库意味着你不能充分利用 Python 3 的许多最吸引人的新特性。但是，只要 Python 2 仍然受支持，这种折衷就是值得的，因为双语库允许那些库的用户在方便的时候用最少的资源移植到 Python 3。另一方面，应用程序通常不需要使用双语，它们只在一个 Python 版本中运行，因此，它们可以利用 Python 3 的所有新特性、模块和改进。

考虑到这次迁移影响了如此众多的不同团队和数千名工程师的所有 LinkedIn 工程，这项工作是由 LinkedIn 的 Horizontal Initiative（HI）计划监督的。Python Foundation 团队充当了焦点，积极与所有工程领域的开发人员合作，分析 LinkedIn 现有的代码库。他们确定了产品所有者，创建工作单位，回答出现的问题，审查变更，并跟踪即将到来的截止日期。LinkedIn 有大约 550 个仓库需要移植，因此给了自己和合作伙伴两个季度来完成整个计划。

LinkedIn 将工作分为两个阶段进行，连续几个季度进行实施：

• 第一个阶段：在 2019 年第一季度，LinkedIn 执行了详细的依赖关系图的绘制，确定了一些更基础的仓库，因此需要首先进行全面的移植，因为它们会阻塞依赖它们的所有端口。其中包括一些与 Python 3 不兼容的内部库，以及没有阻塞依赖关系的应用程序（命令行工具和微服务）。这是在大约 75 个仓库中计算出来的，这在一个季度内就可以很容易完成，并为 LinkedIn 提供了许多重要的经验、反馈和信心来启动整个移植工作。

• 第二个阶段：在 2019 年第二季度，LinkedIn 确定了需要移植的仓库的其余部分，以及由于任何原因而错过最后期限的第一阶段仓库的任何迁移。

通过这种分阶段的方法，LinkedIn 实现了目标完工日期。LinkedIn 对构建系统进行了更改，禁用了构建 Python 2 应用程序的能力，并停止构建内部 Python 库的 Python 2 版本。

请注意，从任何双语库中删除 Python 2 支持显然不是一个目标。然而，既然 LinkedIn 已经完成了迁移，LinkedIn 的库所有者就有机会放弃 Python 2，并对他们的代码库进行现代化升级，利用任何适当的 Python 3 特性使他们的代码更具可读性或更高效。

2 迁移后的反思

LinkedIn 完成多产品迁移的主要指标是成功构建并通过单元和集成测试。对于具有高覆盖率测试套件的仓库，这在实践中效果很好。但是，LinkedIn 的一些代码库的覆盖率很低。虽然通过构建和测试仍然是 LinkedIn 最好的信号，但 LinkedIn 对端口保真度的信心有时会因那些较低的测试覆盖率而削弱。

对于其他规划迁移或处于正在迁移过程中的组织，LinkedIn 提供以下指导原则：

• 尽早计划，并请组织的 Python 专家参与进来。在受影响的团队中寻找和利用冠军，宣传 Python 3 的优势。

• 采用双语方法来支持库，这样你的库的用户就可以按照自己的计划移植到 Python 3。

• 投资于测试和代码覆盖率：这些将是你最好的成功指标。

• 确保你的数据模型是明确而清晰的，特别是在识别哪些数据是字节，哪些是人类可读的文本时。

现在，LinkedIn 工程已经完全采用了 Python 3，不再需要担心是否支持 Python 2，而且 LinkedIn 的支持负载已经降低了。LinkedIn 现在可以依靠最新的开源库和工具，将自己从不得不编写双语 Python 的束缚中解放出来。LinkedIn 正在适时地、积极地采用类型提示和 mypy 类型检查器，以提高 Python 代码库的整体质量、技术和可读性。LinkedIn 目前支持 Python 3.6 和 3.7，并计划在 2020 年初支持 Python 3.8。

参考链接

https://engineering.linkedin.com/blog/2020/how-we-retired-python-2-and-improved-developer-happiness

点个在看少个 bug   :point_down: