百度 App Feed 流业务架构变迁思考和升级实践

如果无法正常显示，请先停止浏览器的去广告插件。

1. 百度 App Feed 流业务架构变迁思考和升级实践李哲浩 Baidu Feed Android Architect

3. • 过去的架构漫步 • 大环境的冲击 • 采用的架构思想和原则 • 若干场景的架构示例 • 架构维护控制

4. 从仓促开始频道A 展现层V 频道B 展现层V” Android 三方库控制层C 业务逻辑层M 网络日志框架 Android RN 三方库控制层C” 基础设施 DB 频道C 业务逻辑层M” 基础设施 DB” 网络日志框架整体组件化频道D Feed业务组件 Feed SDK Hybrid Copy 用例不多，不够重视迭代不多，不够复杂团队视野受限，经验不足重构就是物理搬移、单例满天飞征战状态，时间紧工程化平台不够完善核心业务深入迭代，产品需求不断叠加还没做好，别人就要用遗留代码基大，架构老旧不敢改模型复杂，系统僵化、脆弱、晦涩

5. • 过去的架构漫步 • 大环境的冲击 • 采用的架构思想和原则 • 若干场景的架构示例 • 架构维护控制

6. 行业众软件架构模式 MVC MVP PAC (HMVC) MVVM MVI model-view-controller model-view-presenter presentation–abstraction–contro l model-view-viewmodel model-view-intent ECB ECS OBR MOA SOA DCI data-context-interaction CQRS entity-control-boundary entity-component-system object-request-broker message-oriented-arch service-oriented-arch Command-Query Responsibility Segregation Hexagonal Onion DDD Clean Redux Flux N-tier Event-driven Plugin-based Component-based Microservices Reactive Systems VIPER VueX MobX Database-centric Micro-frontends Middleware-based

7. 公司平台和环境 Easybox 工程构建 Scheme 协议路由 NPS 插件化 Talos Hybrid Pyramid IoC/服务组件化动态化 webview 增强 Crius BdBus OEM mapping 容器化事件总线技术中台 RN 中台化跨端小程序数据中台业务中台客户端重点技术方向商业产品线内容分发 Feed 搜索研发测试基础技术平台内容消费多团队研发多、测试少 Flutter KMM Jetpack Compose 内容生产全民小视频好看视频百度App 百度贴吧百家号音啵 Flow 新流小度音磁看多多柠檬爱美百度云招财猫慧拍西番秒懂游所为有驾多产品线输出（快速孵化、动态裁剪）

8. • 过去的架构漫步 • 大环境的冲击 • 采用的架构思想和原则 • 若干场景的架构示例 • 架构维护控制

9. 架构影响因素环境行业特征开发方式业务价值组织结构干系人构成功能服务流程商业模式团队成熟度高保持满意关键参与最小投入保持知会权力级别技术约束低低 ROI 数据利益级别高

10. 投入成本比需求发布名义粗估 6天排期 5天（倒排）开发 4天测试 1天发版上线 Bugfix 1.5天预计加班 1天含上版本 bugfix 1 天借调人力 0.5天需求发布正在开发下一个需求实际粗估 4.5天研发效率的提升收益如何度量？ • 这个需求需要记录几天？6 vs 5 vs（4 – 1）+ （1 + 0.5）x 30% + 1.5 • 我们敏捷迭代平台记录了什么？名义粗估、排期 • 假设架构重构需要1个人1个Q投入，名义粗估不会提升，还投资吗？重塑度量积累数据 • 假设实际效率有平台度量，确有5到3人天的提升，重构需要投入1年，若环境变化中断，导致架构四不像，怎么办？架构重构是否有足够power 需求回顾研发质量的提升收益如何度量？架构升级架构复辟脆弱和遗漏带来的bug减少复用带来的bug减少真实复用 copy复用中间件变多带来认知复杂度并行开发冲突抽象带来的性能劣化巨型类加载的性能劣化

