(1) 起點是用戶的請求，通常從瀏覽器發出。

(2) 請求應該命中緩存層（例如 CDN），該層可能包含已經在服務器端渲染的應用程序，在這種情況下響應非常快。

CDN 通常將服務器端渲染存儲一段時間，具體取決于業務需求。在給定時間之后，緩存失效。為了以最佳方式執行此失效，建議 CDN 在緩存被驅逐之前請求新的服務器端渲染，并在執行新渲染時繼續提供現有緩存。

(3) 如果 CDN 沒有緩存 SSR 渲染，它會將請求進一步轉發到反向代理（例如負載均衡器）。

(4) 反向代理（通常是負載均衡器）將決定將請求轉發到哪個 SSR 節點（在節點集群中）。

(5) SSR 節點接收到請求并開始渲染。它向 OCC API 發出 OCC 調用。

不建議將 SSR 服務器/節點直接暴露給用戶，因為渲染速度很慢并且無法滿足預期的響應時間。

(6) OCC API緩存層負責緩存來自OCC API服務器的OCC API響應。通常，這意味著緩存 GET 和 HEAD 請求的響應。如果 OCC API 緩存層緩存了響應，則立即將其返回給 SSR 節點，而無需將請求到達實際的 OCC API 服務器，從而使 SSR 節點執行渲染的速度非?？臁?/p>

建議為 OCC API 服務器設置某種緩存層，因為這部分在服務器端渲染時花費的時間最多。

(7) 如果OCC API緩存層不包含給定請求的緩存響應，則將其轉發給OCC服務器進行處理。

使用這些推薦的設置，您的 SSR 節點將不會直接暴露于用戶負載，因此理論上不太可能崩潰。

除此之外，另一個建議可能是檢查您的自定義開發代碼中是否存在任何內存泄漏（這也可能導致您的 SSR 節點崩潰）。

總結

以上是生活随笔為你收集整理的SAP 电商云 UI 服务器端渲染的建议架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。