百度App Feed流业务架构变迁与升级实践
过去的架构
- 初期架构：基础设施展现层V、业务逻辑层M、控制层C、DB、网络、Android日志框架、三方库。
- 特点：组件化不充分，迭代少且不复杂，团队视野受限，工程化平台不完善。
当前挑战
- 技术难题：模型复杂，系统僵化、脆弱、晦涩。
- 业务需求：核心业务深入迭代，产品需求不断增加。
- 架构问题：重构困难，单例满天飞，使用RN和Hybrid技术。
采用的架构思想和原则
- 架构模式：MVC、MVP、MVVM、PAC、Clean、Hexagonal、Onion、DCI、ECS、Redux、Flux、N-tier、Microservices、Reactive Systems、OBR、SOA、CQRS、MOA、VIPER、VueX、Micro-frontends、Middleware、MobX、Database-centric。
- 平台和环境：组件化、中台化、动态化、Talos、RN跨端、Hybrid、webview、Crius、OEM mapping、KMM、Flutter、Jetpack Compose、Pyramid、IoC/服务NPS插件化、Easybox。
架构维护与控制
- 团队成熟度：重视拼接正确性，重视地基，关注复用和测试。
- 业务复杂度：技术复杂度和技术成熟度的平衡。
- 敏捷开发：通过代码审查和测试提升质量，确保架构的灵活性和可维护性。
改进建议
- 快速开发：组件化、多团队协作、独立扩展。
- 组件化：基础组件、业务组件、壳工程，优化依赖关系。
- 架构升级：引入KMM、Redux、Hexagonal、DDD等架构模式，提升系统的稳定性和可维护性。
- 测试体系：提高单测覆盖率，确保核心业务的稳定性。
收益与成效
- 复用收益：所有NA频道相关业务已全面迁移，聚焦、认知成本降低。
- 开发效率：开发效率提升10-20%，主要来自免测和非单点开发者决策。
- 测试体系：核心业务单测覆盖率大幅提升至60%以上，自动化白盒测试覆盖主要场景。
通过上述措施，架构得到了显著改善，提升了系统的稳定性和可维护性，降低了开发和维护的成本。
