滴滴架构师面经：出行架构演进、实时通信方案、跨端技术选型、技术债治理

上篇聊完资深组件化和热修复，这篇进入滴滴架构师面经。架构师面试不只考技术深度，更考架构决策能力——为什么这么设计、技术债怎么还、团队怎么协作。今天8道题覆盖滴滴架构师面试核心考点。Q1：滴滴出行App的架构经历了哪些演进阶段？单体阶段：创业初期，所有功能在一个module中（订单、支付、地图、IM全耦合）。问题：编译时间长（10分钟）、多人协作冲突频繁、模块边界模糊。组件化阶段：拆分为司机端/乘客端/支付/地图/IM等组件。引入路由框架（ARouter）解耦页面跳转。引入接口下沉解耦组件通信。编译速度提升（增量编译），多人协作冲突减少。动态化阶段：活动页/营销页用H5/RN动态下发（不发版即可更新）。热修复方案（DoLikeTinker）支持线上紧急修复。配置下发系统（AB实验+功能开关）控制功能灰度。平台化阶段：抽象底层能力（地图引擎/支付/IM/推送），支持多App复用（花小猪、青桔单车）。统一技术栈（Kotlin优先），统一CI/CD流程。追问：架构演进怎么推动？不能一步到位——先在边缘业务试点（如营销页组件化），验证可行后推广到核心业务。推动时需要技术委员会决策、各团队配合、文档和培训到位。Q2：实时通信方案（IM/推送）怎么设计？IM场景：司机乘客聊天、客服对话、系统通知。要求低延迟（200ms）、消息可靠（不能丢消息）、离线消息（用户上线后收到离线期间的消息）。