前言
因访问速度慢被吐槽前端性能差。
前端说： 明明就是接口慢 关前端啥关系
后端说： 单个接口的qps 都在200以上为什么到前端这边就不行了
实际情况（每个pod 2核4G）
| POD 个数 | QPS |
|---|---|
| 13 | 55 |
原因分析
- SSR: 页面需要保证需要seo 的数据都返回才能填充数据生成静态HTML字符串
- 接口分层: 那些并行 那些串行 保证服务端尽量暂用最少时间
- 实际测试，单个pod 只能在 12以下徘徊
猜测
1. Node 对JSON 的处理慢接口执行效率不行
2. Node 操作大量字符串性能不好
SSR 实验：相同html 字符串不同框架在服务端执行效率(不调用接口直接修改一个随机数)
| 方案 | QPS | 结论 |
|---|---|---|
| 纯Node | 200 | 由于没有引入任何第三方框架，代码路径最短，减少了中间层的开销，因此在性能上表现最佳。这符合预期，因为原生Node.js可以提供最高的运行效率，但开发复杂度相对较高 |
| KOA | 150~170 | Koa是一个轻量级、高度可定制化的Node.js Web框架，其设计哲学是简洁、灵活和高效。相较于纯Node.js，虽然引入了一些额外的抽象和中间件机制，但整体开销仍然较小，故性能接近原生Node.js，略逊于纯Node但优于其他两个框架。 |
| Express | 120~140 | Express是Node.js生态中最流行、功能丰富的Web框架之一，提供了大量的中间件和便利工具。然而，这种丰富性与便捷性是以牺牲部分性能为代价的。相比Koa，Express的API层级更深，可能包含更多内部逻辑和间接调用，导致其处理相同任务的效率低于Koa |
| Nextjs | 100 | Next.js是专为React应用设计的静态站点生成器和服务器端渲染框架，内置了很多高级特性如自动代码分割、路由管理、优化等。它的目标是简化全栈React应用的开发流程，而非极致性能优化。因此，在这个简单的SSR任务中，Next.js需要加载更多依赖、执行更复杂的生命周期方法，性能最低是可以理解的 |
分析： 代码路径越少执行效率越高，既然node 已经极致不能再提升有没有其他方案能解决这些问题
思考
- 为什么老早的 JSP PHP 携带的html 没有说性能问题
- 市面上为什么那么多 自定义 模板库
语言优势加上模板生成Html 快于Node 生成Html
| 语言 | 优势 |
|---|---|
| Node | 开发方便，性能差 |
| JAVA | 框架成熟， 比不上Go 的性能 |
| Go | 没有对应的框架，性能接近C++,天然支持高并发，多平台支持 |
使用Go 来生成 Html
graph TD
Vue --> SSR-Node -->
DSL--> GO模版HTML+TYPE --> SSR-GO --> SSR-Node
保证GO 生成的Html 和 Node 生成的Html 一致
关键技术
- 代码注入（AST 转换 注入自定义渲染方法） 复写这些使用的方法
import { Fragment, createVNode, mergeProps, renderList, toDisplayString } from "vue";
import { ssrInterpolate, ssrRenderAttrs, ssrRenderClass, ssrRenderComponent, ssrRenderList, ssrRenderStyle } from "vue/server-renderer";
2.Proxy 数据（数据依赖关系判断那些是动态的那些是静态的 对于生成 Html 中的模版）
上图看效果 (1 个Pod 的情况)
原文链接：https://juejin.cn/post/7359076801279541300 作者：123bb49
