前端技术架构与工程 读书笔记

作者 周俊鹏 阅读时间：2021.02.22 ~ 2021.02.23

第一到六章

• 同构：令JavaScript编写的代码既可以在浏览器工作，也可以在服务端工作（ssr支持seo）

• 避免全局变量： 命名冲突、封装破坏性、存在安全隐患、极易引起内存泄漏，非严格模式下没有警告、报错。

• web worker ： h5规范的一部分，与JavaScript无关，是浏览器实现的。

  • 将数据量大、运算逻辑复杂的操作放在后台worker线程中，避免主线程阻塞，提高ui、交互、渲染流畅度
  • 协作方式是主从关系，特征如下：
    1. 被动型，worker线程不能自行启动，也不能加载其他worker，必须等待主线程下发“指令”，但可以通过postMessage项主线程发送消息
    2. 独立性： woker线程不与主线程共享数据，并且有独立的执行上下文
    3. 无状态性： worker线程完成主线程交付的“任务”后，将“工作成果”递交至主线程
    4. 线程安全： 浏览器只允许主线程操作DOM，worker线程不能访问window、document等任何与dom相关联的全局变量、api

• webAssembly:适用于web的汇编（assembly）语言。WASM具有平台无关性，提供比js几倍甚至更高的计算性能。目前的最佳实践是将wasm代码运行在worker线程中。其工作组规划加入gc和访问dom的能力，以后前端领域开发就有了js以外的语言选择

• WebGL：尽可能将计算交给GPU

提高dom相关性能：

• 利用浏览器执行帧（间隔16ms，在这16ms内所有逻辑会被汇总执行），尽可能批量处理对dom api的调用，将dom操作集中在一帧中，从而减少浏览器重绘、重排等性能损耗较高的行为
• 使用virtual scrolling提高长列表滚动性能
• 使用canvas取代dom
• 使用react 虚拟dom类似技术

第七章 工程思维与服务支撑

如何理解前端工程化以及将工程思维引入前端开发

• 工程思维>架构思维> 编程思维> 学生思维

web项目迭代周期

前后端开发-》单元测试--》集成测试-》e2e测试-》验收测试--》前后端部署--》 灰度发布-》正式发布

