应用只是冰山一角：构建大规模移动应用基础设施需要什么

我在一家大型电商平台工作了六年，那是一家月活跃用户达数千万、拥有数百个后端服务，而且必须依靠一款 Android 和 iOS App 将所有功能整合在一起的平台。在最初的几年里，我是一名 Android 开发人员，负责开发用户能够看到和操作的功能。后来，我转到了另一边。我不再编写移动端代码，转而开始构建团队中每位移动开发人员都依赖的后端基础设施：一个位于移动应用与其他所有组件之间的网关层。 这一转变彻底改变了我对移动开发的思考方式。关于移动应用的大多数讨论都聚焦于用户界面、框架和设计系统。但决定应用是否能流畅运行、能否频繁发布以及在规模化以后能否保持稳定的关键，并非应用本身，而是其背后的支撑体系。 本文将探讨这一层：它的作用、存在的意义、如何正确地进行设计，以及当你试图在没有安全网的情况下，将一个正在运行且流量巨大的产品迁移到这一层时会发生什么。 智能应用存在的问题 移动应用在用户的设备上运行。这听起来显而易见，但在设计系统时，人们很容易低估其影响。设备电池电量有限，内存有限，而且网络连接往往不稳定、速度慢，或者两者兼而有之。你推入应用中的每一段逻辑都在争夺这些资源。 当应用规模比较小时，尚且还可以应对。但当应用服务于数百万用户，并与数百个由不同团队维护的后端服务进行交互时，客户端逻辑的隐性开销就会开始累积。应用运行变慢，崩溃率上升，电池消耗增加。而且，每次修复都需要发布新版本，这意味着都要经过应用商店审核、等待推送，还得指望用户愿意更新。 为了更直观地说明这一点，以下是我们构建网关之前的架构的样子： 该移动应用知道所有的下游服务。它每显示一屏就会发起多次网络请求，在客户端完成响应结果的合并，在本地评估功能开关，并分别处理每个服务的错误模式。仅一个产品详情页就需要调用五到六个服务，而应用中还包含将这些响应拼接成可渲染视图的逻辑。 代价是显而易见的。在占我们用户基数约 60% 的中端 Android 设备上，产品详情页的渲染时间为 2.8 秒。其中，约 1.1 秒是网络时间（包括多个顺序和并行调用），0.9 秒是客户端数据转换时间。该应用的冷启动时间已经悄悄地超过了 4 秒。APK 大小每季度增长约 2 MB，部分原因在于客户端服务集成代码的累积。 当一款移动应用主要作为远程服务的客户端时，它应尽可能少地承担后端协调工作。这类逻辑在客户端占的比重越大，应用就越容易出现故障。 网关模式：一个接口，数以百计的服务 我们构建了一个代理层，位于所有移动客户端与平台后端系统之间。该系统主要有两项职责。 首先，它为移动开发人员预处理数据，使他们无需理解底层的复杂机制即可直接使用。大型电商平台拥有庞杂的后端系统：库存系统、定价引擎、配送物流、推荐服务、支付处理等等。每个系统均由单独的团队负责，有时甚至作为单独的业务单元而存在，拥有各自的代码库和部署管道。 一位正在构建产品详情页的移动开发人员，原本可以不需要了解如何调用五项不同的服务、合并它们的响应、处理局部失败，并将结果转换为 UI 可渲染的形式。网关代他们完成了这些工作。 其次，网关吸收了原本应该存在于应用中的逻辑。数据转换、功能标志评估、响应聚合以及下游故障的错误处理——所有这些都转移到了服务器端。 现在，该应用每显示一屏仅发起一次请求。网关确定了需要调用的后端服务，按最优顺序调用它们（在可能的情况下并行处理），组合响应，应用功能开关和实验变体，并返回一个预先格式化的有效载荷，应用只需要极少的处理就可以将其渲染出来。 迁移完成后的影响评估： 网关模式的权衡 这种架构并非没有代价。引入网关会产生一个新的关键依赖关系，增加一个网络跳数（通常在同一数据中心内为 5–15 毫秒），并且需要一个团队来负责其运维。 延迟。网关虽然增加了一个跳数，但它消除了多个客户端到服务端的顺序调用，取而代之的是单次客户端到网关的调用，以及后续并行进行的服务器到服务器的调用。服务器间调用通过低延迟的数据中心链路进行，而非移动网络，因此净延迟几乎总是更低。就我们的情况而言，消除 4–6 次移动网络往返所带来的收益，远大于额外增加的网关跳数。 运维复杂性。现在，你拥有了一项必须处理所有移动流量的服务。这要求从第一天起就对冗余、自动扩展和断路器进行投资。我们在多个可用区中部署了网关，目标可用性为 99.99%——这比任何单个下游服务的要求都更严格——因为网关故障意味着应用的完全中断。 耦合风险。如果不加注意，那么网关可能会变成一个单体应用。为了避免了这一问题，我们尽量使网关可配置，而非依赖大量的代码。界面定义在配置文件中声明，而非在应用程序代码中。添加新界面或修改现有界面不需要部署新的网关代码；只需更新配置文件，指定要调用的服务、如何组合其响应以及采用何种回退行为。 团队边界。网关团队会成为每个移动端功能的依赖方。为了缓解这一问题，我们构建了自助服务模式：移动端团队可以定义自己的界面配置，然后由网关负责执行。网关团队负责运行时环境和框架；产品团队则负责各自的界面定义。 我进入这一领域的经历并不寻常。我最初是一名 Android 开发人员，花了好几年时间为这款应用开发功能。随后我转入了 Android 基础设施领域，致力于优化其他移动开发人员使用的内部工具。这让我得以洞察开发中的痛点：开发人员会在哪些地方遇到困难，应用会在哪些方面功能过载，以及客户端与服务器之间的边界划分是否合理。当我最终转入后端工作来设计网关时，我将所有这些移动端经验都带入了新岗位。如果没有先在移动端积累起来的实战经验，就很难构建出优秀的移动后端抽象层。 后端驱动的 UI：将开发速度与应用商店解耦 一旦我们将大部分逻辑迁移到网关中，就发生了一件重要的事：我们大多数产品的变更不再依赖移动应用的发布来实现。 发布周期是移动产品开发中最被低估的瓶颈之一。发布新版本意味着要经过 Google Play 或 App Store 的审核流程。这意味着需要花费数天甚至数周的时间逐步推送更新。这意味着即使推送完成后，仍然有相当大比例的用户在使用旧版本，因为用户并不总是会及时更新应用。研究一再表明，用户不喜欢频繁更新；每次更新都会消耗带宽和时间，而过多的更新会侵蚀用户信任。 对于企业而言，这造成了一种令人痛苦的矛盾。产品团队希望快速迭代：开展实验、调整布局、根据数据优化流程。但应用代码中的每一处变更都需要发布，而发布过程又十分缓慢。一个耗时两天开发的功能，可能需要两周时间才能触达大多数用户。 我们的网关架构将应用程序定位为渲染层而非决策层，从而解决了这一问题。服务器描述了应用程序应该显示的内容——渲染哪些组件、按什么顺序渲染、使用哪些数据——而应用程序则负责显示这些内容。我们只需要更新网关配置，不需要修改应用程序代码，也不需要通过数据存储层，就能改变用户所见的内容，而且用户完全不会察觉。 如果我们希望在不发布新版应用的情况下更改产品行为，那么控制该行为的业务逻辑就必须位于服务器端，而非客户端。 引入网关前后的发布速度对比： 一旦将逻辑移至后端，应用就变成了一个画布。你可以控制在上面绘制什么内容。 后端驱动的 UI：模式选择 后端驱动的 UI 有多种实现方式，具体选择取决于你的限制条件。 纯服务器驱动渲染（SDUI）。服务器发送完整的