开发者学堂课程【Serverless 技术进阶：serverless 架构借鉴&应用场景】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/995/detail/15012
serverless 架构借鉴&应用场景
第二节，Serverless架构简介和典型应用场景，Serverless架构简介，随着云服务器的发展，计算资源被高度抽象化，从物理机到云服务器。再到容器服务，计算资源逐渐变得更加细腻话。
2012年，Iron.io的副总裁Ken From在文章Why The Future of Software and Apps is Serverless中首次提出了无服务器的概念，并指出即使云计算已经逐渐的兴起，但是大家仍然在围绕着服务器转。
不过，这不会持续太久。云应用正在朝着无服务器。这将队应用程序的创建和分发产生重大影响。
2019年，UC Berkeley发表论文Cloud Programming Simplified: A Berkeley View on Serverless Computing，在文章中，作者犀利断言，新的baas存储服务会被发名，以扩展在Serverless计算上能够运行更加适配的应用程序。这样的存储能够与本地块存储的性能。而且具有临时和持久可供选择。
基于Serverless计算的价格将低于Serverful 计算。至少不会高于Serverful计算。Serverless计算一旦取得技术上的突破，将会导致Serverful服务的下滑。serverless将会成为云时代默认的计算范式，将会取代serverful计算，因此也意味着服务器-客户端模式的终结。Serverless架构从2012年的首次走进大众视野到2019年成为UC Berkeley对云计算领域犀利断言的主角，Serverless架构利用了7年的时间，完成了从一个“新的观点”向“万众瞩目的架构”转身，在这7年之间，Serverless架构从鲜为人知，到被商业化应用，再到头部云厂商纷纷布局Serverless架构作为云计算战略，Serverless架构逐渐的成为了人尽皆知的新的技术范式。当然，在这7年之间，Serverless不仅仅技术架构在逐渐的升级和完善，其概念也是越发的明确，其目标和方向也是逐渐的清晰明朗起来。
关于Serverless的定义，Martin fowler在Serverless architecture一文中认为Serverless实际上是baas与faas的组合。这个简单明了的定义,也逐渐地奠定了Serverless组成结构的基础。
Martin Fowler认为，在Serverless架构中，应用的一部分服务端逻辑依然由开发者完成，但是和传统架构不同，它运行在一个无状态的计算容器中，由事件驱动、生命周期很短（甚至只有一次调用）、完全由第三方管理，这种情况称为Functions as a service/FaaS。
AWS Lambda是目前的热门FaaS实现之一：除此之外，Server1ess架构还要有部分依赖于第三方（云端）应用或服务米管理服务器端逻辑和状态的应用，这些应用通常是富客户端应用（单页应用或者移动端Ap),建立在云服务生态之上，包括数据库(Parse、Firebase)、账号系统(Auth0、AWS Cognito)等，而这些服务最早被称为“(Mobile)Backend as a Service”,即所认为“BaaS”部分。
在同样认为Serverless有faas与baas结合而成的同时，CNCF在对Serverless架构的定义。进行了进一步完善描述。Serverless是指构建和运行不需要服务器管理的应用程序概念。
它描述了一种更细粒度的部署模型，其中将应用程序打包为一个或多个功能，上传到平台，然后执行、扩展和计费，以响应当时确切的需求。
与此同时，在2019年UC Berkeley的文章《Cloud Programming Simplified:A Berkeley View on Serverless Computing》中也同样从Serverless架构特性的角度，对什么是Serverless也进行了补充描述和定义：简单地说，Serverless=FaaS+BaaS,在对于被以为是Serverless的服务，它必须具备弹性伸缩和按量付费的特点：在信通院云原生产业联盟所发布的《云原生发展白皮书(2020年)》中对Serverless的概念也有相关的描述：无服务器（即Serverless)是一种架构理念，其核心思想是将提供服务资源的基础设施抽象成各种服务，以API接口的方式供给用户按需调用，真正做到按需伸缩、按使用收费。
这种架构体系结构消除了对传统的海量持续在线服务器组件的需求，降低了开发和运维的复杂性。降低了运营成本并缩短了业务系统的。交付周期，使得用户能够专注在价值密度更高的业务逻辑的开发商。至此，Serverless架构从结构上、行为上以及特性上的定义就可以总结成下图的形式。
UC Berkeley曾犀利断言“Serverless架构将成为云时代的默认计算范例，主要取代服务器计算，从而为客户端：服务器时代带来封园”，在信通院云原生产业联盟所发布的《云原生发展白皮书：（②020年）》中，也对云原失发展趋势进行了大胆的预测“应用服务Server1ess化，更加聚焦业务的核心价值。
Serverless架构作为云原生技术未来的演进方向，无服务器架构技术
(Serverless)也从观望逐渐落地，据Gartner的过往预测数据显示：到2020年全球将有20%的企业部署无服务器架构，Serverless将进一步释放云计算的能力，将安全、可靠、可伸缩等需求交由基础设施实现，使用户仅需关注业务逻辑而无需关注具体部署和运行，极大地提高应用开发效率。同时这个方式促进了社会分工协作，云厂商可以进一步通过规模化、集约化实现计算成本大幅优化。
由此可见Serverless架构将会成为未来云计算领域中重要的技术架构，将会被更多的业务所采纳，成为其技术选型，那么再进一步的深究，Serverless在什么场景下可以有非常优秀的表现，在什么类型的场景下可能表现得并不是很理想呢？或者有哪些场景更适合Serverless架构呢？
Serverless架构的应用场景通常是由其特性决定方向所支持的触发器决定具体场景。
在sense of Serverless白皮书1.0关于Serverless架构所适合的用户场景包括：
异步发组件，可独立部署和扩展的场景，
发或服务使用量不可预测的场景
短暂无状态的应用，对冷启动时间不敏感的场景
需要快速开发迭代的业务，因为无需提前申请资源，因此可以加快业务上线速度。
CNCF基于Serverless架构的特性给出了四个用户场景之外，还结合常见的触发器提供了详细的例子：
响应罚删除的执行逻辑
对物联网传感器输入消息，如MQTT消息进行分析
处理流处理
管理单词提取、转换和存储需要在短时间内进行大量处理
通过聊天机器人界面提供认知计算
调度短时间内执行的业务，例如CRN或批处理调用
机器学习和人工智能模型。
持续集成管道按需为构建作业提供资源，而不是保持一个构建从主机池等待作业分派的任务。
CNCF Serverless witepaper vl..O站在Serverless架构的特点，从理论上描述了Serverless架构适合的场景或业务，云厂商将会站在自身的业务角度，整体来描述Serverless架构的典型场景。
通常情况下，对象存储为触发器在Servrless架构的典型应用场景包括视频处理、数据ETL处理等：API网关更多会为用户赋能对外的访问链接以及相关联的功能等，当以API网关作为Serverless相关产品的触发器时，常见的应用场景就是后端服务，包括App的后端服务，网站的后端服务甚至是微信小程序等相关产品的后端服务，同时像二些智能音箱也会开放相关的接付，这个接口也是可以通过API网关出发云函数，获得相应的服务等：除了对象存储触发以及API网关触发，常见的触发器还有消息队列触发器，Kafka触发器，日志触发器等。下面对几种场景进行详细介绍。一、WEB应用移动应用后端Serverless架构和云厂商所提供的其他云产品进行结合。开发者能够构建可弹性扩展的移动或web应用程序。轻松创建丰富的无福气后端，而且这些程序可在多个数据中心高可用运行，无需在可扩展、备份、冗余方面执行任何管理工作例如web应用处理示例。
临时文件、数据处理、视频应用、社交应用的场景下，用户上传的图片、音视频往往总量大、频率高，对处理系统的实时性和并发能力都有较高的要求。例如，对于用户上传的图片，可以使用多个函数对其分别处理，包括图片的压缩、格式转换、剑皇监控等，以满足不同场景下的需求。例如：
通过Serverless架构所支持的丰富的事件源，通过实践处罚机制，可以通过几行代码和简单的配置，对数据进行实时处理，例如对对象存储压缩包进行解压、对日志或数据库中的数据进行清洗、对MNS消息进行自定义消费等。
离线数据处理通常要对大数据进行处理护理需要搭建hadoop或spark等相关大数据的框架，同时要有一个处理数据的集群，通过搜索技术，只需要将获得到的数据。并且通过对象存储相关处罚。或任务的拆分。然后再调用相关处理函数处理完成之后存储到云数据库中。例如：某证券公司每12小时统计一次该时段的交易情况并整理出该时段交易量t0即5：每天处理一遍秒杀网站的交易流日志获取因售罄而导致的错误从而分析商品热度和趋势等。
函数计算近乎无限扩容的能力可以使用户轻松地进行大容量数据的计算。利用Serverless架构可以对源数据并发执行多个mapper和reducer函数，在短时间内完成工作；相比传统的工作方式，使用Serverless架构更能避免资源的闲置浪费从而节省成本，整个流程可以简化为：
人工智能领域在AI模型完成训练后，对外提供推理服务时，可以使用Serverless架构，通过将数据模型包装在调用函数中，在实际用户请求到达时在运行代码。相对于传统的推理预测，这样做的好处是，无论是函数模块还是后端的GPU服务器。以及对接的其他相关的机器学习服务。服务都是可以进行按量付费以及自动伸缩，从而保证性能的。也确保服务的稳定:
IOT等物联网领域，目前很多厂商都在推出自己的智能音箱产品，用户可以对智能音箱说出一句话，智能音箱可以通过互联网将这句话传递给后端服务，然后获得到反馈结果。再返回给客户.
通过Serverless架构可以将API、网关、云函数以及数据库产品进行结合来替代传统的服务器或者虚拟机等。通过这样的一个架构，一方面可以确保资源的按量付费，只有在使用的时候，函数部分才会计费。
另一方面，当用户量增加之后，通过Serverless实现了智能音箱系统的后端也会进行弹性伸缩，可以保证用户侧的服务稳定，当要对其中某个功能进行维护，相当于对单个函数进行维护。并不会对主流程产生额外风险，相对来说会更加安全稳定的。
监控与自动化运维，在实际生产中，通常需要做一些监控脚本来监控网站服务或者API服务是否健康，包括是否可用响应速度等。传统的方法是通过一些网站监控平台，例如DNSpod监控、360网站服务监控以及阿里云监控等来进行监控告警服务。这些监控平台的原理是通过用户自己设置要监控的网址和预期的时间阈值，由监控平台部署在各地区的服务器，定期发起请求，对网站和服务的可用性进行判断。
当然这些服务很多都是大众化的，虽然说通用性很强，但是实际上并不一定适合。例如现在需要监控某网站的状态码，不同区域的岩石，并且设置一个延时阈值，当网站状态异常或者延时过大时，通过邮件等进行通知告警。针对这样一个定制化需求，目前来说大部分的监控平台。男直接实现，所以定制一个网站状态监控工具就显得尤为重要。除此之外，在实际的生产运维中，还非常有必要对所使用的云服务进行监控和告警，例如，在使用hadoop spark的时候要对节点的健康进行监控在使用K8S的时候，要对API Serverless etcd等多维度的指标进行监控，在使用卡夫卡的时候也要对数据积压量以及topic、Consumer等指标进行监控。这些服务的监控，往往不能通过简单的URL以及某些状态来进行判断。在传统的运维中，通常会在额外的机器上设置一个定时任务，对相关的服务进行旁路监控。
Serverless架构的一个很重要应用场景就是运维监控，警告与定时触发器进行结合使用，可以非常简单地实现某些资源健康状态监控与感知，并进行一些告警功能建设、自动化运维能力建设：