• 构建（编译(babel)+链接（打包)）
• 模块化、按需加载
• 单元测试
• 性能优化
• devServer
• 源码管理：git flow、gitlab flow、github flow
• 测试支撑： 单元测试、集成测试、端到端测试
• 依赖注入： 使用测试替身（test double）替代真实依赖内容；测试替身包括：stub桩、mock模拟、spy间谍、fake伪装
• 前后端集成
• 运维支撑
• 一键部署
• 日志埋点：命令式埋点、声明式埋点
• 性能监控：SYM(synthetic Monitoring,合成监控）、RUM（Real User Monitoring,真实用户监控）

第八章 DevOps与Serverless

云计算与容器技术（DevOps）\可能改变前后端分层架构的severless与云开发相关技术
DevOps: development（研发） operations（运维）

• 传统软件开发流程：一次性提出需求-》全量设计、编码、测试-》部署、发布； 各职能团队对项目迭代的干预状况比较极端：不干预/ 集中干预，易造问题大量积累，开发工程师提测后白天空闲，晚上收到测试反馈bug，需加班，测试工程师也需要一直待命
• 敏捷开发（Agile software development）:倡导渐进式的轻量开发。将需求分解为一个个轻量的子功能或任务，针对这些任务进行渐进式迭代。流程与传统流程类似：设计、开发、集成、测试，但每次迭代只针对需求的一小部分，缩短反馈回路，加强各职能团队对进度及时干预、快速发现、解决问题、降低整体迭代风险
• 快速应用程序开发（Rapid Application Development, RAD）

适合敏捷开发的软件架构：

• 微内核架构（插件架构）：软件具体功能均有插件提供您，内核只负责对各个插件进行调度、集成；常被用于软件的应用层

• 微服务架构：解耦各项子服务，从而可以单独迭代、部署，降低整体服务的宕机风险

1. DevOps:

强调轻量迭代和持续集成（与敏捷开发相同），面向交付（与敏捷开发不同），每次轻量迭代均会被交付到生产环境。强调交付后的用户持续反馈，作为参考及时修正后续功能迭代。将精益原则应用于软件开发相关的所有团队中，包括运维和研发。最佳诠释参考：Gene Kim编写的《The Phoenix Project》

精益软件开发（Lean software development, LSD）,遵循以下7项原则：

• eliminate waste 消除浪费
• build quality in 内建质量
• Amplify learning 增强学习
• Decide as late as possible 延迟决定
• Deliver as fast as possible 尽快发布
• Empower the team 充分授权
• Optimize the Whole 全局优化

持续交付（Continuous Delivery，CD）:

• 保证质量的快速交付才有价值。适应复杂多变的市场环境。

FEOps（Front-End Ops）

持续交付

• 持续集成（Continuous Integration，CI）：每次代码修改或提交都触发构建和测试。产出面向测试，经过单元测试、编译、构建的内容
  • 持续集成，不以交付为目标，但需要基层支撑，与敏捷开发共同，持续集成的起点是代码提交至仓库的瞬间，但实际上需求确定、评审、设计完成后进入编码阶段就开始了。
  • 角色：
    1. 开发者 将代码提交至远程仓库（源码服务器）
    2. 源码服务器：遵循约定的通信规范（如 webhook），通知CI服务器有新人物
    3. CI服务器：收到通知后对新提交的代码进行构建、测试等一系列流程，产出文件、结果反馈给开发者
  • 人：github flow、gitlab flow需代码合并分支pull request、打tag
  • 本地构建： 自测、降低ci服务器压力（ci扛不住多人并行任务，可以用虚拟机、云技术建立ci服务器集群）
  • 代码review平台（gerrit）
  • 与敏捷看板联动、关联jira
• 自动化测试：集成测试、端到端测试、验收测试
• 部署流水线：CI + 自动化测试 + 部署 + 发布

低风险发布

• 蓝绿部署（blue-green deployment）：通过搭建一个与生产环境完全或尽可能一致，并且独立的预生产环境，在产品发布至生产环境之前先将其部署在预生产环境。配置负载均衡器，识别既定请求规则（如 识别ip地址）将特定的请求引流至预生产环境，完成验收、压力测试后再部署至生产环境，并将流量切换至生产环境。
• 滚动升级（Rolling Upgrade），也叫渐进部署（Gradual Deployment）：将多个服务器按批次递增地更新。需要庞大服务器集群，上线前将部分服务器撤下，升级后再上线。隐患：升级完成前未下线服务器压力过大
• 灰度发布（金丝雀发布， Canary Release）：让部分用户先使用新版本（内测？chrome 就是这么干的）。通过根据地理区域、ip、设备类型等划分用户；还可用于A/B测试：需要在用户端支持两个版本之间的切换（切换开关可发在前端逻辑或网关或路由层，现阶段方案不建议耦合前端逻辑，前端一般提供两套代码）

2.Serverless与前端

BFF（Backend For Frontends）：服务于前端的后端。

• 与nodejs中间层的定位大致相同：位于分层架构的应用层与基础服务层中间，从功能上承载渲染、代理、基础服务接口聚合，以交互逻辑为核心，在一些特定场景下承载部分业务逻辑。
• nodejs足以应对功能简单的bff，且对于前端来说语言亲和性更强
• h5、pc、app各自的技术团队各自负责自身平台的前端和bff
• 服务端开发者，再实现bff基本逻辑和功能是第一步，在此之后，对生产环境的用户规模、并发量等因素进行合理评估，进而与运维工程师共同完成服务器硬件配置升级、集群扩容等工作。

Serverless（无服务器：将服务器的管理与开发者解耦，交于云平台负责）

• 是一种软件设计理念，一种基于云的解决方案
• 为实现构建和运行不需要服务器管理的应用程序的解决方案。
• NoOps(No Operations,无运维)
• Serverless和DevOps都拓宽了研发人员的只能边际，但Serverless和NoOps目前实践都未到理想状态
• Serverless = FaaS（function as a Service，函数即服务） + BaaS（Backend as a Service, 后端即服务）
• 契合互联网市场对产品快速迭代、架构高度伸缩的业务需求。弹性扩容、缩容服务器资源。当下环境（云计算、容器、微服务）允许