Serverless 一站式云原生应用开发实践
导语 | 在云的时代，更多的应用将迁移到云端，云原生基于云的架构设计和开发模式，是一套全新的理念。Serverless 技术因其降低开发成本、按需自动扩缩容、免运维等诸多优势，已经大量被开发者采用用来更快的构建云上应用。本文是腾讯云Serverless技术专家王俊杰&方坤丁老师在「云加社区沙龙online」的分享整理，希望与大家一同交流。
点击视频，查看完整直播回放
一、重谈 Serverless
在国内搜索引擎搜索“Serverless” 会有许多五花八门的答案，有些人认为 Serverless 是前端的 3.0 时代，会给前端开发者带来很好的收益改变。社区也在谈 Serverless，知乎上也有人会问一些问题。当我们谈论 Serverless 时，不禁会有一个疑问，你说的 Serverless 到底是哪个 Serverless？大家对 Serverless 的理解其实是有一些困惑的，通过下面这张搜索引擎的截图大家就可以看到，对于 Serverless 有很多不同的解读。
其次，大家都在做 Serverless，但是好像我们每次看到、听到这个词的时候大家讲的又不太一样，这是为什么呢？那么，Serverless 到底是不是在炒概念，是不是过热，是不是每一家都想跟这个词产生一些关系？
为了理清这几个问题，我们还是要从 Serverless 的起源开始说起。2016 年的时候， Serverless 的搜索量开始突飞猛进的增长，到了 2020 年，它的搜索量几乎是 2014 年的 6 倍。
其实，Serverless 理念最早是在 2006 年提出的，后来伯克利的学者也认为这就是云计算的一个基础理念。2012 年，Iron.io 首次提出了 Serverless 这个概念，但和我们现在所说的 Serverless 其实不太一样。
真正意义上的 Serverless 产品是在 2014 年的时候 AWS lambda，一定程度上改变了大家对 Serverless 的认知。2016 年的时候，GCP Clould Function 和 IBM Open Wisk 也发布了对应的函数计算的产品。2017 年，腾讯云也发布了第一个 Serverless 相关的产品。在 2018 年和 2019 年，我们也相继推出了 Serverless 平台的一些产品。
关于 Serverless 的概念，我们先看一下学术圈是如何解读的。6 月 19 号，Serverless 社区在中国举行了一场大会，请到了一位伯克利的学者，他在 2019 年 2 月 10 号发表了一篇非常重要的论文《A Berkeley view on the Serverless Computing》，从伯克利的观点讲解了 Serverless 到底是什么。
论文里提到，Serverless 其实是一种 无服务器云计算，它几乎封装了所有底层资源运营管理工作，开发人员可以更容易的使用云设施。
举例来讲，我们在使用汇编语言的时候，需要非常了解计算机的底层资源结构，Serverless 提供了一个方式，极大地简化了基于云服务的编程，犹如汇编语言到高级编程语言般的转换。
其实，Serverless 对于云计算来讲也是这样，大多数云计算有太多底层的技术资源，包括计算、网络、存储等，但对于开发者来说最重要的是去做业务。如下图所示，这个模型正好能解释上面的理论，在我们的整个软件体系结构中，最上面一层我们叫做核心业务逻辑。
第二层是一些框架支撑，比如：应用框架、数据库、文件存储、CDN等等。再下面一层是一些系统运维相关模块，包括日志日志和监控、扩展性设计、多并发调度等。再下面一层可称为底层设施，包括主机容器、系统安全、数据恢复备份等等。图中“钱”的符号指的是，第一层业务可以直接带来业务收入，所以越往上层它的 business value 越大。根据Serverless的定义，就是让开发者专注于业务，而非底层资源。
Serverless 的好处是可以降低成本，按需付费，依照执行次数付费，没有执行就没有资源开销。其次，Serverless 的入门门槛比较低，底层基础设施的技术门槛其实很高，人力和成本的开销也很高，但是使用Serverless开发则不需要考虑这些问题。
二、Serverless 落地的一些思考
云计算将业务场景和底层资源做了链接，一边是业务，一边是底层资源。业务和底层资源进行链接的传统方式有很多，比如之前流行的LAMP/LNMP架构，基于云搭建后端服务的场景。那么Serverless是如何链接上层应用和底层的资源呢？
Serverless 提供了两种方式，第一种就是现在比较流行的概念，叫做 Serverless = FaaS + BaaS ，首先用函数计算 Function as a Service 来解决算力部分，同时还有一些后端的服务 Backend as a Service。比如我们的对象存储服务、各种 API、数据库、消息队列都是属于BaaS的范畴。
第二种是采用 Serverless 一站式的整套解决方案，只需要关注上层应用就可以，把一切包括可扩展性系统、安全性、资源问题、流量问题，全都交给 Serverless 解决方案来实现，这种模式更贴近于真正的 Serverless 内涵。
这种一站式的Serverless解决方案，针对每一个业务场景都提供了对应的解决方案，框架封装了所有对于云资源的分配和操作。这样的情况下只需要关注最上层的业务场景，不需要关注底下云到底用了多少资源。
三、基于 Serverless 的云原生应用
什么是基于 Serverless 的云原生应用，我觉得有三点。
第一，必须是一个云原生应用，是全部基于云环境的构建和运行的可弹性扩展的应用。
第二，应用的每一个部分都是基于 Serverless 实现的。
第三，符合只需专注于业务，不用关注任何非底层资源。
我们认为在做开发的时候只用关注业务本身，不用关注任何底层资源，它就是一个 Serverless 云原生应用。
举一个例子，在前端开发的领域经常会听到一个词叫“Full Stack”——全栈开发。
全栈开发包括前端、后端和数据库，这种全栈开发在 Serverless 里提供解决方案就包含三部分：它还有一个 Serverless Website 作为静态资源存储，一个Serverless Express提供HTTP服务和API、一个 Serverless Database 作为数据库。它的每一部分都是基于 Serverless 技术实现的，所以说它就是一个 Serverless 云原生应用。
一般来说Serverless 云原生应用包括了 Serverless Website、Serverless HTTP、Serverless Database、Serverless Back-ends几部分。Serverless Website 解决静态文件和资源部署，Serverless HTTP 提供 Web 和 API 的服务，Serverless Database提供 SQL or NOSQL 数据库。这些都可以通过Serverless 框架和 Serverless 平台云基础设施来对接。
四、Serverless SSR
1. 分钟级部署一个Serverless SSR应用
进入具体场景中，本次分析的是我们前端很流行的 SSR 场景。SSR 到底是什么？如何用 Serverless 的方式去构建一个 SSR 的应用呢？
如何鉴定一个 Serverless 应用到底是真是假，可以通过下面这个 demo 来看一下，部署一个 Serverless 的 SSR 应用到底需要多久。
现在我 VS Code 编辑器里展示的项目和传统的有所不同，这个应用本身其实是部署在 Serverless 的架构上的，但是可以看到它的应用代码完全就是 next.js 的原生业务应用，它唯一不同的其实就是在目录结构外面，提供了一个 Serverless 的配置文件能力。
项目依据配置文件进行部署，用户只需要关注自己的业务代码，不需要关心底层使用了哪些资源。我们的 Serverless Framework 工具会帮助你把一切底层资源搞定，然后部署在一个基于纯 Serverless 的架构上。
接下来输入命令，把项目部署到云端，可以看到进度条的提示，正在打包上传自己的业务代码，上传速度也有三倍提升的性能优化，会把它打包上传到我们的对象存储里。但其实作为用户来说，我们根本不需要关注它，只需要知道它已经在做这种打包和上传。
在 Serverless 项目里，本身会有很多静态资源在我的框架里，如果要对 Serverless 的 SSR 项目进行一步一步的优化的话，其实可以通过更多手段比如 COS 托管来实现。
我们现在已经部署成功了，大概在 20 秒左右可以部署成功。部署完成后已经输出了非常多的对应资源信息，如果希望查看底层资源，也可以很方便的在这里查询。
另外，如果采用传统的方式部署了 SSR 应用之后，正常情况下想要去看它对应的一些监控信息、资源信息之类的，其实是需要了解底层是怎么实现的，并且需要在云账号查看对应的资源。但是现在部署成功之后，可以看到它输出了一个概览页的链接，在这个链接下，就可以看到直观的监控视图。
在监控视图里也可以看到，框架层面的一些调用情况，比如调用多少次，调用之后的延时情况，还有它对应的请求以及错误情况等直观的监控视图。在模拟刷新了几次 404 的页面后，然后在我的监控面板上可以非常及时的看到它其实有一些 API 的 error，能看到这些 error 的次数，包括它能够识别出来我对应的路径。
至此，通过 Serverless 一键部署项目到云端。首先我们发现秒级就可以完成完成，其次就是在部署完成之后，可以看到非常直观的、开箱即用的应用级别监控视图。
2. Serverless SSR 实现原理
接下来，我们介绍一下 SSR 本身的演变背景，最早的时候，我们的前端页面是可以通过后端来直接渲染生成的，也就是说服务端直接生成 html 并且返回给浏览器。但这样其实有非常多限制，而且它的前后端也不够分离。
大概在 10 年前，完全通过 PHP 构建网站、博客的经验就是直接通过后端渲染来进行的。在这之后，因为刚才提到的种种弊端，比如它本身的交互能力有限，并且前后端无法分离，所以出现了演变，就是通过客户端进行渲染。
客户端渲染也是目前比较常用的手段，在页面开始加载服务端返回 html 的时候，其实是没有内容的空页面，需要浏览器去执行文件动态生成和渲染页面，也就是通过客户端进行页面的生成和渲染。
这样做的方式可以理解为前后端分离的，但它也有非常多的缺点，比如 SEO 不友善，首屏加载慢等。基于这个背景，就产生了 SSR 的概念，也就是同构渲染，基于我们现在非常流行的 react，vue 的前端框架，将客户端的渲染和服务端的渲染进行了结合。这样就可以在服务端首先执行一次，直接渲染出来，然后客户端再进行，用于后续接管页面的一些交互能力。
SSR 相比于客户端渲染的优势是首屏直出非常快，从刚才的 demo 也可以看出，刷新第一次页面的时候几乎感觉不到加载的过程。另外一个优势是通过服务端的渲染，能够加载更多内容，比如一些元数据信息，搜索引擎可以更便捷、快速的获取这些信息，从而进行优先展示。
SSR 在用户体验和性能收益上比 CSR 强很多，但既然 SSR 这么好，为什么不是所有的公司所有的应用都采用了呢？假设我们现在有一个项目已经部署完成即将上线，在上线过程中准备使用 SSR 方案，可能问题就来了，需要考虑服务的究竟该怎样实现，以及服务器性能、服务节点、它本身的扩展性、如何运维等问题。另外，在搭建的时候应该怎样部署，怎么搭建进来并接入整个流程都是需要考虑的问题。
对于前端工程师来说，他们不希望去关心和不希望去考虑这些问题，所以有很多公司会因为考虑开发成本和运维成本反而觉得可以牺牲一些用户体验，因为 CSR 更加方便，这就是 SSR 还没有完全普及的一个原因。
相比于传统的 SSR 服务端渲染，Serverless SSR 的优势在于它本身的架构是完全 Serverless 化而且秒级部署的。
在传统的 SSR 上，浏览器进行交换的时候其实是要和 node server 进行交换，然后去渲染。既然这边有一个 node 节点，就无法避免的会消耗服务资源，然后就需要去运维。如果现在直接通过 Serverless 的架构来替换 node serve，它本身可以基于函数进行部署。这样可以免除很多运维工作，相当于把它部署过去后其余的一切都不需要我们来考虑，只关注业务就可以了，它的底层资源管控、扩容这些都交给云厂商来负责。
此外，在做 Serverless SSR 架构的时候，还有一个能力就是提供对应的静态资源的分离存储，在项目中把一部分静态资源存储到了对象存储里，这样优势更加明显，渲染速度也会更快。
因为所有的静态资源其实是不需要在计算层面去加载，而是直接托管到了静态的 cos 里面进行存储，它的整体的架构就是这样，通过浏览器、网关点进行接入层和转发，然后对应到后端云函数进行处理。
可以看到，无论是 API 网、对象存储还是 Serverless 原函数，这三个资源都符合 Serverless 的概念。而且它能够弹性扩缩容，能够使用量付费。在业务高峰的时候，可以帮助你弹性的扩容，去满足业务高峰的需求，不需要任何手动的干预和运维。
3. Serverless 云原生应用的开发方法和流程
在传统的开发方式里，很多想法是自底向上的，如果要部署一个实际的应用首先会去想它的整体架构，需要考虑负载均衡、安全、运维等等。考虑基础资源后，又要考虑这些资源或服务如何组合、编排、串联，最后才是实现真正应用的场景。
这种自底向上的思考方式会让应用的搭建的门槛变得很高并且非常复杂，因为要掌握很多底层知识，比如每个产品该怎么配置、怎么连在一起才能达到业务场景。
而 Serverless 云原生应用最大的改变就是思路变成了自顶向下的，也就是从场景出发的。比如要部署一个 Serverless 应用，首先会想它的应用场景是什么选定场景之后，后续底层的编排组合和用到了哪些资源，是如何使用的，怎样做弹性扩充和运维都不需要考虑。只需要去了解场景希望是怎样的，以及业务要怎么实现，更多的关注于业务代码的实现。
有了这个思路的转变，可以看到在云原生应用的开发方法与传统方式并没有太大区别，思路转变后整体流程会变得更加顺畅。有了自己的 Serverless 应用想法后，可以直接再写对应的 Serverless 模板。
在开发调试阶段，为了能够避免本地环境和云端环境的差异，可以直接调试云端代码并对全段代码、日志进行输出和拉取。这是思路上的差异，本身和传统的开发方式没有区别，包括调试流程。
4. Serverless 云原生应用的监控及运维
最后一步是运维的流程，部署 Serverless 应用后，可以直观的看到监控信息的页面，在这个页面里可以对业务进行监控、运维，并及时的查看错误。基于一站式 Serverless 的应用开发流程本身就是一站式的云端开发体验，云端的开发调试包括部署运维的体验。
除了开发部署之外，还有刚才提到的应用本身的监控和运维，包括日志查询也可以结合我们现在的页面进行演示。如果有异常情况需要查看日志详情，可以看到非常清晰的记录。无论从前端的网关层还是函数层都可以通过 ID 来进行排查。
此外，这个函数里还有一个高级日志检索能力，可以直接进行详细搜索，另外也有一些其他条件设置，比如对运行时间对设置，日志本身的功能也是非常强大的。
在这种情况下，开发流程其实已经变得全部都在云端化了，无论是从开发、调试还是运维，都能在云上完美地覆盖到。包括页面监控，虽然对于用户是不感知的，但其实是通过内置的 SDK 做部署时做了很多自定义指标的上报，所以本身对客户来说是透明的。
最后，Serverless SSR 的客户覆盖了各个领域，包括教育、游戏、电商还有视频行业，现在接触很多的在线教育平台，包括企鹅辅导、腾讯课堂的整个页面都已经基于 Serverless SSR 部署了。猎豹移动、人人视频等客户反馈，在使用了 Serverless SSR 架构之后，部署和运维等工作量降低了 80% 以上。
5. Serverless SSR 的案例及展望
基于 Serverless SSR 的架构并不能说已经做到了极致，后续还会有更多的展望能力。比如静态资源存储，可以提供一种非常快速一键式部署的能力。包括缓存页面时，可以借助 Redis 等缓存机制来实现，这些本身已经是一些成熟的方案，只不过需要做进一步的改造。
Serverless SSR 后续计划支持更多高级能力，包括缓存加速， SSR 变为 CSR 的降级处理等。感兴趣的朋友可以通过以下链接体验便捷的部署过程：
https://serverless.cloud.tencent.com/deploy/nextjs
几秒钟后，页面就会出现一个新的 SSR 应用，打开对应的页面可以看到已经部署完了一个全新的应用。如果多访问一下这个页面，它的监控也会马上在页面中展示出来。真正做到了秒级部署，开箱即用！
Q&A
Q：Serverless 平台对代码包的大小有限制吗？
A：限制应该是会有的，但限制本身是可以扩大的。腾讯的 Serverless 平台计划有 500 M 的代码限制，这是指解压后的大小，限制本身的考虑是希望给客户提供更好的加载代码的性能，因为本身代码过大、资源过大的时候我们会推荐使用共享文件存储，后续也会推出共享能力支持扩大代码限制。
从我们的一些客户经验来看，目前 500 M 是完全够用的，而且代码超过 500 M 还放在同一个函数里的话，我们建议最好在架构上拆分一些不同的函数来进行，或者用存储管理的方式进行函数整个架构的管理。
Q：怎么针对突发流量进行扩展，是否是增加实例的方式？
A：对的，限制腾讯的 Serverless 平台对应突发的流量会有一个默认的并发上线，它本身也支持扩展，在上上限以内会通过增加实例的方式来扩展。但这些客户是不感知的，并且现在平台会通过一些行为，比如用户的一个部署操作，根据流量本身的预测会做提前扩展。也就是说它扩展的时候会更激进一些，但是在回收的时候会更缓慢。这样能非常好的保护客户的业务不受影响，能够提前扩容。
Q：通过什么方式来部署？
A：其实这是比较偏后台的技术，Serverless 的全新架构通过一种微虚构机的方式进行部署，进行部署和扩容的具体实践在公众号、社区网站上也有一些对应的内容，因为它本身涉及的技术点比较多，这种 微虚构机方案其实是更加为 Serverless 平台定制的，也就是说它从网络、从性能方面都有非常好的优势，这位同学可以后面再去参考一下我们的技术资料。
Q：行业是否有标准接口？是否强耦合于某个平台？
A：Serverless Framework 在工具或编排的一个领域上，它本身已经成为了一个规范。它本身就不是强耦合于某个平台的，既能很好的支持腾讯云，也能支持 AWS 和其他很多运厂商，它的规范其实更加中立，并且它本身在业界非常受欢迎，所以其实它已经成为了一个事实上的规范，它的借口规范也是腾讯正在遵循的一个规范。所以不用担心这种强耦合，比如云厂商绑定的这种问题。
Q：迁移 Serverless 的时候主要考虑哪些因素？
A：我们现在其实在很多这种大客户做迁移的时候，会有一些方案或者一些成熟的经验可以给到客户来借鉴，也会有不同的场景。我们的 Serverless 迁移没有任何成本，应用代码没有再修改的地方。所以这些框架，尤其 Service Framework，它本身支持了非常多的外部框架，迁移其实已经做到了零成本。
如果有其他场景可能要单独细分来看，我们现在很多的客户实践中其实也是通过类似于微服务的方式转换进行架构组合，可以比较好的衔接在一起。
Q：是否可以让域名直接访问到项目上？
A：这个是完全支持的，完全没有问题的。我这次没有演示是因为我自己的域名已经在另外一个项目中被占用了，但是其实非常简单，就是在自己的项目里增加一个新里的配置，然后增加你的域名就可以了。也就是说可以使用自己的域名来部署各种各样的项目，这个是支持的。
Q：Serverless 更适合哪种应用场景？
A：其实前面提到的全栈场景、website 静态托管场景，包括外部的服务托管场景，还有一些数据的传输都是非常适合的。另外还有同学咨询运维难度，其实 Serverless 的运维难度大大降低了，而且更多的是从机器运维或者资源运维改为了业务运维。
Q：Serverless 在物联网方面有什么优势？
A：Serverless 在物联网的结合是非常典型的，支持接入语音对话平台的能力，包括微信公众号，连接物联网设备等等，其实很多事件出触发的场景下是非常适合用 Serverless 架构来做的。包括用 Serverless 连接智能音箱等场景。
文章推荐