有人喝生肖酒吗？
06-18
1.简介 Serverless 最近再次流行起来。许多企业已经在云端实施了Serverless云功能，并取得了良好的实施效果。
业界也在不断探索Serverless。更多 大量着陆场景。
那么无服务器对于前端意味着什么呢？对于Node服务，我们在哪里可以实现Serverless？答案：Serverless同构直出渲染Serverless+SSR=？ Serverless云功能：云计算发展过程中出现的计算资源的抽象。它基于云计算平台，为开发者提供业务程序和开发的运行环境，用户无需关注底层资源分配和扩展部署。
代码执行所需的所有服务均由平台提供。 SSR服务器端渲染：指将服务器端的HTML渲染到前端。
早期普遍采用php jsp技术在服务器端生成HTML。近年来，随着JS同构趋势的演变，前端JS代码运行在服务器端进行渲染的方式逐渐出现。
解决方案，例如React、Vue等主流框架的同构渲染。如果能够在SSR场景中实现Serverless技术，将会有以下优势：云服务资源理论上可以无限扩展，前端不需要考虑业务量对SSR机器性能的影响。
前端同学无需关注SSR机器的运维、应用、扩展，降低了Deploy运维成本，提高了开发效率。目前，腾讯NOW Live IVWEB团队正在逐步将SSR业务迁移至腾讯云云功能平台，以精简部署和运维成本。
2. Serverless 的演进 Ah J 是一名前端开发人员。有一天，产品告诉他页面白屏加载界面时间太长，体验很差。
这对于他作为一名优秀的前端开发人员来说并不困难。他有99种如何让页面加载更快的方法，所以他立即使用团队的direct-out框架，花了半天时间将页面连接到direct-out。
接下来，他要把直出业务部署到现网。这时，他遇到了一个困难：部署直出要提供服务，我需要申请一台机器。
我应该申请多少台机器，申请多少个核心？业务量如何？有没有高并发的场景？机器有扩展机制吗？如何更改Nginx配置才能访问直接传出页面？如果直接传出页面失败，如何访问隐藏的静态页面？正当他困惑的时候，他看到了腾讯云同事maxlong关于Serverless架构演进的PPT……从IaaS到FaaS。在介绍SCF云功能之前，我们先来区分一下传统的IaaS业务架构和云功能FaaS业务架构： 基于虚拟化的基于机器的业务架构（IaaS）和云功能架构是这样的： 基于云功能的业务架构（FaaS） ）。
AJ对比两种架构后发现，在基于云功能的业务架构下，开发者不再需要关注业务基础。该层的相关配置可以专注于业务逻辑的开发。
平台负责基础层的维护和迭代。只要我们的直出业务部署在云端，就可以解决部署直出业务的运维痛点。
FaaS+BaaS下ServerlessFaaS的出现，让服务更容易迁移到云端，但FaaS并没有解决“公共基础服务”的问题。所谓公共基础服务就是对象存储、KV存储、消息推送等基础服务。
服务，这个问题最终落到云服务商身上。因此，市面上所有的云服务都无一例外地提供上述“公共基础服务”。
这种服务模型称为BaaS（后端即服务）。 Serverless字面意思就是无服务器。
这并不是说不需要服务器，而是开发者不需要关注服务器。该部分由平台维护提供，开发者只需关注业务逻辑的开发即可。
Serverless架构下的应用程序。在这样的架构下，开发者无需关注支持应用服务运行的底层资源。
业务逻辑以“功能”的形式承载，公共服务以“BaaS服务”的形式支撑。公有云基础设施的Serverless演进考虑到直出服务的特点，阿J认为直出服务非常适合Serverless，因此他立即开始了直出云服务的预研，并构建了Serveless SSR服务，无需运维部署。
不用担心，降低直达成本！ 3、SCF云函数开发阿J仔细研究了腾讯云的Serverless Cloud Function（SCF），发现Cloud Function可以把我们的业务拆分成更细粒度的“函数”，而函数的执行环境却不允许开发者需要注意并由平台负责。以下是阿J对云函数执行的理解。
云功能执行流程云平台执行这些“云功能”的过程实际上就是在对外提供服务。通常，Serverless 函数用于“响应 HTTP 请求”，即通过 HTTP 访问事件来触发云函数的执行，如下图： 云函数用户请求链接并“执行” “函数”无非就是四个要素：输入参数、上下文、返回值、副作用。
如图：函数执行的四要素。四要素：“输入参数”：云函数的输入参数是HTTP请求中的请求头和请求体。
“上下文”：包括函数请求的id、函数执行的环境变量等。 “副作用”：云函数执行可能会调用外部服务，如数据库、对象存储、数据监控等。
“返回值”：即HTTP响应如{retcode:0,msg:"ok"} 阿J还了解到，按照一定的配置部署云功能后，云平台会给你一个URL，可以通过这个URL来“触发” " 执行相应的云函数并得到结果。4、NGW Serverless同构直出解决方案 当阿J开始开发Serverless直出时，突然发现Serverless环境和原来的直出环境有很大不同。
原来的直出环境如下： 原来的方案是使用TSW来执行Koa App。这意味着原来的解决方案需要监视端口而不是作为函数运行。
这该如何处理呢？老业务能否无缝迁移至云功能？新的直出方案能否兼容旧的直出方案？云功能如何以工程化的方式打包发布并融入到团队现有的CI流程中？原方案可以用于本地调试，但是如何使用云函数进行本地调试呢？云功能发布后，会获得一个URL。那么这个URL如何连接到我们的企业域名呢？除了前端webpack打包进行工程打包之外，对于Serverless云功能平台来说，我们还要在原有打包产品的基础上多做一些操作。
其核心是“打包成zip并上传到云函数”，如下图所示： 云函数打包图 从图中可以看到，打包和部署过程是由“CLI工具”按顺序进行的提供命令式部署原语以方便 CI 访问。 Serverless AJ下的同构环境考虑到原来的业务直出方案使用的是TSW，但是在Serverless下，我们不能将TSW移到云函数中执行，而是提取出我们需要的组件，比如ajax发送请求、监控等常用组件报表、记录器等，因为：方便老业务无缝迁移到云功能直导出，解决直导出业务的运维痛点。
TSW非常大，压缩后接近20MB，解压后则大得多。除了有利于云函数的性能之外，还需要实现类似于 TSW 全局注入的 window.REQUEST 插件对象，因为旧的解决方案也依赖于这些全局对象。
原来的“流式”和“块式”的解决方案需要Koa监听本地端口来提供服务，而云函数的输入输出参数是块类型，而Koa的输入输出参数是流类型，所以这里我们需要处理云函数的输入和输出参数。参。
阿J的做法是根据云函数入参动态构造http的IncomingMessage和ServerResponse实例，然后透传给app.callback()直接渲染，最后从ServerResponse中获取渲染结果构造为云函数返回价值观。NGW作为网关转发。
考虑到业务的可用性以及之前链路访问的痛苦，我们决定连接NGW（Node Gateway）：通过NGW可以实现NGW下的Serverless直出链路：实现自下而上的逻辑：云功能有可能会崩溃，然后使用静态页面访问机的灰度逻辑：在直接上线的过程中，可以通过NGW配置进行一些灰度测试。链接日志收集：长期以来，在前端查看具体链接都比较困难。
信息，现在有了NGW，一切皆有可能。云函数本地调试。
云函数的无状态模型使得本地调试变得非常容易。我们只需要输入本地构造函数的参数和上下文就可以直接调试。
阿J 实际实现中，本地设置一个Koa服务监听端口，通过这个端口的请求来构造输入参数和上下文，最后将函数执行结果传入并返回给前端显示。在同构直出流程的最后，阿J完成了Serverless直出方案。
直出流程如下图所示： 新方案下的同构直出三步“Init”：初始化云函数环境，接受并处理云函数 输入参数“Koa”：React同构业务逻辑体现在Koa App“Clear”的形式上：清理云函数环境，处理Koa Response并返回直接结果。需要特别提到的一点是，Koa 实际上是原始解决方案的封装。
于是，新方案在此基础上做了一些环境迁移和重写，使其能够在云函数环境中进行渲染。性能瓶颈与云功能优化 Ah J 在完成新的直传方案后立即进行了压测，发现随着压测压力的增大，收包率会出现断崖式下降，同时他还发现一些执行函数花了很长时间。
我联系了云功能的同事，发现这是一个“冷启动问题”。那么什么是冷启动呢？从云函数的架构可以看出，云函数被触发后并不会立即执行。
它需要一个环境初始化过程。这种启动方式称为冷启动。
另一种情况，本次请求的函数执行后立即被接收。对于下一次请求，此时不需要重新初始化云功能环境，而是直接启动。
这称为热启动。收包率优化前后压测云函数执行时间分布图（右侧为优化后）。
冷启动问题在压力较低时并不明显，但在高并发情况下会额外影响报文返回。以下是 SCF Optimized 的同事：增加最小实例数并减少冷启动。
最小实例越多，处理瞬时并发的能力就越好。优化效果如上图右侧所示。
另外，我们还发现了内存问题。我们联系了SCF的同事来优化Node内存模型。
优化后，4xx问题基本消失。（业务中的内存使用也可以进行优化，避免JS内存泄漏。
）内存超限导致4xx问题。压测压力越大，此类错误发生的次数就越多。
至此，阿J在优化了内存模型的性能后，终于完成了Serverless。直接设计和开发解决方案，并开始在业务中逐步使用和推广。
现状及下一步 NGW+Serverless SSR已应用于NOW直播、手Q附近、浏览器直播、手Q群送礼等多个项目。在实际业务开发中，减少了Node业务的部署和运维工作量。
超过80%。阿J下一步计划：完善云功能版本管理；配合webpack进一步优化本地直出调试体验；与腾讯云同事合作，进一步优化云功能性能；完善React Chunked流式渲染方案，进一步提升首屏加载速度；完善Node服务云功能，规划为前端BFF解决方案；完善直发和链路日志采集，增强业务监控能力。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-18
06-21
06-18
06-18
06-18
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用