运行在 CCV2 环境上的 Angular 服务器端渲染应用的性能瓶颈分析

本文分析笔者在项目中开启 Angular 应用的服务器端渲染模式后，遇到性能问题时的分析思路和最终的解决方案。

在 Angular 应用程序中使用服务器端渲染，出于以下几种原因：

1. SSR 有助于搜索引擎优化。 搜索引擎爬虫可以解析通过服务器端渲染的 HTML 页面源代码。而运行在 CSR 模式下的单页面应用，页面源代码是在客户端浏览器里执行复杂的 JavaScript 生成，现代很多爬虫对此内容无能为力。

2. Facebook 和 Twitter 等社交媒体平台，可以在共享时显示 SSR 渲染出的网站的预览。

3. 在服务器上呈现网页后，页面内容可以被缓存，从而能够更快的响应用户相同的页面请求。

要在 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 层执行。