什么是Serverless
目前，开发人员使用OpenStack或Kubernetes进行业务开发时，仍然需要关心很多和虚机、容器相关的后端工作，如应用的负载均衡，虚机的存储和计算资源，横向/纵向的扩展能力，甚至容灾稳定性等非专业逻辑的开发。这些后端的运维和开发知识降低了开发者的开发效率。
如果云平台能自动解决上述问题，让开发者只专注于业务逻辑，云平台负责应用的部署和运行，这样是否可以提升开发效率和产品质量？这种不用关心后端如何支撑服务运行而只需要实现服务本身的理念，称之为Serverless。
Serverless有一个更具有描述性的名字是FaaS(Function as a service)，就像IaaS、PaaS、SaaS一样，FaaS是云计算的一种。通过FaaS，用户为应用的某一特定功能购买必要的功能。
Serverless也可以指一部分服务逻辑由应用实现，但跟传统架构不同在于，他们运行于无状态的容器中，可以由事件触发、生命周期短暂、完全被云平台管理。这种思路是Functions as a Service / FaaS。用户通过云平台可以运行自定义的代码（函数），函数是无服务器架构中抽象语言运行时的最小单位。
Serverless的使用场景
Serverless架构主要分为以下特点
实现了细粒度的计算资源分配
不需要预先分配资源
具备真正意义上的高度扩容和弹性
按需使用，按需计费
根据Serverless的这些通用特点，归纳出下面几种典型使用场景，供大家参考
-
低频请求
在物联网行业中，由于物联网设备传输数据量小，且往往是固定时间间隔进行数据传输，因此经常涉及低频请求场景。
例如：物联网应用程序每分钟仅运行一次，每次运行50ms，这意味着CPU的使用率为0.1%/小时，这也意味着其实有1000个相同的应用可以共享计算资源。而Serverless架构下，用户可以购买每分钟100ms的资源来满足计算需求，通过这种方式就能够有效解决效率问题，降低使用成本。
-
定制事件
例如用户注册时发邮件验证邮箱地址，通过定制的事件来触发后续的注册流程，而无需再配置额外的应用来处理后续的请求。
-
固定时间触发
事件触发固定时间触发，例如在夜间或者服务空闲时间来处理繁忙时候的交易数据，或者运行批量数据，来生成数据报表，通过Serverless方式，不用再额外购买利用率并不高的处理资源。
-
流量突发型事件
移动互联网应用经常会面对突发流量场景。例如：移动应用的通常流量情况是QPS 20，但每隔5分钟会有一个持续10s的QPS 200流量（10倍于通常流量）。在Serverless架构下，开发人员可以利用弹性扩展特性，快速构建新的计算能力来满足当前需求，当业务高峰后，资源能够自动释放，有效节省成本。
使用案例（新浪微博 × 阿里云）
用户需求
微博客户端上显示多种格式的图片，为了适配不同的手机屏幕和操作系统，需要对图片进行个性化 的处理。微博有海量用户，系统每日要能处理海量的调用请求，并保持稳定的延时。
解决方案
微博将用户上传的图片存储到阿里云对象存储中，在函数中实现个性化的图片处理逻辑。手机客户端 获取图片时，通过阿里云 CDN 服务回源到函数计算，函数从阿里云对象存储中下载原图，实时处理后将结果图片返回。
使用效果
开发人员只需要专注于图片处理逻辑的开发，工程效率大幅提高。函数计算自动实时扩容底层计算资源，确保应用在负载动态变化时仍能保持稳定的延时，平滑处理海量的调用请求。使得微博不再为峰值负载预留计算资源，降低了成本。
Serverless的实施
OpenStack中的Serverless方案
OpenStack中发起了新的项目，名字叫做 Qinling （ 灵感来自于中国的秦岭山脉 ），目标就是在 OpenStack 平台上提供 Function as a Service 的功能。
Qinling利用OpenStack中已有的组件来支撑用户自定的Function运行。OpenStack提供丰富的IaaS层资源以及用户验证（ Keystone ），事件监控（ Adoh ），负载均衡等功能。用户自定义Function可以灵活地利用这些资源和服务达到效果。
目前Qinling支持的功能比较简单，对应的实现也比较简单：
- 用户通过代码的方式定义Function的行为。
- 通过Qinling的CLI，指定代码文件创建Function。
- Qinling收到请求之后， 获取用户指定的代码文件，生成Docker image，通过Container COE以容器的方式运行用户定义的Function，执行结束回收这个容器。
最后，值得注意的是，目前Qinling只支持OpenStack Rocky以上版本