11. 团队成熟度黑箱复用白箱复用基本需求/初始代码扩展需求/继承新需求/要求复用原型阶段重构/分解通用化扩展阶段 • • • 争取业务，野蛮增长，重复轮子表现打分 ● 宁可花时间研究fresco，不愿花时间研究打磨现有的项目“复杂”组件； ● 宁可花时间研究花哨的外家功夫，不愿花时间打磨自己的基本内功； ● 不是自己写的代码基本不改，完全无视带来的重复，架构设计的背离； ● 没有制定设计规范，或者存在多套设计规范，互相无法说服，没有顶层架构设计； ● 对单测、代码评审等保障体系建设有抵触，认为给自己带来无意义的麻烦； ● 能copy工作就行，对新技术、团队指标、任何宣贯都漠不关心 ● 团队成员互相不愿意沟通协调解决协作、边界处理等问题 ● 擅长 0-1 Copy，对1-n没有自己的想法，处处依赖上面的指定框架化标准化萎缩阶段巩固阶段 • • 争抢标准，争抢输出你造汽车，我造航母 • ROI至上，强调先验俄罗斯方块类比重视地基重视拼接正确性有code review比没有code review强，没有code review比有code review强，同样适用于测试，即没有勇气，只想遵循规则而不是坚持原则

12. 业务复杂度 • 做一个转换器插件，将RGBA的颜色数组转化成YV12格式的颜色数组技术复杂度可以很高，业务复杂度低 • 做一个简易弹窗提醒（弹窗无要求），有上百种情况，不同情况组合（协同、互斥、相互作用）下，弹窗的文案不同技术复杂度低，业务复杂度可能很高（熵很高） • 文件写入也可能有多种异常情况要处理啊？文件处理是您的主要业务吗？难以理解，难以整合，难以预测

13. 团队成熟度和业务复杂度复杂业务简单业务强制或重组过度设计领域模型设计放任样板间设计简单设计自由人工具人敏捷人

