ARTICLE · 软件编程
应用只是冰山一角：构建大规模移动基础设施需要什么
一语总结本文详细介绍了构建服务端网关层如何提升大型电商平台移动应用的性能、发布速度和可靠性，将渲染时间缩短了 50%，并实现了 4 小时内完成变更部署。
本文介绍了拥有数千万用户的大型电商平台在构建大规模移动基础设施时面临的挑战。作者讲述了自己从 Android 开发转向后端基础设施，并构建位于移动应用与后端服务之间的网关层的经历。该网关负责聚合数据、评估功能开关、处理错误，并将每个屏幕的网络请求从 5-7 次减少到 1 次，使商品详情页的渲染时间从 2.8s 缩短至 1.4s。网关还支持后端驱动 UI，让产品变更无需等待应用商店发布，并将上线时间从 10-14 天缩短至 4 小时以内。文章讨论了 3 种 SDUI 方案（全量式、混合式、仅数据式），并解释了选择混合式方案的原因。文中还详细介绍了使用影子模式、金丝雀发布和自动回滚的迁移策略，最后总结了依赖关键性矩阵和容量规划等可靠性措施。
- 服务端网关层通过集中处理数据聚合和业务逻辑，大幅提升移动应用的性能与可靠性。
将响应聚合、功能开关评估和错误处理移至网关后，商品详情页的渲染时间缩短了 50%（从 2.8s 降至 1.4s），每个屏幕的网络请求从 5-7 次减少到 1 次，客户端处理时间也从 900ms 降至 120ms 以内。
- 后端驱动 UI 将产品迭代速度与应用商店的发布周期解耦，支持快速实验和部署。
让应用负责渲染而非决策后，网关使变更部署时间从 10-14 天缩短至 4 小时以内，每月实验次数从 3-5 次增加到 15-25 次，生产环境中的应用版本数也从 8-12 个减少到 3-4 个。
- 迁移线上高流量系统需要谨慎分阶段推进，并采用影子模式、金丝雀发布和自动回滚机制。
迁移过程中，团队使用影子模式对比响应，将流量逐步提升至 1%、5%、25%、50% 和 100%，并在错误率达到阈值时自动回滚；同时依靠监控工具处理只有在生产环境规模下才会显现的边缘情况。
- 要实现大规模系统的可靠性，必须明确产品层面的降级行为，并根据真实流量模式持续进行容量规划。
依赖关键性矩阵将服务调用划分为必需、优选或可选，从而支持自动选择回退方案。容量规划则跟踪不同屏幕、服务和可用区的 p50、p95 和 p99 延迟，以避免促销活动和使用高峰期间出现热点。
应用只是冰山一角：构建大规模移动基础设施需要什么
本文介绍了拥有数千万用户的大型电商平台在构建大规模移动基础设施时面临的挑战。作者讲述了自己从 Android 开发转向后端基础设施，并构建位于移动应用与后端服务之间的网关层的经历。该网关负责聚合数据、评估功能开关、处理错误，并将每个屏幕的网络请求从 5-7 次减少到 1 次，使商品详情页的渲染时间从 2.8s 缩短至 1.4s。网关还支持后端驱动 UI，让产品变更无需等待应用商店发布，并将上线时间从 10-14 天缩短至 4 小时以内。文章讨论了 3 种 SDUI 方案（全量式、混合式、仅数据式），并解释了选择混合式方案的原因。文中还详细介绍了使用影子模式、金丝雀发布和自动回滚的迁移策略，最后总结了依赖关键性矩阵和容量规划等可靠性措施。
文章金句
"「如果移动应用主要是远程服务的客户端，它就应该尽可能少地负责后端编排。客户端承担的这类逻辑越多，应用就越脆弱。」
"「如果我们希望在不发布新应用的情况下改变产品行为，那么控制这些行为的业务逻辑就应该放在服务端，而不是客户端。」
"「把逻辑移到后端之后，应用就成了一块画布。你可以决定在上面画什么。」
"「我们在应用持续运行期间，将整个应用迁移到了新架构。由于无法提前完全复现生产环境的情况，我们采用了谨慎分阶段的迁移策略。」
"「目标是让系统在生产环境中平稳运行、不起波澜。如果系统运行时你还得操心，那就说明出了问题。」