Uber 新架构 RIBs 的前世今生

末蓝、 2022-10-01 11:44 254阅读 0赞

>  *  原文地址：[Why We Decided to Rewrite Uber’s Driver App][Why We Decided to Rewrite Uber_s Driver App]
>  *  译文出自：[猛犸象][Link 1]

[new\_rider\_app][new_rider_app]

### 为什么 Uber 要重构移动端 ###

Uber 基于一个简单的概念：一键出行。 从最初优享到现在提供的一系列产品，每天在数百个城市协调数百万次乘车。 为了应对和支持2017年及以后的发展，我们迫切的需要重新设计我们的移动端架构。

但从哪里开始？ 我们决定重新开始。于是我们决定完全重构并重新[设计][Link 2]我们的[乘客端][Link 3]。 由于不用被之前的设计和代码限制，在重构上我们有很大的发挥空间。[结果就是你今天看到的这个时尚的新应用][Link 4], 它在iOS和Android上实现了新的移动架构。接下来的文章将介绍我们的新移动端架构 Riblets，让你了解为什么我们需要创建这种新架构模式，以及它如何帮助我们达成目标。

### 目标 ###

虽然共享出行仍然是 Uber 背后的驱动理念，但我们的产品已发展成为功能复杂的APP，我们原有的移动架构无法与之匹配。 随着乘客端App的新功能扩展，工程挑战和技术债务不断累积。增加了诸如[拼车][Link 5] ，[预约乘车][Link 6] 和促销车辆视图等功能，导致工程的复杂性逐步升高。 我们的行程模块变得越来越大，难以测试。 加入小变化有可能影响到应用程序的其他部分，使得功能尝试增加额外调试任务，从而抑制了我们快速迭代和功能实验。 为了给所有 Uber 用户的高质量体验，我们需要一种方法，重新找回起点的简单，同时考虑今天的处境和未来的目标。

对于乘客和 Uber 工程师来说，新的应用程序必须简单。 为了适用于不同的群体，我们的两个主要目标是：持续增加有效的核心用户体验，并且允许在系列产品需求序列中做大胆实验。

#### 可靠性 ####

从工程方面来说，我们正在努力使 Uber 的行程主流程的可靠性达到 99.99％。 实现99.99％的可靠性意味着我们每年只能有一个累计小时的停机时间，一周的停机时间为一分钟，每10,000次运行只有一次失败。

为了实现这一目标，新架构定义并实现了核心和可选代码的框架。 核心代码包括注册，获取，完成或取消行程所需的一切代码。 对核心代码的更改和添加需要经过严格的审核流程。 可选代码可以降低审查力度，可以在不停止核心业务的情况下关闭。 这种代码隔离机制使我们能够尝试新功能，并在异常情况下自动关闭它们，而不会干扰乘车体验。

#### 规划 ####

我们需要一个平台，一百个不同的项目团队和数千名工程师可以快速构建高质量的功能，并在乘客端上进行创新，而不会影响核心用户体验。 因此，我们提供了新的移动端架构，具有跨平台兼容性，确保iOS和Android工程师都可以在统一的基础上工作。

从历史上看，在 iOS 和 Android 上发布最好的应用程序涉及不同的架构、库设计和分析方法。 但是，新架构致力于在两个平台上使用相同的最佳模式和实践。 这给了我们学习两个平台的机会。 由于一个平台的经验教训可以预先解决另一个平台上的问题，从而避免了同样的错误在两个平台重复出现。 因此，iOS 和 Android 工程师可以更轻松地进行协作，并且可以并行处理新功能。

虽然在某些情况下，平台之间可以也应该是不同的(例如 UI 实现)，但是 iOS 和 Android 移动平台都是从一致性出发。平台共享:

*  核心架构
 *  类名
 *  业务逻辑单元之间的继承关系
 *  业务逻辑如何划分
 *  插件点 (名字, 存在,结构等)
 *  响应式编程链
 *  统一平台组件

