共计 4323 个字符，预计需要花费 11 分钟才能阅读完成。
本文整顿自 ServerlessDay · China 大会 –《Serverless 利用实际及典型案例解析》的分享，讲师为腾讯云 Serverless 高级架构师卢萌凯、猎豹挪动前端总监董文枭、江娱互动技术经理董文强、新东方高级工程师李垦。
本文次要分为四局部：
- Serverless 的劣势和价值
- 基于 Serverless 构建 REST API
- Serverless 和服务端渲染的联合
- Serverless 构建音视频转码计划
Serverless 的劣势和价值
为什么咱们投入这么大工夫和精力来做 Serverless 呢？因为咱们深信云计算的将来趋势之一就是 Serverless。因为 Serverless 让云服务的利用变得更加简略、高效。比方用云主机部署利用的时候，不仅要搭建和保护环境，同时也要评估业务的资源用量，尤其是对于经营类的流动，如果一旦评估的不精确，要么会造成资源的微小节约，要么服务可能会被打爆，甚至停服下线。
而 Serverles 可能做到按需应用，让业务完满的弹性伸缩，对于运维同学来讲，几乎不能更爽。而且和预付费的实例不同，Serverless 是 pay as you go 的模式，只有当业务运行时才会占用资源，只有源被占用了才会计费，简略来讲，就是，我理论用多少就付多少钱。这种计费模式对于存在显著波峰波谷的服务，劣势相当显著。
另外，云计算的倒退，肯定是让用户更加专一于业务。而对于运维来讲，那些繁琐的且对业务倒退没有外围价值的资源保护工作，就能够 offload 给云厂商，这样就能更加专一业务层面的运维。这就是 Serverless 所带来的价值，他不仅把用户对云的应用老本降到了最低，也最大水平上的减速了利用的上线过程。
咱们也能够回顾下云计算呈现及倒退的这些年里，和自建 IDC 相比，用户就是越来越聚焦业务，资源的应用效率也越来越高，而 Serverless 在当下把这些劣势做到了极致。
咱们再来简略看下云函数是怎么形成 Serverless 架构，以及 Serverless 利用具体是怎么运行的。
开发者在理论应用时，能够借助 WEB IDE 或者本地 IDE 实现代码开发，而后通过在线或者插件、工具的形式把代码以及所用到的相干依赖，一起打包部署到云函数平台，在代码里，咱们能够像传统开发方式一样去调用后端的 BaaS，比方拜访数据库、对象存储、音讯队列、第三方服务接口等。计算逻辑和后端服务独特形成了所谓的 Serverless 利用架构。
而终端用户依据平台提供的申请形式，去触发部署在云函数平台上的业务代码，比方发送 http 申请等，平台会依据用户的申请量去拉起相应的计算资源去运行用户代码。平台会保障资源的可用性和弹性伸缩，因而用户只用关注和聚焦业务及其运行状况。
基于 Serverless 构建 REST API
接下来进入明天的正题，首先咱们来看下 REST API 这个场景。这里会用到 Serverless Framework 来辅助开发和部署。借助 Serverless Framework 的 SCF 组件，咱们能够把本地开发好的 REST API 利用疾速部署到云上，咱们只须要提前写好相应的 yaml。Serverless Framwork 会基于 yaml 里的配置信息，疾速创立云函数、API 网关等云资源。
接下来分享江娱互动 Serverless API 实际。将从上面三个方面分享
- 为什么要迁徙到云函数
- 迁徙后的价值
- 应用云函数后的一些心得
大略将近一年前，江娱互动策动设计了一个性能，某个服务端的行为会触发零碎告诉发送到聊天频道上。实践上这个设计也没问题，然而没有思考规模，我也不晓得上了这么一个性能。上线之后，聊天零碎忽然来了 20 倍的申请量冲击，申请开始大量排队。玩家发的一句话须要一分钟后才会送达。
因而紧急加服务器分流，扛过了这一波流动。预先复盘如何防止这种突发申请量顶峰，硬堆服务器数量必定不行，方向过后是思考这么几个：弹性伸缩、容器化、云函数。
最终抉择云函数是因为它人造适宜无状态 Http 服务的场景。
- 首先从部署便捷性上讲，只须要关注到代码层面就好了，容器、镜像、服务器的概念齐全不必理睬。
- 其次就是用多少花多少钱。后半夜没啥申请量的时候，就没有老本。
- 最初就是再多的申请量，只有资源下限容许，都能够承载得住，当然，仅限于云函数这一层。因而决定先试试云函数。
团队大略花了不到一个月工夫，理分明云函数的根本用法并把玩家拉取历史音讯的接口迁徙了过来，十分顺利，用起来也没有什么问题，于是决定整体迁徙。
这是一套十分棒的老本和性能兼顾的计划。自从迁徙之后，聊天服务的 API 局部，稳定性十分好，随着游戏用户越来越多，也无需思考承载量的问题，而总体老本始终能维持在比拟低的程度。偶然遇到极其的申请量顶峰时，也都能失常撑过去，不会引起雪崩的场面。
另外云函数和其余零碎的联合利用，也比拟不便，比方音讯队列和日志零碎。还有定时触发器，间接取代了以往找台服务器用 crontab 运行一些定时工作的办法。而咱们也在把一些其余的外围零碎用云函数的形式来做，尽量减少游戏服务端的复杂度。
从程序员的角度看。应用云函数能够让开发者更加专一于代码自身的优化，能够去从新思考需要的实质，重新整理本人的思路。比方循环里要做什么，查询数据库时是不是要优化一下 SQL，大型的数据明确不必时，是不是先手动把内存开释掉等等。这对于开发者技术水平的晋升，是有很大的益处的。而且带来的正反馈，就是老本上显著的缩小。
Serverless 和服务端渲染的联合
接下来再来看下 SSR 场景。最早的时候前端利用其实就是 SSR，由服务器端生成 Html 页面送到浏览器端，起初为了晋升工程化效率，在前端引入了组件和 MVVM 的开发模式，而后就有了 CSR，典型的如单页利用，通过在浏览器端加载 JS 和 CSS 来实现渲染。然而咱们也发现单页利用对 SEO 不够敌对，另外，单页利用的首屏加载工夫也会比拟久，尤其是网络越差的状况就越显著。
所以一些公司为了优化用户体验，或者优化 SEO，就又开始转向 SSR。然而对于前端同学来说，须要跑后端，我就得运维一个 node 服务器集群，这个是很头疼的一件事，还须要理解很多后端的常识，如负载平衡和高并发等。借助 Serverless 能够完满解放前端同学的累赘。
猎豹挪动前端团队在 2016 年的时候开始应用 React，2017 年就开始钻研并尝试 React Server Render，同期 Facebook 的网站曾经采纳 Isomorphic 技术实现，性能十分好。为了满足公司业务需要和技术传承，团队自研了猎豹的前端技术框架 Koot.js，目前已成为猎豹前端的次要技术计划。
Koot.js 是基于 React、Koa、Webpack 来架构的，其中用 Koa 搭建的 Node 作为开发服务和部署时候的 SSR 服务，页面渲染次要是用 React+Redux 实现的一套代码在浏览器环境和 Node 环境通用，利用 Webpack 可编程性动静生成配置并执行，打包出多场景（开发、测试和线上环境等）多端代码（前端、服务端）部署。
具体落地的时候，猎豹挪动团队将自研的 Koot.js 应用 Serverless Framework 进行了封装，做了一个 Serverless 组件，这样在其余业务场景须要用的时候就能够间接复用，能够节俭不少老本，防止了反复造轮子，升高了出错的概率。
SSR 我的项目落地的时候通常不是很顺畅，我的项目部署的时候须要具备服务器技术能力能力和运维顺畅沟通，所以我的项目落地不仅要前端同学把握后端开发能力还要对运维技术、并发等问题多方面思考，这对前端技术同学的技术全面行有较高要求。
在这种状况下，去年咱们开始接触 Serverless 技术，Serverless 技术能够升高前端对服务端和运维的技术能力但要求，更适宜大部分要做 SSR 的前端团队。团队调研了几大云厂商 Serverless 服务，综合比拟后，抉择了腾讯云作为实现 SSR 的 Serverless 服务反对。
腾讯云 Serverless 提供了比拟全面的组件反对，与 Serverless Framework 根本是无缝联合，周边社区和生态反对也比拟到位，应用过程会少踩一些坑。在选定了平台之后就比拟顺畅了，因为 Serverless Framework 提供了很多标准化的接口，在封装 Koot.js Serveless 组件的过程中也比拟省心。
Serverless 构建音视频转码计划
最初是音视频转码场景，云函数和对象存储 COS 的联合，能够很不便的把上传到 COS 的音视频，进行自动化的转码解决。云函数里能够基于 ffmpeg 实现自定义的转码逻辑，并且对于转码后回传 COS 的文件，还能够主动触发 CDN 预热。
凭借云函数 (SCF) 的弱小联动能力，将视频上传、视频解决、图片解决、存储场景有机地整合为一体。用户能够自定义转码函数，帮忙客户疾速搭建定制化工作解决能力，补救以后独自云服务的性能盲点。能够把 ffmpeg 业务不便地从物理机、云主机或容器中移植到云函数。云函数提供丰盛的计量形式，帮忙用户取得显著的老本劣势。
在每年暑期的时候，都会有大量的学生在新东方的平台学习。以前咱们都是在自建的机房里基于服务器和 NFS 来实现音视频课程的存储和转码逻辑。然而因为暑期流量比拟大，IDC 里的服务器不肯定能满足计算需要，同时自建服务的硬件洽购周期较长，这里冀望寻找一种弹性的办法，既可能反对疾速业务部署，又能高效的实现转码性能。
通过比照和选型，最终选定腾讯云的云函数。在云上采纳云函数 + COS 的形式，能够反对弹性伸缩，即便把本地流量全副切到云上，也能有全副承载。那么新的业务流程，就会退出任务调度模块，当业务流量过去的时候，能够主动或者手动把流量别离导入自研服务和云上服务，并在流程里退出了很多高可用的技术，比方通过工作 TraceID 进行全链路追踪、云端计算失败本地从新计算一次等。新的计划里，云端服务开发起来很简略，且不须要投入太多的运维精力，费用绝对也很低，用多少付多少。
Serverless 是云计算的必然趋势，也是云原生的利用场景之一，期待大家可能有更多的尝试和分享。
One More Thing
3 秒你能做什么？喝一口水，看一封邮件，还是 —— 部署一个残缺的 Serverless 利用？
复制链接至 PC 浏览器拜访：https://serverless.cloud.tenc…
3 秒极速部署，立刻体验史上最快的 Serverless HTTP 实战开发！
传送门：
- GitHub: github.com/serverless
- 官网：serverless.com
欢送拜访：Serverless 中文网，您能够在 最佳实际 里体验更多对于 Serverless 利用的开发！
举荐浏览：《Serverless 架构：从原理、设计到我的项目实战》
