在 Angular 应用程序中使用服务器端渲染,出于以下几种原因:
- SSR 有助于搜索引擎优化。 搜索引擎爬虫可以解析通过服务器端渲染的 HTML 页面源代码。而运行在 CSR 模式下的单页面应用,页面源代码是在客户端浏览器里执行复杂的 JavaScript 生成,现代很多爬虫对此内容无能为力。
- Facebook 和 Twitter 等社交媒体平台,可在共享时显示 SSR 渲染出的网站的预览。
- 在服务器上呈现网页后,页面内容可以被缓存,从而能够更快的响应用户相同的页面请求。
要在 Angular 应用程序中实现服务器端渲染,可以使用 Angular Universal package.
当我们使用 Angular Universal 时,向 OCC 服务器发起业务数据请求的 API 触发两次。首先是在服务器渲染页面时实行一次,第二次是在客户端应用程序启动时触发。这种 API 重复触发的方式会导致延迟问题和糟糕的用户体验,因为发生这种情况时屏幕通常会闪烁(flickering
).
此外,SAP CCV2 上的 SSR 容器是运行 Node.js 代码的地方,因此更容易受到性能下降的影响。在选择 Node.js 和 server.js jsapps-* 之后,可以从 Dynatrace 中的技术和进程页面查看 CPU 和内存。注意 SSR 应用文件的名称可能不同,默认为 main.js.
随后的页面将显示所选任何给定指标的平均利用率。 单击单个 pod 将进入其进程详细信息页面,其中可以查看有关 cpu/内存利用率和重新启动时间的信息。 对于 SSR,有关 CPU 的详细信息将在系统性能选项卡下,而有关 V8 内存使用的详细信息将在 Node.js 指标选项卡下。
当发现 SSR Pod 的 CPU 利用率居高不下时,基于 Node.js 的设计,尽管我们可以通过垂直扩展来缓解这个问题, 另一方面,如果并发请求的数量很大,那么也可以考虑通过水平扩展的方式来降低每个 Pod 的 CPU 利用率。
尽可能多地消除 Spartacus Storefront 中 CPU 密集型代码 ,必要时可以研究是否能够将逻辑转移到 OCC 层执行。