为了实现平台之间的这种通用蓝图，我们的新移动架构需要清晰的组织和分离业务逻辑，视图逻辑，数据流和路由。这种架构有助于降低复杂性，简化可测试性，从而提高工程效率和用户可靠性。 我们在其他架构模式上进行了创新以实现此目标。

### 从 MVC 到 Riblets ###

考虑到我们的两个目标，我们调查了旧架构可以改进的地方，并研究了可行的方案。Uber 旧的代码遵循\[MVC 模式\]（https://developer.apple.com/library/content/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html）。我们调查了其他模式，特别是\[VIPER\]（https://mutualmobile.com/posts/meet-viper-fast-agile-non-lethal-ios-architecture-framework），我们最终用它来创建 Riblets。Riblets 的核心创新是业务逻辑驱动，而不是视图逻辑驱动。 如果您不熟悉 MVC 和 VIPER，请阅读一些\[关于现代 iOS 架构模式的文章\]（https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52\#.ba5863nnx），然后回过头来看看在 Uber 采用它们的利弊。

#### MVC (Model-View-Controller) ####

乘客端应是在大约四年前由少数几个工程师创建的。 虽然 MVC 模式在当时是有意义的，但随着程序的规模越来越大，也就越来越难以管理。 随着业务的增长和团队的扩大， MVC 的弊端越发明显。具体来说，有两大问题：

首先，成熟的 MVC 架构经常面临[重量级视图控制器][Link 7]的困境。例如，RequestViewController 刚开始有 300 行代码，由于处理了太多的功能（业务逻辑，数据操作，数据验证，网络逻辑，路由逻辑等），现在超过 3,000 行。它变得难以阅读和维护。

其次，MVC 架构的更新过程是不易维护和测试的。我们进行了大量实验，为用户推出了新功能。 这些实验归结为 if-else 语句。 每当将 if-else 语句构建在一个具有许多功能函数的类上时，导致几乎无法推理，更不用说测试了。 此外，由于像RequestViewController 和 TripViewController 代码巨大并且快速增长，因此对应用程序进行更新变得更加空难。 想象一下，进行更改并测试嵌套 if-else 实验的每种可能组合将是多么的困难。由于我们需要实验来继续添加新功能并增加 Uber 的业务，因此这种架构不具备可扩展性。

#### VIPER ####

在考虑 MVC 的替代方案时，我们受到 VIPER 架构的启发。[适用于][Link 8] iOS 应用程序的[简洁架构][Link 9]。VIPER 为 MVC 提供了一些关键优化。首先，它提供了更多的抽象。Presenter 桥接视图逻辑和业务逻辑。Interactor 处理纯粹的数据操作和数据验证，包括向服务层发起调用，例如登录或者发单。最后，Router 启动跳转，例如将用户从首页带到确认页。其次，使用 VIPER 方法，Presenter 和 Interactor 是普通对象，因此我们可以进行简单的单元测试。

但我们也发现了 VIPER 的一些缺点。它是 iOS 独有架构，意味着我们必须为 Android 做出权衡。由于整个应用程序被固定在视图树上，也就意味着状态由视图驱动。 Interactor 必须通过 Presenter 操作应用程序的业务逻辑，因此需要暴露业务逻辑给 Presenter。至此，通过紧密耦合的视图树和业务树，很难实现仅包含业务逻辑或仅包含视图逻辑的业务节点，无法达到解藕的目的。

虽然 VIPER 对使用的 MVC 模式进行了重大改进，但它并没有完全满足，清晰的模块化定义，和高可扩展性。所以我们在兼顾 VIPER 优势，同时规避其架构模式缺点的基础上，实现了我们自己的架构： Riblets。

### Riblets: Uber 乘客端架构 ###

在我们的新架构模式中，业务逻辑被分解为小的，可独立测试的单元，每个单元目的明确，遵循单一责任原则。 我们使用 Riblets 作为这些模块化部件，整个应用程序结构为 Riblets 树。

#### Riblets 组件 ####

