10月24日，第二届云原生技术实践峰会（CNBPS 2019）在北京圆满落幕。CNBPS是云原生领域重要峰会，每年一届，以汇聚前瞻洞察和技术干货为目标，展现全年云原生趋势和优秀实践。本文为腾讯云架构师孔令飞在CNBPS 2019上的演讲实录“一讲了解Serverless”。
大家好！我是来自腾讯云的孔令飞，今天主要跟大家从宏观的层面介绍一下Serverless。Serverless从去年开始尤其是最近特别火，因为确实能够解决我们的一些业务问题。我会借助腾讯云Serverless产品，来介绍下腾讯云是如何落地Serverless技术，以及Serverless技术所适用的场景，最后会介绍一些客户案例。
Serverless 简介
在左边这张图上，蓝色的是Serverless，在2016年它的热度已经超过微服务和Kubernetes。右边展示的是Serverless产品化的情况。比如，2014年的时候，AWS首先推出了Lambda，2016年微软、Google、IBM都分别出了自己的产品。国内来说，17年国内厂商腾讯云推出了Tencent Cloud SCF，阿里云也推出了自己的Serverless产品。18年腾讯云联合微信，推出了微信小程序云开发的产品TCB，19年，腾讯云推出了Serverless 2.0产品TSF Serverless，支持新的应用场景。
什么是 Serverless？
Serverless无服务器，不代表真的不需要服务器，只不过服务器由云厂商维护。它是一种软件系统架构思想和方法，不是软件框架、类库或者工具。它的核心思想是，无须关注底层资源，比如：CPU、内存和数据库等，只需关注业务开发。
我们从另一个角度来看下 serverless 技术为什么这么火。
这张图的前三列大家应该可以看到这 3 列代表了云计算的发展阶段，从刚开始的 On-Premise 到 IaaS 层，再到 PaaS 层。第四列 FaaS 层，serverless就在这一层。
在软件研发领域，我们绕不开的两个环节是软件的部署和运维。如果我们要上线一个业务，在 On-Premise 阶段，我们要去购买物理服务器，然后还可能需要去建自己的机房，安装制冷设备，招聘运维人员，然后再上面搭建一系列的基础设施，比如：虚拟化，操作系统，容器，Runtime，Runtime 可以理解为像 python, golang, nodejs 这类软件。接下来我们要去安装软件类的开发框架，到最后，我们才会去编写我们真正需要的业务函数。到了 IaaS 层这一阶段，云厂商维护了硬件和虚拟化这两个基础设施。
到了 PaaS 层云厂商又维护了 OS、容器和 Runtime，然后到了 FaaS 阶段，用户只需要关注 Function，也就是只需要关注自己的业务逻辑。可以看到随着阶段的演进，用户需要关注的点越来越少，越来越聚焦于自己的业务逻辑。所以在 On-Premise 阶段，我们开发一个业务可能需要 8 个人，在 FaaS 阶段，我们只需要 2 个业务，节省了很多人力，可以把节省的人力投入到业务研发这块，提高产品的迭代速度，进而提高产品的竞争力。
由这张图我们也可以看到，过去十多年云计算其实是一个“去基础架构”的过程。这个过程可以让用户聚焦于自己真正需要的业务开发上，而不是底层的计算资源上。serverless 符合云计算发展的方向，是云的终极形态，这种特有的模式使serverless 存在潜在的巨大价值。
Serverless技术形态
这里介绍下Serverless的技术形态。目前腾讯云Serverless一共有3种技术形态。
一种是Cloud Function，Serverless Cloud Function 是基于事件驱动型的，大概意思就是外界触发一个事件给 Serverless 平台，Serverless 平台收到触发事件后，会调用函数并传入触发事件数据和参数信息，函数内部做业务逻辑处理之后返回给调用方。Serverless Cloud Function 可以对接多种云上的产品，比如：api网关、ckafka、cmq、COS对象存储等。
event function 是一种开发模式，要求业务将业务逻辑拆分成function 这种粒度，这种方式国外接受程度比较高，但是国内很多用户都还停留在 HTTP 这个阶段，为了能够方便现有的业务迁移到 serverless 平台，适配现有业务的调用方式以及扩展 serverless的使用场景，我们又提供了TSF Serverless这种方式。
TSF Serverless，Service 这种形态可以理解为我们通常意义上的 HTTP 服务，简单理解就是把 HTTP 服务的运行环境从物理机或者虚拟机或者容器换成 serverless 计算资源。这种形态服务进程常驻，不限制运行时间，因为服务进程常驻，所以它一直在监听请求，所以请求延时更低，同时也支持长连接和一定的内场共享能力。因为 service 这种形态，跟我们现在的服务运行方式是一致的，所以业务可以无缝迁移到serverless 平台上，不需要做过多的改造。同时TSF Serverless支持Spring Cloud这种微服务框架，也支持Service Mesh这种服务形态。
还有一种就是Tencent Cloud Base这种形态，这种形态是我们联合微信团队推出，简化小程序开发流程，里面封装了很多功能，比如：云函数，对象存储，数据库，方便用户开发小程序。这也是云函数的一个典型应用场景，通过封装云函数，提供一些PaaS能力。
Serverless Cloud Function 组件架构
Cloud Function 组件架构
这里介绍一下Cloud Function的组件架构，让大家了解下，我们底层都做了哪些工作，来实现serverless这门技术。这张图描述了 serverless 的组件架构。最底层是基础设施层，底层计算资源我们用到了 docker 和轻量化虚拟机技术，其中 docker 是 serverless1.0 的计算资源展现形态，轻量化虚拟机是serverless2.0 的计算资源展现形式，相比于 docker，轻量化虚拟机性能得到了非常显著的提升，可以在几毫秒就可以启动一个业务进程。在最底层我们也做了双活，并且对底层资源做了严格的安全保护。
再上一层就是资源管理层，比如说我们有集群监控，监控我们的集群监控状况，如果有集群不可用，会立马安排运维人员去排障，当然了，我们刚说过我们底层是有双活的，当一个集群出故障的时候，我们可以把流量切换到另一个集群，用户是无感知的，也不会影响用户的请求。这一层我们有专门的自动扩缩容算法，来应对用户的请求变化。再往上，我们有认证和授权系统，通过认证和授权来保证函数的安全。再上面就是接入层，接入层主要用来触发 Function 的调度和执行。在往上就是架构层，主要用来做一些流程上的调度。最上面这2 层是用户需要关心的，用户主需要关注自己的业务代码，以及跟数据库，存储等的调用，还有自己使用的一些框架，其它底层的设施用户完全不用关心，全是由云厂商来提供专业的保障和维护。
我们还提供了很多外围的工具系统，来支持用户的研发、部署和排障。比如：DevOps 支持，日志、监控、告警支持。后面会有介绍。
运维工具建设
刚才讲了Serverless是如何支持函数的运行，其实就是讲了计算资源。但是要真正使用Serverless这个技术，光有计算资源还不行，还要有其它工具来支持Serverlss的开发和运维。接下来我从开发者工具，CI/CD，日志，监控告警来介绍下腾讯云是如何支持serverless的。
首先来介绍下开发工具，为了支持开发者能够方便高效的开发和部署云函数，我们开发了一系列的工具，比如：我们提供 VS Code 插件，通过 VS Code 插件，开发者可以很方便的通过 IDE 直接部署、更新和调试云函数。我们也提供了 Web IDE 来方便用户直接在网页开发代码。此外我们还提供 CLI 工具，通过 CLI 用户可以在终端很、方便的通过命令调用完成诸如配置、部署、调试、调用等功能。最后我们还提供 API 接口来满足用户对自动化和定制化的需求。最后我们还提供 SDK 供用户更方便的调用云函数的接口。所以可以看到要将 serverless 产品化，还需要做很多其它工作来支撑 serverless 这个技术，尤其是工具这块儿。
除了开发者工具，我们也提供完善的 DevOps 支持，从最佳实战，到工作流，到工具链，以及产品打通，我们都提供了很多方案和支持。
比如工作流这里，我们支持编码、构建、打包、部署、测试和发布等一系列流程。在工具这里，我们提供了：CLI、应用模型等。产品这里，我们打通了很多产品供用户很方便的跟这些产品进行交互，利用这些产品提供的能力，比如：Git 仓库，API 网关，ServerlessDB等。这个是 DevOps 支持。
日志这里我们支持 2 种日志查询方式，方便用户查看日志。在 scf 控制台上，能够查看函数调用成功与否，各阶段的调用时间，以及用户打印在日志或者标准输出的日志，支持用户按 RequestId 去搜索日志。另外我们还支持用户将日志输出到腾讯云日志服务系统，将日志持久化存储，在日志服务系统中，用户可以根据正则表达式来搜索日志，也可以自定义检索规则，方便下次检索。
Serverless Cloud Function 应用场景
这里介绍一下应用场景，先介绍下 Cloud function 的应用场景，通过这张图，我们可以看到，云函数可以作为浏览器、APP 和小程序的后端服务。通过我们提供的不同触发器可以支持不同的场景，比如通过 API网关触发器，可以匹配 websockt 的应用场景，通过cos/cmq/ckafka 触发器可以支持像：消息处理、流失计算，事件通知这类的应用场景。
Serverless Cloud Function 客户案例
这个是腾讯地图的客户案例，走的是 event function 这种方式。场景是这样的：用户在访问腾讯地图是会产生一些数据库，腾讯地图会将这些数据进行整理并保存到 Hbase 和 ES 上，然后再配上一个 UI 用来查询数据。当用户产生一条数据时，会将这条数据放在 kafka 队列中，kafka 触发后端的云函数，云函数做数据处理之后又将数据放入 kafka 队列中，由另外一个进程从 kafka 队列中取走处理后的数据，放入 ES 和 Hbase 中。
Tencent Cloud Base
下面介绍一下TCB。做小程序开发时，要有一个小程序前端，也需要有后端，写后端时，需要处理很多后端需要的组件或者功能，比如数据库、存储或者CDN等等，都需要研发工程师自己去给产品写接口、做调用，工作量非常大，这时候可以通过TCB来解决，TCB就会变成右边这样。前端仍然有一个小程序的前端，中间We-Chat Backed主要用来做授权，当授权通过后，会把请求转发到TCB组件，这个组件会提供很多SDK，提供的SDK里面封装了很多功能，比如数据库、对象存储以及云函数，直接通过TCB的SDK调用，这样就不需要处理后端那么多组件，让用户非常方便的去开发一个小程序。
TSF Serverless
这里介绍一下TSF Serverless，TSF是腾讯云的微服务产品，这个产品底层之前是支持基于虚拟机和基于容器部署应用，我们又增加了基于Serverless第三种部署方式。基于Serverless的话，用户不需要去关注底层资源，只需要去部署容器就可以了。
这个是它的组件架构，最底层是Serverless计算托管的一些功能，比如集群管理容器，这是Serverless底层的一些计算的展现形式。再上一层微服务部署框架，这个部署可以原生支持一些微服务功能，比如服务注册、服务发现以及服务限流、服务熔断、动态配置、服务监控、负载均衡、服务容错、服务审计等等。
TSF Serverless 应用场景
这里介绍下TSF Serverless其中的一个典型场景。假设我有一个 APP 应用跨多端的，比如 Android，iOS，Web。如果想写后台的话，我可能要写多个接口，去适配不同的终端。这样如果后端有变更，需要去更改 3 个终端的 API 接口，与此同时，当我们需要对一个字符串进行处理，如限定 140 个字符的时候，我们需要在每一个客户端（Android，iOS，Web）分别实现一遍，这样的代价显然相当大。
现在有一个比较流行的解决方案就是在前后端加一个 BFF 层（Backend For Frontend）将前后端解耦，这里是 BFF 层可以承载的能力比如：身份校验，日志记录，数据组合等。BFF 一般由前端工程师去编写，适配不同的后端当后端有变更的时候，只需要改 BFF 层就可以，不用去更改客户端。BFF 层可以部署成 HTTP Service，也就是可以直接利用我们提供的 HTTP Service 技术形态来部署。通过 BFF，可以让前端工程师变成全栈工程师，开发不用去关注底层的资源。因为BFF一般是HTTP服务，所以TSF Serverless就很适合这个场景。
新年彩蛋来了！！！
在微信公众号后台回复关键词：2020 ，一起来瓜分新年666红包！
