基本概念
无服务器
无服务器架构说法的来源可以根据 Mike Roberts 在 Martin Fowler 的博客网站上发表的 无服务器架构 一文中得到解释。
无服务器并不是没有服务器就能够进行计算，而是对于开发者来说，无需了解底层的服务器情况，也能使用到相关资源，因此称为无服务器。
无服务器也可以从更广的角度来识别，针对无需配置和了解底层的服务器就可以直接使用的云服务，在一定程度上也可以称为无服务器。
在云函数 SCF 产品中，我们针对的是无服务器场景中的计算场景。云函数产品提供的是无服务器模式下的 FaaS 能力。
函数即服务
函数即服务提供了一种直接在云上运行无状态的、短暂的、由事件触发的代码的能力。
函数即服务和传统应用架构不同，函数服务提供的是事件触发式的运行方式，云函数不是始终运行的状态，而是在事件发生时由事件触发运行，并且在一次运行的过程中处理这一次事件。因此在云函数的代码中，仅需考虑针对一个事件的处理流程，而针对大量事件的高并发处理，由平台实现云函数的多实例并发来支持。
为了实现对高并发的支持，云函数平台提供了自动的弹性伸缩能力，会在有大量请求到来时启动更多实例来处理事件请求，也会在没有事件到来时缩减函数实例甚至到零实例。因此为了匹配自动扩缩能力，需要函数代码使用的是无状态开发方式，即不在云函数的运行内存中保留相关的状态数据并在多次运行时依赖这些状态数据。云函数的状态数据，可以依赖外部的持久存储能力例如云缓存、云数据库、云存储来进行。
触发器和触发源
任何可以产生事件，触发云函数执行的均可以被称为触发器或触发源。触发器在本身产生事件后，通过将事件传递给云函数来触发函数运行。
触发器在触发函数时，可以根据自身特点，使用同步或异步方式触发函数。同步方式触发函数时，触发器将等待函数执行完成并获取到函数执行结果；异步方式触发函数时，触发器将仅触发函数而忽略函数执行结果。
腾讯云云函数在和腾讯云的某些产品或服务对接时，也有自身实现的一些特殊方式，例如推（PUSH）模式和拉（PULL）模式。
推模式：触发器主动将事件推送至云函数平台并触发函数运行。
拉模式：云函数平台通过拉取模块，从触发器中拉取到事件并触发云函数运行。
触发事件
触发器在触发函数时会将事件传递给云函数。事件在传递时以一个特定的数据结构体现，数据结构格式在传递时均为 JSON 格式，并以函数 event 入参的方式传递给云函数。
触发事件的 JSON 数据内容，在不同的语言环境下将会转换为各自语言的数据结构或对象，无需在代码中自行进行从 JSON 结构到数据结构的转换。
例如，在 Python 环境中，JSON 数据内容会转变为一个复杂 dict 对象，即函数的入参 event 就是一个 Python 的复杂 dict 对象。而在 Golang 或 Java 中，入参是一个需要和 event 数据结构可以匹配的对象。更具体的实现方式可以见 开发语言说明。
工作原理
函数运行时的实例模型
云函数 SCF 将在函数接收到触发请求时为您执行函数。SCF 执行请求的资源为实例，根据函数的配置信息（如内存大小等）进行资源分配，并启动一个或多个实例处理函数请求。SCF 平台负责所有函数运行实例的创建、管理和删除清理操作，用户没有权限对其进行管理。
Serverless 的价值
首先，从开发者使用的来说，不用更多的去考虑服务器的相关内容，无需再去考虑服务器的规格大小、存储类型、网络带宽、自动扩缩容问题；同时，也无需再对服务器进行运维了，无需不断的打系统补丁、应用补丁、无需进行数据备份、软件配置等工作了。
其次，Serverless 产品是完全自动化的弹性扩缩容的；在业务高峰时，产品的计算能力、容量自动扩容，承载更多的用户请求，而在业务下降时，所使用的资源也会同时收缩，避免资源浪费。
再次，跟随着完全自动化的弹性所带来的，是全新的计量计费模式；开发者仅需根据使用量来付费，而在深夜无业务量的情况下，不会有空闲资源占用，因此也不会有费用产生。
- 1、降低运维需求：
Serverless 使得应用与服务器解耦，业务上线前无需预估资源，无需进行服务器购买、配置；
Serverless 也使得底层运维工作量进一步降低，业务上线后，也无需担忧服务器运维，而是全部交给了云平台或云厂商；
- 2、降低运营成本：
Serverless 的应用是按需执行的。应用只在有请求需要处理或者事件触发时才会被加载运行，在空闲状态下 Serverless 架构的应用本身并不占用计算资源；
而在使用 Serverless 产品时，用户只需要为处理请求的计算资源付费，而无须为应用空闲时段的资源占用付费；
- 3、缩短迭代周期、上线时间：
Serverless 架构带来的是进一步的业务解耦，应用功能被解构成若干个细颗粒度的无状态函数，开发可以聚焦在单功能的快速开发和上线上；
同时拆解后的云函数，也都可以进行独立的迭代升级，更快速的实现业务迭代，缩减功能的上市时间；
- 4、快速试错
利用 Serverless 架构的简单运维、低成本及快速上线能力，可以来快速尝试业务的新形态、新功能；
利用 Serverless 产品的强弹性扩容能力，在业务获得成功时，也无需为资源扩容而担心；
Serverless 的技术特点
这里提到的技术特点的对象，特指 Serverless 产品中的计算产品，也就是云函数。云函数包含了如下的技术特性：
事件驱动
云函数的运行，是由事件驱动起来的，在有事件到来时，云函数会启动运行
Serverless 应用不会类似于原有的监听-处理类型的应用一直在线，而是按需启动
事件的定义可以很丰富，一次 http 请求，一个文件上传，一次数据库条目修改，一条消息发送，都可以定义为事件
单事件处理
云函数由事件触发，而触发启动的一个云函数实例，一次仅处理一个事件
无需在代码内考虑高并发高可靠性，代码可以专注于业务，开发更简单
通过云函数实例的高并发能力，实现业务高并发
自动弹性伸缩
由于云函数事件驱动及单事件处理的特性，云函数通过自动的伸缩来支持业务的高并发
针对业务的实际事件或请求数，云函数自动弹性合适的处理实例来承载实际业务量
在没有事件或请求时，无实例运行，不占用资源
无状态开发
云函数运行时根据业务弹性，可能伸缩到 0，无法在运行环境中保存状态数据
分布式应用开发中，均需要保持应用的无状态，以便于水平伸缩
可以利用外部服务、产品，例如数据库或缓存，实现状态数据的保存
Serverless 的应用场景
Serverless 架构或者技术，可以用在什么样的场景下，来充分发挥它的优势呢？如下的场景，都适合使用 Serverless 架构或产品，来实现所需的业务逻辑。
- WEB 及移动后端
通过结合使用云函数和 API 网关或 HTTP 触发器，可以对外提供 URL 访问地址，成为 Web、小程序、或移动应用等的后端服务。Serverless 架构既可以直接用于构建后台来服务应用，也可以通过类似 BFF 模式，构建中台和应用间的桥梁。
Serverless 架构提供的强弹性能力，使得可以支撑业务或应用的暴涨；而提供的低运维需求，使得开发者可以专注于业务实现和优化；同时，按实际使用量的付费方式，使得开发者无需预配置资源，无需担心预配置资源的浪费。
- 消息处理
Serverles 架构的应用本身是由事件触发的，因此极其适合于进行消息处理。无论是消息队列中传递的业务消息，还是 Kafka 中采集应用日志，均可以对接到云函数上，进行实时的消息处理、分析。
- 对象存储文件处理
在 Serverless 应用场景中，由对象存储中的文件上传事件，来触发云函数的运行，也是一种常见场景。针对图片文件的上传，可以借助云函数完成图片的缩略图生成、二维码或水印标记、图片优化处理；而针对数据文件的上传，可以启动数据的自动化分析，
- 物联网
物联网意味着成千上万的设备会连入网络，时刻在不断的产生数据，这对数据的分析、处理的及时性提出了很高的挑战。通过使用 Serverless 架构，物联网设备所采集的数据将可以作为云函数的触发事件，而实现数据的实时处理、分析和应用。
随着物联网设备计算能力的进一步提升，云函数作为最小粒度的计算单元，有机会被调度到设备端运行，实现边缘计算，达到端-云联合的 Serverless 架构。
- 运维及集成
通过对接云函数以及云上的各个产品、日志服务、监控告警系统，云时代的运维也都可以用云函数来构建。定时触发的云函数，将可以方便的替代需要在主机上来运行的定时任务；而日志或告警触发的云函数，将可以对云中的事件作出立刻回应及处理。
Serverless - 云原生时代的应用架构
云计算已经进入了新的时期，目前上云已经不是应不应该，而是如何上云的问题。在这种情况下，云原生的概念也随之而生。云原生的架构或应用，是基于云而设计的，充分的利用现代云计算平台所具备的弹性和分布式特性来实现应用架构。
而 Serverless 架构、产品、以及应用，均是完全依托于云而构建的，是典型且完全的云原生的架构、产品或应用。 Serverless 产品所具备的产品特性优势、技术优势、费用优势，将成为新一代云产品的发展方向；而基于 Serverless 架构推进完成开发的应用或架构，将充分享受到云时代带来的强大助力，使得云计算能真正成为业务的助推器。
Serverless 的计算产品-云函数，作为云虚拟机、容器技术之后的下一代计算形态，将引来云计算中新的热潮。围绕着云函数而建设的产品能力、工具、生态、以及应用开发，也将引来新的一轮发展。随着无服务器的产品和生态走向成熟，将逐步承载起企业核心业务。 在这个持续向前高速发展的过程中，腾讯云的云函数，将作为腾讯云云原生的重点发力领域，跟随客户需求、行业发展、技术发展，为用户提供完整全套的 Serverless 解决方案。