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

优步正在发展成为满足日常消费者需求的必需品，在非常高的层面上，当消费者点击“搭车”或“获取食物”按钮时，优步会捕捉用户的意图并通过将其与正确的匹配来实现它附近的一组供应商。 Fulfillment 将用户的意图建模为需求，并将任何可以满足此需求的活动提供者会话建模为系统中的供应。优步开发了平台来协调和管理全球数百万活跃用户会话中正在进行的订单、工作和供应商的生命周期。从本质上讲，履行是一种基础平台功能，可为现有业务线提供动力，并能够无缝地快速扩展新的垂直领域。
该平台每年处理数百万个并发用户会话和数十亿次旅行，遍及全球数千个城市。 Uber 每天处理数十亿的数据库事务。优步有数百个微服务依赖该平台作为任何正在进行的订单、工作或司机和送货员会话的源准确状态。现在，由该平台生成的事件，被数百个离线数据集用于制定关键的业务决策。

优步履行架构

当您打开 Uber 乘客应用程序并请求乘车时，请求会经过一系列检查和验证，最终触发履行以为消费者创建新订单。这个订单代表了消费者的意图，优步将意图转化为个人工作
需要处理的。优步将所有这些信息存储在 Spanner 中。现在，我们的匹配引擎会定期读取这些工作，并提供给附近的任何开放供应商或供应商。

现在，Uber 过去将所有这些数据存储在我们的本地数据库中，而 Uber 最近也迁移到了 Spanner。

在这个原始架构中挑战本地数据库

Uber 利用 NoSQL 存储引擎 Cassandra 来维护本地所有履行实体的实时状态。为了保持一些序列化能力的概念，在 Cassandra 之上，Uber 使 铃声 提供单独的实体级序列化。有一些重大挑战，但让我强调其中的几个。 Cassandra 建立在范式之上
的最终一致性。除此之外，在多数据中心设置中，Cassandra 很难保证低延迟的仲裁写入。随着 Uber 产品和服务的发展，Uber 开始看到需要多行和多表写入的复杂存储交互。因此 Uber 不得不构建一个应用层框架来利用 saga 模式来编排这个操作。由于 Cassandra 的底层存储平台最终保持一致，因此通常会导致必须手动更正的不一致。

它在现实世界中的翻译是，一个骑手看到两个不同的司机被派往他们身边。想象一下，你在办公室附近，有两个司机来接你。对于那里的任何人来说，这有点令人困惑。随着 Uber 在全球范围内扩展到数百万活跃用户，在我们的应用程序级别上，即使是一致性的概念也变得更加难以实现。除了所有这些，随着 Uber 的扩展，它开始出现水平扩展瓶颈，以及整体架构，实际上，因为 Uber 从我们的应用程序层开始使用 Ringpop 的方式。这是 Uber 开始追溯我们的步骤，以追溯传统的基于 SQL 的存储引擎的属性，该引擎提供资产保证。优步开始定义一个事务存储引擎，它将提供一致性作为主要功能。主流技术中的一件事是新的 SQL 存储引擎，它将 NoSQL 架构的可扩展性与强大的 ACID 保证相结合。这是 Uber 遇到 Google Cloud Spanner 的时候。

从 NoSQL 迁移到 New SQL 的教学过程

当优步考虑优步履行平台的下一章时，对一致性的关注成为主要评估标准之一，以及高弹性和可用性。根据他们的要求和各种基准，他们评估了现有的各种新 SQL 存储引擎——CockroachDB、FoundationDB 和 Cloud Spanner。 Cloud Spanner 提供了所有的功能需求，它可以根据它们的基准进行水平扩展，并为我们提供了用于集群管理和维护的托管解决方案。

我们将通过以下链接继续本文的第二部分。

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

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

本文链接：https://www.qanswer.top/11790/39330318