SSR 与当年的 JSP、PHP 有什么区别？-低调大师

SSR 与当年的 JSP、PHP 有什么区别？

2020-10-28 592

关注「前端向后」微信公众号，你将收获一系列「用 💖 原创」的高质量技术文章，主题包括但不限于前端、Node.js以及服务端技术

写在前面

SSR（Server-Side Rendering）并不是什么新奇的概念，前后端分层之前很长的一段时间里都是以服务端渲染为主（JSP、PHP），在服务端生成完整的 HTML 页面

（摘自《前端渲染模式的探索》）

也就是说，历经 SSR 到 CSR 的大变革之后，如今又从 CSR 出发去探索 SSR 的可能性……似乎兜兜转转又回到了起点，在这之间发生了什么？如今的 SSR 与当年的 JSP、PHP 又有什么区别？

一.SSR 大行其道

回到论坛、博客、聊天室仍旧火热的年代，行业最佳实践是基于 JSP、PHP、ASP/ASP.NET 的动态网站

以 PHP 为例：

<?php if ( count( $_POST ) ): ?>
<?php include WTG_INCPATH . '/wechat_item_template.php' ?>
<div style="...">

  <div id="wechat-post" class="wechat-post" style="...">
    <div class="item" id="item-list">
    <?php
        $order = 1;
        foreach ( $_POST['posts'] as $wechat_item_id ) {
        echo generate_item_list( $wechat_item_id, $order );
            $order++;
        }
    ?>
    </div>
    <?php
    $order = 1;
    foreach ( $_POST['posts'] as $wechat_item_id ) {
    echo generate_item_html( $wechat_item_id, $order );
    $order++;
    }
    ?>
    <fieldset style="...">
      <section style="...">
        <p style="...">如果心中仍有疑问，请查看原文并留下评论噢。（<span style="font-size:0.8em; font-weight:600">特别要紧的问题，可以直接微信联系 ayqywx</span> ）</p>
      </section>
    </fieldset>
</div>
<script>
    function refineStyle () {
        var post = document.getElementById('wechat-post');
        // ul ol li
        var uls = post.getElementsByTagName('ul');
        for (var i = uls.length - 1; i >= 0; i--) {
            uls[i].style.cssText = 'padding: 0; margin-left: 1.8em; margin-bottom: 1em; margin-top: -1em; list-style-type: disc;';
            uls[i].removeAttribute('class');
        };
    }

    document.addEventListener('DOMContentLoaded', function() {
        refineStyle();
    });
  </script>
</div>

<?php endif ?>

（摘自ayqy/wechat_subscribers，一款用来自动生成微信公众平台图文消息的 WordPress 插件）

这一时期网页内容完全由服务端渲染，客户端（浏览器）接收到的是融合了服务数据的 HTML，以及少量内联的（表单）交互逻辑和样式规则，支撑着早期大量动态网站的正是这种纯 SSR 模式

但随着技术实践的深入，这种模式逐渐暴露出了一些问题：

性能差：每一个请求过来都要重新执行一遍数据逻辑和视图逻辑，动态生成 HTML，即便其中很大一部分内容是相同的
机器成本高：Tomcat/Apache 等应用服务器的并发处理能力远不及nginx之类的 Web 服务器，因此需要部署更多的机器
开发/维护难：前后端代码掺杂在一起，人员协作是个问题，并且修改维护要十分谨慎（标签结构容易被破坏）

面对这些问题，两个思路逐渐变得清晰起来，动静分离与前后端分层，前者解决性能和机器成本的问题，后者解决开发/维护的问题

二.动静分离

为了充分利用 Web 服务器的静态资源处理优势，同时减轻应用服务器的负担，将资源分为两类：

静态资源：图片、CSS、JS 等公用的，与具体用户无关的资源
动态资源：应用逻辑、数据操作等与具体用户密切相关的资源

