简介:揭示SSR技术在直播RD部Web应用中的新玩法，在CSR目录中增加一个JS计算功能，使页面具有SSR能力。依托端云协同驱动，打通SSR技术关键路径，大规模引领优质Web应用市场价值。让我们来探索这个每小时授权方案。
从南车到SSG，网页信息完全是从零开始出现的。个性化内容滞后于AJAX请求，驯服了访问体验，提升了网页内容量和平台品牌水平，满足了消费者对更高品质体验的需求。同时，内容服务网站的SEO推广也是关键因素，内容运营帮助业务实现突破性增长。回归到提高服务竞争力的核心，SSR技术有着独特的潜力和创新机会，各种“非常规”方案也在活跃，共同的目标是让互联网Web应用高质量。
另一方面，SSR也是Web服务发展质变的分界点。除了SSR技术本身的提升，赋能成本的降低更依赖于大规模的实施。通过系统工程的改变，开发者可以方便的升级，让服务更贴近用户。第二，诉求是目标。同构SSR:顶层设计中不再接受基于模板的SSR技术，因为异构的TPL和JS增加了页面组件的维护和切换成本。基于业务和团队现状，需要快速迭代，一套代码可以100%复用。同时，JS集成和同构SSR可以最大限度地减少组件代码的入侵。
快速访问:页面开发人员希望在CSR项目下集成，对模块、项目和页面目录几乎不做任何更改。一方面，中国南车是大的商业载体；另一方面是前端很多零散模块的现状。移入一个集中式的庞大项目，然后拆分成可控的小块，再加上依赖管理，重建的成本会很高，甚至为了访问SSR而重写也会削弱工程ROI。
体验:页面开发人员更关注组件代码本身，CSR的开发部署，修改代码打包发布。我希望BFF服务编排和云基础设施将与NoOps一起有序运行。数据接口和字段重用是基本要求。
效果保证:用服务器的HTML结果渲染首屏，适当使用缓存策略，加快访问速度，缩短FMP时间，提高网页服务质量。SEO友好，有利于内容密集型网页的曝光。
第三，FaaS SSR是通用的
面对上述挑战，用第一性原理思考，回归同构SSR技术本质”是指在服务端拼接一个网页的HTML结构并返回内容丰富的文件，然后在浏览器端水化为其绑定状态和事件，成为完全交互的页面的过程。无论每个版本如何描述这个过程，在服务端生成内容丰富的HTML都被分解成最基本的组件:组件和数据。来源:组件已经可用，可以通过修改构建配置来导出和引入；也就是数据CSR进程通过AJAX调用的后端接口响应数据。其实也很清楚，但是服务器端需要服务器对服务器的调用。与CSR相比，SSR要求在组件第一次执行时预先传输数据。
在第一个构建原则上，我们可以基于PaaS拉出一致的FaaS SSR组装环境，具有服务预热、快速接入、灵活扩展、容器隔离、运维成本低等优势。关键优势在于互补Web应用的云开发辅助能力，在前端架构层面高效协同，使Web应用支持原生云联合渲染，从而打造通用同构方案。SSR核心库更小，更具内聚性和可维护性，松耦合和自治的模块具有更好的可扩展性，不会将每个模块页面局限于特定的技术栈，释放组织潜力。除了基本的DevOps，FaaS SSR环境只调度组件和数据，保证组件在节点服务器上运行的方法是组件本身导入的所用框架的原生API。页面资源:SSR流程的必要元素。模板:页面模板，即CSR页面的HTML，也是SSR页面的模板。
Bundle:按组件打包的Bundle。Node.js服务器上SSR的这个捆绑产品需要webpack单独打包。
FC:控制SSR进程的计算功能，实现SSR内核的钩子，运行在函数沙箱中，可以自定义SSR结果。
数据:通过调用后端服务获得填充组件的BaaS数据。
路由:路由页面请求和调度资源
Manifest.json:模块构建产生的资源列表。每个方向模块自动产生一个副本，说明上述页面资源的资源和其他信息。
模块:模块的信息，manifest.json路径，模块查询路径等信息。
Router: Lambda函数，解析当前请求信息，匹配当前页面的模板、Bundle和FC信息，发送HTTP事件给FC。
BaaS:后端即服务，包括接口、存储、通信等后端服务。通过规范描述，可以将它交给FaaS RPC来调用目标服务。
渲染:通过一系列Lambda函数管道调用，注入整个流程的环境变量，包括获取并转换BaaS数据接口的描述，通过RPC调用获取内容数据，合并组件和数据，回填APP HTML和模板等等，进行实际的SSR流程。
看:服务的日常运维与效率提升相关，包括一般监控、日志传输、离线计算、服务观察等等。
4.1部件响应
同构是组件的最小粒度。同构给了组件一个非常强大、高度可重用、灵活多样的运行环境。实际上，它是客户端、边缘服务和中心服务的集成。我们集合单一职责的组件内容显示和交互逻辑，让组件代码在端和云环境下至少执行两次，在服务器环境下执行一次，从而产生网页内容丰富的HTML结构，然后在浏览器环境下再次执行，以水化和接管页面的交互响应。组件可以根据不同阶段的全局环境标记做出更加垂直和细分的渲染响应，从而控制更加个性化的适配逻辑。通过大规模完全平滑FaaS沙盒底层，验证了大部分组件的访问成本为零。即使组件没有响应，也可以通过实现FC操作的HTML结构来响应请求结果。
4.2界面描述组件是页面的骨架，数据是页面的灵魂。FaaS SSR FC使用JSON Scheme语言描述的接口，浏览器的源请求由FaaS RPC中转处理引擎转换成相应的BaaS调用，链接上下游数据通信。具有缩短调用环节，加快结果响应的特点。该描述规范包括:URI地址、静态参数、动态参数、请求头、请求方法、权限检查控制、响应捕获机制、知识库等私有协议格式。
4.3建设和改造在构建阶段，目标是定义模块中不同资源的规则边界，迎合源代码资源，通过加载、编译和依赖分析，产生多层次的产品，发布到BFF应用进行大规模部署。同时可以通过工程自动化的手段复制工艺线。新产品包括:模块列表、页面捆绑和SSR计算功能。
4.4开发经验为了开发着陆场景，技术方案必须“本地化”，然后“生产”。只有建立流畅的本地开发体验，才有可能线下获取开发者和用户，开始合作共建。基于FaaS的SSR，页面开发人员即使没有服务器端DevOps和搭建经验，也可以通过搭建插件的方式引入FaaS SDK，无需耦合服务器端框架，进一步降低开发时间和成本，并且可以在本地实时看到SSR结果，让你的网页瞬间升级。
4.5风险控制“我们无法完全防止不兼容的组件代码、下游BaaS黑洞等。，但是我们可以避免出现问题时直接影响用户的访问。在这一思想的指导下，通过改变BFF软件架构，创建了“两存一降”的架构设计理念，能够容忍异常组件、异常下游baa和异常FaaS环境，从而提高BFF业务的整体稳定性和健壮性。双层缓存和降级策略；
1:缓存，即代理层缓存。当FaaS服务异常时，返回最成功的SSR缓存。2:缓存，即FaaS层缓存。实现不同模块不同页面共享共同的下游响应数据，在下游BaaS服务异常时返回最新成功的API缓存。
降级:即服务降级为CSR，当上面没有缓存时，回退到响应静态文件。
此外，由于“两存一降”作为底层，各模块各页面访问SSR能力的成本也大大降低，成本的降低提高了该技术方案应用于各种业务场景的可能性。从周级别到小时级别，随着访问效率的提升，容量、意愿、信心都在不断增加。FaaS FC可以随时发布，只由页面开发学员自己决定，只关注页面结果，真正为开发者提供无服务器的开发体验。
方案的实际效果是提高了系统的下限，限制了工程方法陷入无底线的混沌。方案设计既要控制边界又要预留外延，提高开发商“犯错”的水平。工程链辐射，各种恰到好处的侧侵，可以很容易的移植到更多的模块中。率先垂范，将布局切入前端工程新基因，共同拓展渐进式增量升级的能力，带来技术选择的灵活性。赋能新的商业模式，降低实验沉默的成本。
总之，Web应用的SSR升级已经成为普遍现象，新的范式也在不断被创造出来，这还远没有结束。展望基于欢迎新人，拥抱未来，这使得SSR节目高度多元化——自由、活力、多边智慧。
