前端架构设计理念与实践——付志敏

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
1. 前端架构设计理念与实践 付志敏 - 百度资深前端研发工程师
2. 个人简介 付志敏,百度资深前端研发工程师。 2016年加入百度,现任搜索产品研发部通用搜索方向前端负责人。 在百度,先后参与了教育体系(百度文库、百度阅读、智慧课堂 等)相关业务的前端架构、部署、运维,以及搜索体系通用搜索方 向的业务实现和技术设计。
3. 目录 • 架构的定义 • 架构的层次 系统层 应用层 模块层 代码层 • 架构的设计原则
4. 架构的定义
5. 架构的定义 • 维基百科:软件架构是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。软件架构会包括软件组件、组件之 间的关系,组件特性以及组件间关系的特性。 • IEEE(1471-2000):架构是指系统组件的基本组织形式,它们之间以及和环境之间的关系,以及指导其设计和演化的原则。 • 关键词: 组织形式(结构)、描述….关系(整体与子系统,子系统与子系统,系统与环境的关系)、提供….指导原则(设计&演化)
6. 架构的层次
7. 架构的层次 代码层 应用层 规范、原则、质量 模块层 模块层 组件化、模块化 应用层 系统层 代码层 框架、模式库、组件库、设计系统 子系统拆分、前后端分离、微前端架构
8. 架构的层次 - 系统层 代码层 应用层 规范、原则、质量 模块层 组件化、模块化 系统层 模块层 应用层 应用层 模块层 代码层 系统层 代码层 框架、模式库、组件库、设计系统 子系统拆分、前后端分离、微前端架构
9. 前端架构 - 系统层 …. 接入层 PHP / Go 层 Node 层 数据模块
10. 前端架构 - 系统层 Node 层 & PHP 层的关系 PHP NodeUI 渲染部分单独子系统 Smarty PHP + VueSSR (Node.js) SanSSR (Node.js) 业务逻辑部分与渲染部分完全分开,单独一个子系统;
11. 前端架构 - 系统层 Node 层部署模型 • 多机房、异地多活 • 容器化部署 • 动态扩缩容 机器 container container container ……
12. 前端架构 - 系统层 Node 层整体设计 - 进程模型 Deamon instance 每个实例(容器)中: • 通过 Node.js 的 cluster 模块,根据 CPU 核数创建 m 个进程,提高 CPU 利用率; cluster1 cluster2 clusterN ….. dict_process • 每个 cluster 主进程,创建 n 个子进程,并发处理阿 拉丁卡片的渲染; • 多个 cluster 主进程,共用一个 dict_process (词典 child1 child2 child3 ….. childN 加载进程),减小内存的消耗。
13. 前端架构 - 系统层 Node 层整体设计 - 渲染模型 Node cluster 主进程 PHP request 主模板渲染 阿拉丁卡片渲染 chunked pack1 头部区域 chunked pack2 前 n 条结果 …. chunked pack3 后 n 条结果
14. 前端架构 - 系统层 Node 整体设计 - 渲染模型 异步非阻塞、多进程并行渲染 Node cluster 主进程 ⻚面主体内容渲染 单条结果渲染 单条结果渲染 单条结果渲染 child 进程 child 进程 …..
15. 架构的层次 - 应用层 代码层 应用层 规范、原则、质量 模块层 组件化、模块化 系统层 模块层 应用层 应用层 模块层 代码层 系统层 代码层 框架、模式库、组件库、设计系统 子系统拆分、前后端分离、微前端架构
16. 架构层次 - 应用层 • 框架:定义项目文件组织标准、规范及约束,项目⻛格明确、清晰、统一。 • 脚手架:便于项目快速搭建,辅助框架的落地实施; • 模式库:代码、功能最大限度复用及共享,降低接入成本; • 设计系统:相当于更高级别的UI组件库,如: AntDsign、 Element;
17. 前端架构- 应用层 HOTH 框架 app1 业务层 app2 ….. app autoload con g view engine dict warmup logger hot reload …… • 基于 fastify • 完备的核心插件 app autoupload: 自动加载、相互隔离 view engine: 模版渲染 框架层 fastify warmup: app 预热自动 hot reload:线下代码热重载 con g:词典加载,包括需要启动 dictload 进程 logger:日志模块,提供统一的日志 运行时 Node Daemon Monitor
18. 前端架构- 应用层 HOTH 框架部署 基础环境 node-base 提供 Node Runtime、fastify、core plugins 一键式集成部署 hoth-cli 脚手架 app 初始化 app1 脚本编译 业务代码 app2 …… 业务子模块拆分代码仓库,独立编译、部署、上线 服务启停 对接paas平台
19. 架构层次 - 应用层 组件化 - 跨应用组件复用 卡片 组件 区块 标题区 内容区 扩展区
20. 架构层次 - 应用层 组件化 - DSL 标准化的界面描述语言,结构化的数据描述。 children:结构关系 props:属性配置 div Title Icon Text Source ThreeImages Image Image Image Text Text
21. 架构层次 - 应用层 组件化 - DSL 的生成 模板配置平台、Sketch 设计稿 div Title Icon Text Source ThreeImages Image Image Image Text Text
22. 架构层次 - 应用层 组件化 - DSL 的生成 H5 DSL dsl2san Template
23. 架构层次 - 应用层 组件化 - DSL 跨端生成组件 H5 组件 可视化编辑平台 NA 组件 Sketch 插件 RN 组件 将模板抽象为结构化数据 DSL,由 DSL 驱动不同实现的组件进行拼装,最终通过解析结构化数据将⻚面渲染出来
24. 架构的层次 - 模块层 代码层 应用层 规范、原则、质量 模块层 组件化、模块化 系统层 模块层 应用层 应用层 模块层 代码层 系统层 代码层 框架、模式库、组件库、设计系统 子系统拆分、前后端分离、微前端架构
25. 架构的层次 - 模块层 什么是模块化: • 将一个复杂的程序依据一定的规则(规范)封装成几个块(文件), 并组合在一起; • 块的内部数据与实现是私有的,只是向外部暴露一些接口(方法)与外部其它模块通信; 模块化的好处: • 避免命名冲突 • 更好的分离, 按需加载 • 提高复用性; • 提高可维护性; • 独立部署上线;
26. 前端架构 - 模块层 模块化 - Molecule 背景: • • • • • 搜索结果⻚是搜索流量的主要流量⻚面,10+ 亿 PV / 天; 相关业务产品线几十条,协同困难; 前端开发者 200+,月迭代 160+ 次,集成模式编译、部署成本高; 模块耦合严重,可维护性低、可复用性低; 当时架构还是 PHP + Smarty 渲染,不支持组件化; 模块化改造迫在眉睫,于是设计了 Molecule 机制; 定义: 基于业务模块拆分出来,可独立代码管理、开发、编译、上线的,在运行时可互相引用的前端模块机制; 难点: • 受限于php,需要提供 ts2php 工具; • 业务迭代快,需要平滑迁移方案;
27. 前端架构 - 模块层 molecule molecule molecule molecule molecule molecule molecule
28. 前端架构 - 模块层 模块化 - Molecule 机制设计 • 每个 Molecule 业务模块: 提供单一 Controller,负责处理数据和渲染 提供单一 CSS/JS 入口文件。 运行时 (Server-Side) • HTML 渲染: Smarty 模板 San 模板 主模板通过 {% molecule %} 引入。 • CSS/JS 渲染: 主模板通过 {% moleculeStatic %} 内联。
29. 前端架构 - 模块层 模块化 - Molecule 实现
30. 前端架构 - 模块层 模块化 - Molecule demo
31. 前端架构 - 模块层 模块化 - 各 Molecule 与主⻚面的关系 结果⻚ 垂类⻚ 落地⻚ …. 模块3 …… Node 运行时 模块1 模块2
32. 架构的层次 - 代码层 代码层 应用层 规范、原则、质量 模块级 组件化、模块化 系统层 模块层 应用层 应用层 模块级 代码层 系统层 代码层 框架、模式库、组件库、设计系统 子系统拆分、前后端分离、微前端架构
33. 架构的层次 - 代码层 ISO/IEC 9126 定义了软件质量模型,包括功能性、可靠性、易用性、效率、可维护性、可移植性。 开发阶段 测试阶段 上线阶段 运行阶段 • 统一代码⻛格规范; • 自动化测试; • 编译速度、上线速度; • 性能监控:首屏性能、⻚面体积等; • 遵循 SOLID 原则; • UT 测试覆盖率 100%; • 流水线可靠性; • 异常监控; • 细化 CR 规范; • E2E 测试; • 环境搭建成本; • 自动化运维; • TDD(测试驱动开发); • 展现 DIFF 对比; • TypeScript 开发; • 线上抽样 Schema 校验; • 组件化开发; • 动态扩缩容; • 千行 BUG 数;
34. 架构的设计原则
35. 架构的设计原则 架构的设计原则: 架构的演进: • 不多也不少 • 更新:让旧的应用的依赖和环境不断更新,以免成为一个不可维护的遗留系统 • 演进性 • 迁移:在改变小量代码的情况下,让旧的应用可以运行在新的架构上 • 持续性 • 重构:对于架构的重构,往往从模块、服务级别上对应用进行代码改善 • 重写:对系统中的部分功能、应用或全部功能,使用新的技术栈、语言进行重写 • 重新架构:从架构的层面上,对应用进行重新设计、拆分
36. Thanks

trang chủ - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-17 02:56
浙ICP备14020137号-1 $bản đồ khách truy cập$