14. 什么应该是模型 { "is_vip":"1" "data": { … } "pass_through": { … } vipTitleColor="#FF0000" title="<b>" + data.title.substring(0, 1) + "</b>" subtitle=data.title.substring(1) } 展现模型 isVip=true 云控模型 if (isVip) { // 解锁 // 更新ui } 业务模型 id | xxxxxx | { … } } json { "is_vip":"1","data": 存储模型关注业务模型  模型应该能用于不同角色的交流  模型是业务需求分析的设计表达，使业务规则显明化  聚焦业务合法性启动加载8条数据填满首屏其他数据延后加载回填技术模型

15. KMM的启示架构层级是否推荐共享业务逻辑是平台访问可选，接口化行为（此部分共享），使用平台API 前端交互（输入交互，后端通信）可选，依赖架构模式 UI展示否业务逻辑不依赖基础设施

16. 前端状态管理方案的启示单向数据流模型响应式状态化（而非接口化）展示层设计    • • • MVI Redux Flux UI被动渲染 UI不能更改状态 UI传递抽象意图 VueX MobX Bloc   一个意图或事件可能多次切换状态 UI只是观察状态变化触发render方法

17. 后端前沿架构的启示依赖方向 Query 接口驱动/主适配器基础设施被驱动/次适配器 Command Controller Entity actor/UI Moment Interval Presenter Value Object Context Gateways Interactor Entity Control Adapter Data • 框架/基础设施 Entity Converter Port event Adapter 其他上下文四色原型 DCI Clean • • bridge Adapter Command DDD • • 核心单测/脚本 • 网络库/Server Methodful Role Boundary • Description Methodless Role • • Remote source Domain Event • • IO Adapter Party Place Thing Use Case Local source Domain Service Aggregate Role 存储/Database Repository 领域层 Application Service IO Port 应用层特点 ECB/EBI • • 依赖反转，端口适配里层不依赖外层不再依赖基础设施不再嫁给框架边界清晰领域模型为核心业务逻辑不泄露关注点分离富血模型用例整洁业务维度隔离易于单测易于维护

18. 快速开发的思考 Feed的同学比较深入，难度大核心业务实现已具备外部团队同学来Feed 无法实现快速开发独立模块独立扩展可裁剪可以实现快速开发大业务认知概念统一有助于实现此目标已具备新入职同学来Feed 重点扩大这里的辐射范围 “标准化” “边界清晰” 技术栈工程能力工具链新人必备的能力目前已必备

19. 组件化壳工程业务组件A 业务组件B 接口层模块业务组件C 下沉通用部分共用依赖基础组件X 基础组件Y 基础组件Z 核心实现层模块扩展实现层模块初步组件化依赖情况组件A 接口层模块接口层模块接口层模块实现层模块实现层模块实现层模块组件A 组件B 组件C 接口层提取接口层模块接口层模块 layout xml 实现层模块业务基础组件实现层模块核心组件 B 实现层模块扩展组件B‘ 实现层模块组件C 贫血模型 data 实现层模块业务组件业务组件膨胀情况物理接口层有助于减少依赖环，随迭代膨胀后，产出一些隐式经验规则： A. 适合核心组件和扩展都在一个团队 B. 适合多团队外部扩展，独立发布、组合使用 C. 历史遗留情况  划分组件类型  减少贫血模型，尽可能接口化  减少布局文件，尽可能code as ui（声明式DSL）

20. 组件化能力集成方式业务中台组件泛化(继承/实现) 基础框架组件包含(聚合/组合) UI组件 Data组件业务基础组件基础技术组件业务支撑组件调用(依赖/关联) 线程池库、网络库、图片库等业务无关 feed容器等点赞、关注等业务组件通用业务特定业务组件能力模型 • • • • • 分离通用和业务，进行业务抽象，分离不变和易变 • • 接口层提取容易程度账号、打点等组件分类 • 服务化程度依赖的服务（下游）提供的服务（上游）身份通信机制生命周期概念完整性关系管理（优先级、互斥、协同、容器父子）动态性（编译期识别/运行时发现，热更新，异常鲁棒性）业务相关性

21. 边界问题 Id=x • 原则1：组件独立、互不依赖列表条目数据json • 原则2：谁的PM提需，胶水、脏活这一方适配开发首页胶水 tid=1 图文落地页首页列表页 tid=2 push 内容搜索落地页 sid=1_1 视频落地页 vid=11 我有一套通用的当前展示内容的通知机制搜索落地页条目2 来自push 电商重复逻辑条目3 Back返回 vid=12 我不想调用你的方法，你提前注册我电商胶水来源是否锚点条目 sid=1_2 视频落地页 API层条目1 点击熊掌按钮返回来自push 首页视频的通知格式 Back 返回图文落地页来源是否我有一套通用的锚点插入机制没有时机？那 application里注册？不想耦合你的通知的数据结构信息业务组件胶水/适配组件胶水/适配组件业务组件

22. 多产品线方案选型矩阵产品+创新孵化产品+不同应用市场渠道差异部分组件1 新分支组件1 组件2 组件3 分支方案：跟随者/独立自主为什么以分支方案为主差异部分组件1 接口化插件扩展 1 组件2 组件3 插件方案：客户和供应商/开放服务差异部分组件1 main  两个团队发版节奏不同，时间不容易match  构建方案版本管理成本大  两个分支差异有工具可以 merge  整体也能得到足够复用  主线定期以矩阵用例回溯改进接口 common lite 组件2 组件3 构建方案：共享内核

23. 架构升级假设业务单元拆解功能单元功能单元调度/分发功能单元调度/分发服务中心通信通信能力单元能力单元能力单元能力单元能力单元能力单元能力单元能力单元能力单元事务脚本领域模型表模块四色原型 DDD战术充血响应式状态插件下发 hybrid RN 梯田式架构  不同的子域根据不同的业务复杂度和质量约束，采用不同的编程范式，建模方式，方法论，开发构建部署形式概念完整度、业务模型边界清晰度、测试覆盖度、团队成熟度、单元细颗粒度是架构可以自然升级的保障升级业务用户量上涨单测  调度/分发事件中心升级单测不单测交互定制易维护性快速开发 NA 业务变复杂领域模型 MVC MVP Compose 能力单元由于粒度细，可以边重构，边进行产品需求开发，重构周期短，有单测验证保障 VS 标准化架构模型：大炮打蚊子，但认知迁移负担小

24. 迁移和升级准备简单列表简单列表简单列表业务自增逻辑层弥补三级列表中台能力不足复杂列表三级列表中台组件带通用业务策略的列表可刷新的通用列表 • 最小级 • 通用业务级 • 饱满业务级基础列表架构现状    架构割裂，四不像，维护成本高复杂列表业务痕迹严重，难复用，中台难落地三级列表中台能力薄弱，其上业务重复造轮严重提前做培训升级问题    权力变更、无法持续投资设计之初未分析好重点对象，另起灶炉、天马行空没有做好培训引导、推广不接受四不像，重塑？

25. • 过去的架构漫步 • 大环境的冲击 • 采用的架构思想和原则 • 若干场景的架构示例 • 架构维护控制

26. 定义结构和语义组件 Processor 业务逻辑组件连接件 Page UI抽象组件管理者消息 Action 连接核心业务逻辑和基础设施、父容器、异构容器约束 (部分摘录) Ability Extension 基础设施抽象组件（UI） Process Context 业务逻辑组件管理者生命周期管理者服务发现者事件派发者业务扩展组件 Plugin Assistant 可动态下发的一类业务扩展集合对外服务接口 Extension Point 连接核心业务逻辑和扩展业务逻辑 • Processor中仅能接受以Ability身份封装的基础设施的交互，不能出现具体的视图类、数据存储类等 • Processor间不能互相直接交互，可以以Assistant的身份交互，或者基于Action消息交互（适合单向单工） • Ability是基础设施的被动封装，谦卑对象， Ability间的交互只能发生在Page、Repository、 DataSource、UnitOfWork等连接件中 • Processor、Ability都可以进行复合使用，但ID标识符应虚拟，并设置为可查找内部组件 • Processor是基于“主营”业务设置的，通用时机应设计Action消息，非通用时机需要设计为Extension Point，供外部注入Extension，禁止非“主营”特定业务以分支(if-else)的方式污染Processor • 各种组件应附着在对应生命周期容器的Process Context里，禁止自建不必要的ID标识符Map、单例等分散的全局引用

27. 事件-组件-系统 Action Action Processor UI 回调1 … 回调N UI 业务a 业务b 业务a Action1 Processor b … Processor a Processor Processor Event ActionN 事件转换器 Action Action Processor Processor c Action 业务c Processor Processor Action Event Sourcing Redux动机/收益 CQRS 单向数据流，预测性好 UI只基于状态更新，Data驱动UI 无缝衔接类React思想组件全局app级state树实现内存数据库单一数据源置信 State不可修改，无副作用从测UI变成测状态，易于单测树状reducer集实现模块化纯函数，增强组合能力

28. 上下文框架 getProcessContext()#query(AssistantA.class) Create View ID 外部组件事件提供的Assistant服务 Touch 依赖的Assistant服务 Extension Point 1 Extension Point 2 Extension Point N load Extension Manager Assistant Manager 服务注册和发现 Dependency Manager Process Context Processor Scroll ID规则管理和组件查找 Processor Container Extension N Assistant N 页面状态监控刷新数据同步模板网络状态运营 … 映射Action的ID 派发Action流查找能处理的Processor集提取组件对外接口回调组件注册观察者按依赖拓扑排序业务维度划分的Processor集 Ability N 编排引擎 Page Repository 框架提供的Process Context能力 Action Dispatcher State Map parent 自定义的Process Context属性 Process Context Plugin/Bundle 三方框架回调

29. 复杂业务-DDD战术设计模型 Message 1 Params 3 1 1 Params 2 1 3 7 4 5 6 1 0 8 9 1 2 1 4 1 6 1 5 最终显示 ① 读取缓存数据一次feed流数据源还原历史 ② 请求网络数据（下拉） ③ 请求网络数据（上滑） ④ 解析数据去重 ⑤ 装配数据 ⑥ 执行云控策略 Action ⑦ 置顶数据去重 Command 重复上滑冲突 ⑧ 普通数据去重 ⑨ 清理过期数据刷新时间间隔频道信息一次feed流刷新协调 DomainEvent 基础设施层 Infrastructure Layer ⑩ 处理黑名单数据 ⑪ 加载更多历史数据 ⑫ 缓存数据 ⑬ 回填数据 ⑭ 插入数据到列表头部 ⑮ 插入数据到列表尾部 ⑯ 通知列表刷新

30. 展示层设计无视图控制图层播放器组件视频播放区手势图层消息中心 loading/fail/empty状态图层 WebView组件运营槽位作者信息槽位 RN组件运营视图图层控制UI图层列表组件推荐区点赞组件操作槽位背景图层评论组件评论区页面图层化页面槽位分区化关注组件收藏组件

31. 展示层设计 Page 业务组装工厂层推荐 Factory 心潮 Factory 热榜 Factory … Factory Layout Ability 页面实现层能力实现层 ListView Page JetpackCompose Page Update RecyclerView实现 Update Compose实现 Navigate实现 Refresh实现 … Page RecyclerView Page 列表图层 items 页面接口层能力接口层 other abilities 能力可注册能力可查找能力可发现能力可替换 Adapter Ability Footer Ability 可点击Footer实现 Popup实现加载型Footer实现 … 实现 Empty View Ability Refresh Ability item UI Page 槽位分区 items Page items other items Page data Update Ability Popup Ability Navigate Ability 页面能力接口化 … Ability Data processors 适配融合(父子）

32. • 过去的架构漫步 • 大环境的冲击 • 采用的架构思想和原则 • 若干场景的架构示例 • 架构维护控制

33. 架构评价和特征度量演进式架构是支持跨多个维度进行引导性增量变更的架构，而架构的适应度函数为这些架构特征提供了客观的完整性评估 --《演进式架构》 ATAM/SAAM GSM-QUANTS 稳定性/抽象性度量 McCabe圈复杂度认知复杂度霍尔斯特德复杂度 DSQI MOOD

34. 架构能力评估模型团队成员 • 是否有经验丰富的架构师 • 成员多大程度有一致的目标和价值观开发过程 • 过程是否已定义、或已量化管理 • 有无采用敏捷开发模型、快速开发模型或有效的项目管理 • 成员中有大中型重构设计经验的比例组件、工具、平台 • 是否有组件库并有足够的组件、以及检索能力 • DevOps平台能够多大程度智能阻止不规范成本 • 是否建立了有效的效率、质量、需求满足度、业务收益等的度量机制 • 架构防劣化可持续性、决策可逆性这些的难度 • 自动化工具占全开发工作的占比决策 • 常规问题决策是否有路径规范可循 • 决策者是否有足够的权力和责任，不受干扰 • 决策的质量和效用能否量化、有无反馈考核机制规范制度、最佳实践 • 规范、最佳实践的数量和质量 • 规范、最佳实践的普及、奖惩、遵守情况

35. 劣化度量监控 • Emacs编辑器可以煮咖啡? 理念：离开发者手边越近的东西就越有价值。不离开IDE就能提供帮助的优于离开IDE • 单例的最好写法是静态内部类方式还是契约规范? 理念：钩子(或切面、插桩)铺开的越多，越规范，就越可控，统计价值越大，架构决策越有效，也越能够自动化。

36. 度量-IDE插件

37. 度量-平台建设管理平台考试平台规范文档平台组件质量度量平台 DevOps

38. 架构过程回顾 • 架构需求分析 • 质量属性甄别 • 架构风格选型和改造设计 • 架构评审 • 架构准备、架构实现和组件库建设 • 架构维护和监控平台建设并行开发、快速启动业务和支援、业务动态下发、尽可能免测、减少质量问题可维护性、可复用性、可扩展性、可测试性梯田方式，以低迁移成本改造为Redux + Hexagonal + DDD等简易ATAM（架构权衡分析方法）架构能力评估、培训、迭代速率度量、权力和完整性、标签建设 6+适应度函数、IDE和DevOps并重、测试体系和个人贡献挂钩

39. 架构升级实践收益测试体系保障开发效率所有NA频道相关业务已全面迁移复用核心业务单测覆盖率从0变成60%+；可归因的效率提升10-20%；接入架构组件来快速孵化相关业务，自动化白盒测试覆盖了刷新主要场景主要来自免测、非单点开发者并行开发、动态裁剪决策和设计自由度平台和能力提升业务模型边界清晰，依赖关系整洁，扩展性好，标准化程度高业务维度隔离，各业务可以更好的根据自己的特点进行维护和质量权衡点决策基础配套设施更全更智能，输出复用收益聚焦、认知成本降低架构升级经验和框架沉淀，团队sense提高、工作强度降低

40.

41.

42.

43.