通过 Riblets，我们将职责分配给六个不同的组件，进一步抽象业务和视图逻辑：

Riblets 与 VIPER 和 MVC 的区别是什么？路由由业务逻辑而非视图逻辑引导。这意味着应用程序由信息流和决策流驱动，而不是 Presenter。在Uber，并非每个业务逻辑都与用户看到的视图相关。不是将业务逻辑集中到 MVC 中的 ViewController 或通过 VIPER 中的 Presenter 操作应用程序状态。我们可以为每个业务逻辑提供不同的 Riblets，这些 Ribltes 可以组合出不同意义的逻辑分组。 Riblet 模式被设计为跨平台的，达到统一 Android 和 iOS 架构的目的。

每个 Riblet 由 **R**outer，**I**nteractor 和 **B**uilder 及其 Component 和可选的 Presenters 和 Views 组成。Router 和 Interactor 处理业务逻辑，而 Presenter 和 View 处理视图逻辑。

让我们使用车型切换 Riblet 作为示例，确定每个 Riblet 单元负责的内容。

新乘客端APP，车型切换功能。

#### Builder ####

Builder 实例化所有主要 Riblet 单元并定义依赖关系。 在车型切换 Riblet 中，此单元定义城市流（特定城市的数据流）依赖关系。

#### Component ####

Component 获取并实例化 Riblet 的依赖项。 这包括服务，数据流以及其他不是主要 Riblet 单元的内容。 车型切换组件获取并实例化城市流依赖关系，将其与对应的网络事件进行关联，并将其注入到 Interactor。

#### Routers ####

Routers 通过添加和删除 子Riblets 形成应用程序树，同时驱动组件内 Interactor 的生命周期。 这些决定由外部 Interactor 传递。路由器包含两个业务逻辑：

1.  添加和删除组件
2.  子组件间状态切换

车型切换 Riblet 没有任何子 Riblets。 其父 Riblet 的 Router， 确认 Riblet 负责添加车型切换的 Router 并将其 Views 添加到 View 层次结构中。 然后，一旦选择了车型，车型切换 Router 将停用其 Interactor。

#### Interactors ####

Interactors 执行业务逻辑：

*  调用服务来启动操作，比如请求搭车
 *  调用服务来获取数据
 *  决定要转换到下一个的状态。 例如，如果根 Interactor 监听到用户的身份验证令牌过期，它会向其 Router 发送切换到 “欢迎” 状态的请求。

车型切换 Interactor 包含城市流数据，包括该城市服务的车型，定价信息，预估行程时间和车辆视图。 它将此信息传递给 Presenter。 如果用户从拼车切换到优享，则 Interactor 会从 Presenter 接收此信息。 然后它会收集相关数据传给 View，这样它就可以显示 uberX 车辆和预估行程时间。 简而言之，Interactor 执行随后 View 中显示的所有业务逻辑。

#### View (Controller) ####

视图构建和更新UI，包括实例化和布局 UI 组件，处理用户交互，UI 组件数据填充和动画。 车型切换 Riblet 的 View 显示它从 Presenter 接收的数据（车型选项，定价，ETA，地图上的车辆视图）并反馈用户操作（即车型切换）。

#### Presenter ####

Presenters 管理 Interactors 和 Views 之间的通信。 从 Interactors 到 Views，Presenter 将业务模型转换为 View 可以显示的模型。 对于车型切换，这包括定价数据和车辆视图。 从 Views 到 Interactors，Presenters 将用户交互事件（例如，点击按钮选择车型）转换为 Interactors 中的相应操作。

### 整合 ###

Riblets 只有一个 Router 和 Interactor，但可以有多个 View 部分。仅处理业务逻辑且没有用户界面元素的 Riblet 没有视图部分。 因此，Riblets 可以是单视图（一个 Presenter 和一个 View），多视图（一个 Presenter 和多个 Views，或多个 Presenter 和 Views），或者是无视图（没有 Presenter 和 View）。 这允许业务逻辑树的结构和深度与视图树不同，视图树将具有更平坦的层次结构。 这有助于简化页面切换。