两种资源分开部署，把静态资源部署至 Web 服务器或 CDN，应用服务器只部署动态资源。如此这般，静态资源响应更快了（浏览器缓存、CDN 加速），应用服务器压力更小了，皆大欢喜

然而，视图逻辑却被我们漏掉了，HTML 算作静态资源还是动态资源？

前后端分层就是为了回答这个问题

三.前后端分层

视图逻辑的特殊之处在于：

与数据密切相关
服务端与客户端均可承载视图逻辑

也就是说，HTML 视图结构的创建和维护工作，可以由服务端完成，也可以在客户端完成，都依赖服务数据。但与服务端相比，客户端环境有一些优势：

无需刷新（重新请求页面）即可更新视图
免费的计算资源

因此，视图逻辑划分到了客户端（即 CSR），以数据接口为界，分成前后端两层：

后端：提供数据及数据操作支持
前端：负责数据的呈现和交互功能

自此，前后端各司其职，前端致力于用户体验的提升，后端专注业务领域，并行迭代，（不涉及接口变化时）互不影响

四.CSR 如日中天

前后端分层之后，进入了 CSR 的黄金时代，探索出了功能插件、UI 库、框架、组件等多种代码复用方案，最终形成了繁荣的组件生态

组件化的开发方式之下，纯 CSR 模式日益盛行：

<!DOCTYPE html>
<html>
<head>
    <title>My Awesome Web App</title>
    <meta charset="utf-8">
</head>
<body>
    <div id="app"></div>
    <script src="bundle.js"></script>
</body>
</html>

这种模式下，几乎所有的页面内容都由客户端动态渲染而来，包括创建视图、请求数据、融合数据与模版、交互功能在内的所有工作，都交由一套数据驱动的组件渲染机制来全权管理，而不必再关注组件之下的 DOM 结构维护等工作，有效提高了前端的生产效率。但一些问题也随之而来：

在组件树首次渲染完之前，页面上无法展示任何内容，包括 loading
数据请求必须等到所属组件开始渲染才能发出去

这些问题的根源在于目前的组件渲染流程是同步阻塞的，对首屏性能提出了挑战：

低端设备上 JS 执行效率低，白屏时间长
弱网环境下数据返回慢，loading 时间长

CSR 虽然利用了用户设备的计算资源，但同时也受其性能、网络环境等不可控因素的制约。于是，大家又重新将目光聚集到了 SSR

五.SSR 东山再起

SSR 模式下，首屏内容在服务端生成，客户端收到响应 HTML 后能够直接呈现内容，而无需等到组件树渲染完毕

虽然核心思想都是在服务端完成页面渲染工作，但如今的 SSR 与先前大不相同，体现在：

出发点：为了更快、更稳定地呈现出首屏内容
成熟度：建立在前端成熟的组件体系、模块生态之上，基于 Node.js 的同构方案成为最佳实践
独立性：仍然保持着前后端分层，不与业务领域的应用服务强耦合

也就是说，如今的 SSR 是为了解决前端层的问题，结合 CSR 优化内容加载体验，是在 CSR 多年积淀之上的扩展，与现有的前端技术生态保持着良好的相容性。而当年的 SSR 更多地是为了实现功能，解决温饱问题

再看当年 SSR 面临的几个问题：

性能差：每一个请求过来都要重新执行一遍数据逻辑和视图逻辑，动态生成 HTML，即便其中很大一部分内容是相同的
机器成本高：Tomcat/Apache 等应用服务器的并发处理能力远不及nginx之类的 Web 服务器，因此需要部署更多的机器
开发/维护难：前后端代码掺杂在一起，人员协作是个问题，并且修改维护要十分谨慎（标签结构容易被破坏）

引入 SSR 之后这些问题卷土重来，但这些年的技术发展为解决这些问题提供了新的思路：

