共计 3276 个字符，预计需要花费 9 分钟才能阅读完成。
全文 3268 字，预计浏览工夫 8 分钟
目录：
一、名词解释
二、业务背景：新增服务市场业务线
三、窘境：服务端的渲染由后端主导，前端只负责产出动态（浏览器端执行）js 文件
四、从新开始：前端也能做服务端渲染，js 也能在服务端生成 html
- 1：引入 Node.js 做服务渲染层
- 2：确定 SSR 技术计划 node-vue-ssr
五、新的挑战：Node.js 和 SSR 的退出，同构逻辑繁杂
六、正当分层：拆解不同端的复杂度，一次开发多端失效，进步开发效率
七、配置化开发：每一层开发单元如何工作传递给下一层
- 1：node 层：数据抓取和 SSR 渲染
- 2：前端工程化：客户端和服务端的桥梁
- 3：数据配置层，保护数据统一
- 4：状态解决层：对于获取的数据进行筛选
- 5：页面层：渲染
八、其余：
九、结语：
- 劣势
- 毛病
- 比照：在 rd 机器动态产出和革新后在 Node 机器上通过 SSR 构建的各项指标比照
- 1：加载总时长时长
- 2：其余指标比照
- 将来和瞻望
一、名词解释:
二、业务背景：新增服务市场业务线
随着百度爱洽购的倒退，咱们致力于打造本人的商业生态，以爱洽购为外围，以搜寻流量为根底，打造服务市场平台。服务市场致力于服务全网 B 端商家。搜寻流量是咱们的基石，咱们须要服务端渲染来进步咱们的搜寻排名，当然服务端渲染也能进步一部分用户体验。
三、窘境：服务端的渲染由后端主导，前端只负责产出动态（浏览器端执行）js 文件
咱们是爱洽购前端团队，爱洽购的整体技术设计是后端采纳 php 服务，C 端以 Smarty 渲染引擎来进行渲染。前端通过工程化，产出 Smarty 引擎源文件。导致前后端并未彻底进行前后端拆散，前端过于依赖后端渲染，整体的优化和提效过于局限。新的零碎冀望继承老零碎的劣势，丢掉它的包袱，在不足之处从新开始。
流程图如下：
四、从新开始：前端也能做服务端渲染，js 也能在服务端生成 html
通过调研剖析，Node.js 也能反对服务端渲染，而且性能并不逊色于 php 的 Smarty 渲染引擎，在整个部门围绕着提效和跨平台合作的前提下，整个服务市场的技术选用 Node.js 作为渲染引擎，以加强前端能力实现跨平台和提效。
流程图如下：
1：引入 Node.js 做服务渲染层
自身，渲染就是前端的工作量，引入 Node.js 层来做渲染，次要是缩小后端关注点，使后端仅作为数据层，让后端更加专一，前端能够染指服务端，连贯服务端和客户端，加强工程化能力。
2：确定 SSR 技术计划 node-vue-ssr
得益于技术的提高，现有的 Node.js 服务端渲染有有很多的技术可选择性：nuxt、node-vue-ssr
通过团队已实际的 node-vue-ssr 和已有的 vue 技术栈，最终选用了 node-vue-ssr。
node-vue-ssr 的实现流程：具体请参考文档 https://ssr.vuejs.org/zh/
五、新的挑战：Node.js 和 SSR 的退出，同构逻辑繁杂
1、状态中须要退出 SSR 和 CSR 的状态判断
2、在数据对立解决上，Nuxt.js(vue-ssr 的一个框架) 会通过 asyncData（一个服务端和客户端都会在每个页面渲染前运行的配置函数）来放弃 nodejs 和客户端的数据统一，这种形式有很大的弊病
效率低：每开发一个页面，都要进行书写申请逻辑（串行数据和并行数据）、网络异样解决逻辑（网络申请失败、后端异样状态码、未登录去申请登录的数据）
扩展性差：对于后续扩大跨平台流动页实现难度大（效率太低、代码耦合在一个函数外面，很难进行 lowcode 的降级）
为了解决这些问题，对问题进行了拆解，并将数据的获取解决，分层（客户端和服务端代码拆散）多步执行，以达到高扩展性，高效开发，保护简略，疾速锁定问题等长处
六、正当分层：拆解不同端的复杂度，一次开发多端失效，进步开发效率
七、配置化开发：每一层开发单元如何工作传递给下一层
1：node 层：数据抓取和 SSR 渲染
node 层获取用户拜访的路由、依据路由信息前置获取数据配置层的数据，同时获取公共数据（用户信息）交给状态解决层。
2：前端工程化：客户端和服务端的桥梁
通过工程化解决一套代码开发，多端运行。代码能够在服务器运行生成 html 节点，代码在浏览器运行 js 进行交互生成 html。
3：数据配置层，保护数据统一
依据数据配置层的配置信息，会从 Node.js 端和客户端获取同一份数据，这样能够保障在拜访同一个路由，不论是客户端构建还是服务端构建，数据是雷同的，构建渲染后果也是一样的。
配置信息：
export default {
// 题目
"title": "服务市场",
"name": "home",
// 路由匹配
"path": "/",
// 是否须要 ssr 构建
"ssr": true,
// 申请参数
"ajax": [
// 并行接口
{
"path": "/home/info",
// 串行接口
"children": [{
"path": "/home/getProductConf",
"params": {
// 依赖父接口的参数
"name": 'parent.data[0].data.name'
}
}]
},
// 并行接口
{"path": "/home/getProductConf"}
]
}
由工程层的配置，咱们强化配置文件，使我的项目的所有页面反对三种灵便配置：
1、对于客户端体验要求比拟高的，并且有 seo 需要的，采纳 SSR 构建
2、对于用户体验要求绝对个别的、采纳数据端预取形式
3、对于动态页面采纳客户端 js 展现即可
4：状态解决层：对于获取的数据进行筛选
一个我的项目的页面有很多状态，例如用户核心须要登录，如果未登录，要显示未登录界面。如果数据获取失败，要显示获取失败界面。
这样的状态，在以往我的项目中有很多的冗余代码。
状态解决层依据页面的配置进行解决数据，状态解决层交付给页面层的，只有胜利的数据。同时如果不胜利（未登录、获取数据失败等）展现对应的状态。
5：页面层：渲染
得益于正当的分层和逻辑的拆解，整个页面层仅用于交互和页面数据渲染。
八、其余：
灵便配置：同时反对服务端渲染、数据直出渲染、以及客户端 CSR 渲染三种渲染形式。
灾备计划：在服务端渲染呈现 bug 的状况下，可灵便转换为客户端渲染。
日志采集：对每个申请进行采集，记录以后的 cup、内存能性能参数，在产生问题后及时报警
问题锁定：对于每个申请每个渲染，从后端到前端生成惟一的 logid，对产生问题的申请进行疾速的问题锁定
九、结语：
劣势：
前端进行 SSR 渲染赋予了咱们我的项目生机、更加灵便的配置，更好的用户体验，更弱小的性能，更好的迭代，更高的安全性和容错率。
毛病：
Node.js 层的引入，造成成本增加
比照：在 rd 机器动态产出和革新后在 Node 机器上通过 SSR 构建的各项指标比照
（1）加载总时长时长
图 1：渐进式 CSR 加载总时长 1.7s
图 2：SSR 加载总时长 1.2s 晋升 30%
（2）其余指标比照
图 1：渐进式 CSR 渲染 首次绘制 243ms 后，首次内容绘制 943ms，完结绘制 1243ms
图 2：SSR 渲染 首次容绘制和内容绘制 427ms，完结绘制 1027ms
FP (First Paint) 首次绘制
FCP (First Contentful Paint) 首次内容绘制
LCP (Largest Contentful Paint) 最大内容渲染
DCL (DomContentloaded): 解析结束
将来和瞻望：
通过性能比照，整体收益远不止眼前的这些，将来咱们冀望大抵以爱洽购为外围的交易生态，持续推广配置化落地，以数据来形容各个页面，以 Node.js 为根底渲染服务驱动各个页面以实现前端微服务和跨平台的流动页定制。
举荐浏览：
百度 APP 视频播放中的解码优化
百度爱番番实时 CDP 建设实际
当技术重构遇上 DDD，如何实现业务、技术双赢？
接口文档主动更改？百度程序员开发效率 MAX 的秘诀
技术揭秘！百度搜寻中台低代码的摸索与实际
百度智能云实战——动态文件 CDN 减速
化繁为简 – 百度智能小程序主数据架构实战总结
———- END ———-
百度 Geek 说
百度官网技术公众号上线啦！
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边