例如，乘车 Riblet 是一个无视图的 Riblet，用于检查用户是否有有效的行程。如果已经开始行程，它添加行程 Riblet，将行程显示在地图上。如果没有，它将添加请求 Riblet，请求 Riblet 将在屏幕显示，允许用户请求行程。像乘车 Riblet 这样没有视图逻辑的 Riblet，通过分解业务逻辑驱动应用程序，在支持这种新体系结构的模块化方面，发挥了重要作用。

### Riblets 构建应用程序 ###

Riblets 组成了应用程序树，并且经常需要进行通信以便更新信息或将用户带到下一阶段。 在我们讨论他们如何通信之前，让我们首先了解数据在一个 Riblet 中是如何流动的。

#### 数据流 ####

Interactors 拥有状态的作用范围和业务逻辑。该单元进行服务调用获取数据。 在新架构中，数据是单方向流动的。 它从 Service 到 Model Stream，然后从 Model Stream 到 Interactor。 来自服务器的交互，调度和推送通知可以要求 Service 对 Model Stream 进行更改。Model Stream 生成不可变模型。 这强制要求 Interactors 类必须使用服务层来更改应用程序的状态。

示例流程：

*  **从后端服务到视图:** 服务调用（如状态）从后端获取数据。 将数据放置在不可变 Model Stream 上。 Interactor 监听新数通知并将其传递给 Presenter。 Presenter 格式化数据并将其发送给 View。
 *  **从视图到后端:** 用户点击按钮（如登录），然后 View 将交互传递给 Presenter。 Presenter 在 Interactor 上调用登录方法，该方法调用 Service 进行登录。 返回的令牌由 Service 在数据流上发布。 Interactor 监听数据流，收到通知后 Interactor 切换 Riblet 到首页 Riblet。

#### Riblets 间通信 ####

当 Interactor 做出业务逻辑决策时，它可能需要通知另一个 Riblet（例如，完成）并发送数据。为实现此目的，做出业务逻辑决策的 Interactor 调用另一个 Riblet 的 Interactor 。

通常，如果通信是 Riblet 树上，从子 Riblet 传递到父 Riblet 的 Interactor，则该接口被定义为侦听器。侦听器几乎总是由父 Riblet 的 Interactor 实现。如果通信向下传递给子 Riblet，则应将接口定义为代理，并由子 Riblet 的 Interactor 实现。代理仅用于 Riblet 单元之间的同步通信，例如父 Interactor 与子 Interactor 之间的同步。

特别是对于向下通信，作为代理的替代方法, 父 Riblet 可以选择将可观察的数据流暴露给子 Riblet 的 Interactor。然后，父 Riblet 的 Interactor 可以通过此流将数据发送到子 Riblet 的 Interactor。在大多数用于发送数据的向下通信中，这应该是首选的通信方法。

例如，车型切换 Interactor 确定已选择车型时，它会调用其侦听器以传递所选的车辆视图 ID。侦听器由确认 Interactor实现。然后，确认 Interactor 存储车辆视图 ID，以便可以在服务请求中发送，调用其 Router 分离车型切换 Riblet。

通过以上方式构建 Riblets 内部和 Riblets 之间的数据流通信，我们能够确保在正确的页面正确的时间出现正确的数据。因为 Riblets 基于业务逻辑形成应用程序树，所以我们可以通过业务逻辑（而不是视图逻辑）来路由通信。这对我们的业务意义重大，并最终有助于代码隔离，防止应用程序开发变得过于复杂。

### 回到起点 ###

当我们重新开始乘客端时，希望提高乘客体验的可靠性和为未来的应用程序开发建立标准规范。创建新架构对于实现这两个目标至关重要。

#### 如何提高乘车体验的可靠性 ? ####

