本文主要是介绍Uber 实现平台大规模迁移：第 -2 部分，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

Uber 实现平台大规模迁移：第 -2 部分

这是 Uber 迁移之前文章的延续。

https://medium.com/@jalajagr/uber-fulfillment-platform-migration-at-scale-part-1-e0fb1227c939

使用 Spanner 工作架构的履行架构

优步利用 Spanner 的北美多区域配置作为所有履行实体的存储引擎。我们的履行服务超越了 Uber 自己在北美的运营区域，他们将一系列网络核心连接到 Spanner，为用户进行的每笔交易部署在 Google Cloud 中。
因此，对于每个用户请求或任何系统操作，它都会导致针对 Cloud Spanner 中的一个或多个行以及一个或多个表的事务。借助 Spanner，Uber 能够向内部和外部客户提供我们所有数据的一致视图。优步利用了这种内部部署和云基础设施的混合体。现在，知道将延迟保持在最低限度是像 Uber 这样的应用程序的最大因素。

Uber 的全球网络基础设施团队和谷歌云平台的网络团队，Uber 已经构建了一个极具弹性和高度可靠的网络基础设施来支持 Uber 的工作负载。为了实现这一目标，Uber 将网络基础设施分为两个主要部分——

物理层 ，其中包括 Uber 和云供应商之间的互连，
逻辑层 ，它由物理层之上的虚拟连接组成，以实现冗余。优步通过在每条物理网络路由上设置多个路由器和本地接入点，在这些层之间建立了冗余，并在顶部增加了一层逻辑连接的冗余。

优步甚至在谷歌的所有流量中利用谷歌的私有谷歌访问，谷歌 API 通过云互连 VLAN 附件。
这减少了通过公共互联网路由流量的需要，并提供了额外的可靠性。
为了验证我们的架构，团队提出了一个基准测试套件，可以广泛验证所有物理和逻辑网络路由，Uber 很快发现这个测试设置中的任何低效之处。这对于整个项目的成功至关重要。

迁移策略

这非常棘手。优步从一开始就同意的一件事是内部平台重新架构不应以任何方式影响消费者。因此，Uber 专注于构建能够将任何正在进行的用户会话从我们的旧架构无缝迁移到基于 Spanner 的新架构的技术。现在，由于我们旧平台的数据模型和数据库拓扑与利用 Spanner 的新架构有很大不同，因此排除了任何类型的数据轻迁移。
最初，鉴于大部分数据都是短暂的并且每分钟都在不断变化，因此通过备份进行少量迁移只会导致数据丢失。
因此，Uber 构建了一个系统，可以拦截从用户会话到用户会话开始的世界的请求。如果会话有任何正在进行的订单，Uber 在订单完成之前不会迁移用户会话。对于没有活动订单的开放用户会话，Uber 将它们切换到由 Spanner 支持的新架构。现在，团队通过工具自动化了所有这些，Uber 在我们的测试、暂存和影子环境中严格测试了工具。优步甚至设立了测试城市，
Uber 模拟了数百名乘客和司机，以及他们在现实世界中的行为，以确保 Uber 能够观察到这种迁移的影响。而这些迁移是一个城市一次完成的，有时是一批城市完成的，需要六个多月才能完成。将这种迁移扩展到六个月也有助于我们不断地将业务功能从旧堆栈迁移到新堆栈。有 120 多个业务功能要从旧堆栈迁移到新堆栈。所以从整体技术和执行的角度来看，Uber 作为一个团队承担了一个非常困难和具有挑战性的项目。

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明

本文链接：https://www.qanswer.top/11788/39280318

这篇关于Uber 实现平台大规模迁移：第 -2 部分的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！