实时渲染的性能问题：动静分离的思路仍然适用，例如Static Generation
服务器资源成本问题：云计算的发展有望大幅降低机器成本，例如Node FaaS
SSR 部分与 CSR 部分的开发/维护问题：同构为解决开发/维护难题提供了一种新思路（之前的思路是前后端分层，但这一次分不开了），维护同一份代码，跑在不同的运行环境输出不同形式的目标产物

其中，Static Generation（也叫 SSG，Static Site Generation）是指在编译时生成静态 HTML（可部署至 CDN），避免实时渲染的性能开销：

Static Generation (Recommended): The HTML is generated at build time and will be reused on each request.

但并非所有页面都能在编译时静态生成，一种可行的实践方案是将 SSR 与 Static Generation 结合起来，只对内容依赖个性化数据、或者频繁更新的页面走 SSR，其余场景都走 Static Generation：

You should ask yourself: “Can I pre-render this page ahead of a user’s request?” If the answer is yes, then you should choose Static Generation.

至此，沉寂多年的 SSR 又焕发出了新的活力

参考资料

What is the point of SSR these days?
Two forms of Pre-rendering

联系我

如果心中仍有疑问，请查看原文并留下评论噢。（特别要紧的问题，可以直接微信联系 ayqywx ）

本文分享自微信公众号 - 前端向后（backward-fe）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。

微信关注我们

原文链接：https://my.oschina.net/u/4581386/blog/4692947

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

技术选型：为什么批处理我们却选择了Flink

最近接手了一个改造多平台日志服务的需求，经过梳理，我认为之前服务在设计上存在缺陷。经过一段时间的技术方案调研，最终我们决定选择使用 Flink 重构该服务。目前重构后的服务已成功经受了国庆节流量洪峰的考验，今日特来总结回顾，和大家分享一下经验。业务需求及背景在了解改造服务的需求前，我们首先要明确，要解决什么问题以及目前的服务是如何解决的。当前的业务逻辑还是比较清晰的：采集同一时段不同数据源的日志；对采集的数据进行处理；将处理后的数据上传到指定位置，供客户下载。我们面临的痛点和难点：日志的数据量比较大：每小时未压缩的日志数据量有 50 多个 G，节假日等特殊时间节点，日志量会翻倍。目前服务使用单机进行处理，速度比较慢，扩容不方便。目前服务处理数据时需要清洗字段，按时间排序，统计某字段的频率等步骤。这些步骤都属于 ETL 中的常规操作，但是目前是以代码的形式实现的，我们想以配置形式减少重复编码，尽量更加简单、通用。方案1：我们需要一个数据库吗? 针对以上业务需求，有同学提出：“我们可以把所有原始数据放到数据库中，后续的 ETL 可以通过 SQL 实现。” 如果你一听...

2020-10-28

444

在前不久的上海外滩大会上，蚂蚁集团高级体验设计专家林外分享了Ant Design4.0背后的设计理念，我们将内容整理出来与大家分享。今天，我和大家分享的话题叫做，创造快乐工作。 Ant Design的基本假定在我开始所有话题之前，我有问题想问大家，大家工作快乐吗？我听到了特别积极的反应，说非常的快乐。但是呢，其实，工作并没有我们想象中那么快乐，是所有的活动当中快乐指数最低的，跟躺着带来的快乐差不多的，有些人躺着什么也不干，也比工作快乐。什么原因导致了工作的不快乐？大部分人认为工作是为老板服务，所以很难受。另一类人是因为反馈，很多工作的结果依靠于外界，依靠于老板，所以你跟直属上司的关系，决定了工作的体验。第三类是我们认为挑战和技能的不匹配，导致了我们工作的不快乐。当挑战大于技能的时候，你就会焦虑，当技能大于挑战的时候，你就会觉得无聊，你的工作就会在焦虑和无聊之间来回地徘徊，这是我们理解的世界。这个问题，在数字世界中会变得更加的明显。70 年前，第一台计算机出来之后能解决的问题非常的简单，但是 70 几年过去了，数字世界得到了非常大的发展，我身边任何一个小设备都远远大于 70...

2020-10-28

444

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。