Riblets 有明确的职责划分，因此测试更加简单。每个 Riblet 都是可独立测试的。通过更充分的测试，当推出更新时，我们可以对应用的可靠性更有信心。由于每个 Riblet 只负责一个任务，因此很容易将 Riblet 及其依赖项分离到核心代码和可选代码中。通过对核心代码进行更严格的审查，我们可以对核心流程的可用性更有信心。

我们提供了核心流程全局回滚到可用状态的能力。所有可选代码都具备开关能力，如果部分功能有问题，可以将其关闭。在最糟糕的情况下，我们可以关闭全部可选代码，保留默认的核心流程。由于我们在核心代码上有超高的标准，可以确保我们的核心流程始终有效。

#### 如何为开发建立标准规范 ? ####

Riblets 帮助我们尽可能缩小和分离功能。清晰的分离业务和视图逻辑，将有助于防止我们的代码库变得过于复杂并使其易于工作。由于新架构与平台无关，因此 iOS 和 Android 工程师可以轻松了解对方如何开发，从一方的错误中吸取教训，并共同推动 Uber 向前发展。由于 Riblets 帮助我们将可选代码与核心代码分开，因此实验将不太容易对核心体验产生附带影响。我们将能够在 Riblet 架构中将新功能作为插件进行尝试，而不必担心它们可能会意外地将 uberX 和 uberPOOL 体验置于bug 的风险之中。

由于 Riblets 加强了抽象和责任分离，并且有明确的数据流和通信路径，因此持续开发变得很容易。这种架构将在未来几年内为我们服务。

### 星辰大海 ###

我们的新架构使我们为未来的发展做好了准备。最新的重构意味着完全重做乘客端的代码，重新实现以前存在的内容，执行用户研究，案例研究，A/B 测试以及编写新功能。最重要的是，我们希望进行全球推广，以便更快地将新应用程序交付给用户，因此我们从设计，功能，本地化，设备和测试角度考虑了全球变化。 虽然已经投放市场，但我们新架构下的工作才刚刚开始。

转载于:https://juejin.im/post/5c7ce66e6fb9a049ac79e478

[Why We Decided to Rewrite Uber_s Driver App]: https://link.juejin.im?target=https%3A%2F%2Feng.uber.com%2Frewrite-uber-carbon-app%2F
[Link 1]: https://link.juejin.im?target=https%3A%2F%2Fddmammoth.github.io%2F
[new_rider_app]: https://link.juejin.im?target=https%3A%2F%2Fuser-gold-cdn.xitu.io%2F2019%2F3%2F4%2F16947e40e226eb14%3Fw%3D865%26amp%3Bh%3D372%26amp%3Bf%3Djpeg%26amp%3Bs%3D224647
[Link 2]: https://link.juejin.im?target=https%3A%2F%2Fmedium.com%2Fuber-design%2Fdesigning-the-new-uber-app-16afcc1d3c2e%23.wio2h7epr
[Link 3]: https://link.juejin.im?target=https%3A%2F%2Fride.uber.com%2Fen_US%2F
[Link 4]: https://link.juejin.im?target=https%3A%2F%2Fnewsroom.uber.com%2Fnewriderapp%2F
[Link 5]: https://link.juejin.im?target=https%3A%2F%2Fnewsroom.uber.com%2Fus-california%2Fits-a-beautiful-pool-day-in-the-neighborhood%2F
[Link 6]: https://link.juejin.im?target=https%3A%2F%2Fwww.uber.com%2Finfo%2Fscheduled-rides%2F
[Link 7]: https://link.juejin.im?target=https%3A%2F%2Fwww.smashingmagazine.com%2F2016%2F05%2Fbetter-architecture-for-ios-apps-model-view-controller-pattern%2F
[Link 8]: https://link.juejin.im?target=https%3A%2F%2Fmutualmobile.com%2Fin-the-news%2Farchitecting-ios-apps-viper
[Link 9]: https://link.juejin.im?target=https%3A%2F%2F8thlight.com%2Fblog%2Funcle-bob%2F2012%2F08%2F13%2Fthe-clean-architecture.html