共计 3202 个字符，预计需要花费 9 分钟才能阅读完成。
作者：Serverless
Serverless 架构将成为将来云计算畛域重要的技术架构，将会被更多的业务所驳回。进一步深究，Serverless 架构在什么场景下有优良的体现，在什么场景下可能体现得并不是很现实呢？或者说，有哪些场景更适宜 Serverless 架构呢？
Serverless 架构的利用场景
Serverless 架构的利用场景通常是由其个性决定的，所反对的触发器决定具体场景。如图 1-1 所示，CNCF Serverless Whitepaper v1.0 形容的对于 Serverless 架构所适宜的用户场景如下。
- 异步并发，组件可独立部署和扩大的场景。
- 突发或服务使用量不可预测的场景。
- 短暂、无状态的利用，对冷启动工夫不敏感的场景。
- 须要疾速开发、迭代的业务。
1-1 CNCF Serverless Whitepaper v1.0 形容的 Serverless 架构所适宜的用户场景
CNCF 除基于 Serverless 架构的个性给出 4 个实用的用户场景之外，还联合常见的触发器提供了具体的例子。
- 响应数据库更改（插入、更新、触发、删除）的执行逻辑。
- 对物联网传感器输出音讯（如 MQTT 音讯）进行剖析。
- 执行流解决（剖析或批改动态数据）。
- 数据单次提取、转换和存储须要在短时间内进行大量解决（ETL）。
- 通过聊天机器人界面提供认知计算（异步）。
- 调度短时间内执行的工作，例如 CRON 或批处理的调用。
- 机器学习和人工智能模型。
- 继续集成管道，按需为构建作业提供资源。
CNCF Serverless Whitepaper v1.0 基于 Serverless 架构的特点，从实践上形容了 Serverless 架构适宜的场景或业务。云厂商则站在本身业务角度来形容 Serverless 架构的典型利用场景。
通常状况下，当对象存储作为 Serverless 相干产品触发器时，典型的利用场景包含视频解决、数据 ETL 解决等；API 网关更多会为用户赋能对外的拜访链接以及相关联的性能等，当 API 网关作为 Serverless 相干产品的触发器时，典型的利用场景就是后端服务，包含 App 后端服务、网站后端服务甚至微信小程序等相干产品的后端服务。
一些智能音箱也会凋谢相干接口，这个接口也能够通过 API 网关触发云函数，取得相应的服务等；除了对象存储触发以及 API 网关触发，常见的触发器还有音讯队列触发器、Kafka 触发器、日志触发器等。
Web 利用或挪动利用后端
如果 Serverless 架构和云厂商所提供的其余云产品联合，开发者可能构建可弹性扩大的挪动利用或 Web 应用程序，轻松创立丰盛的无服务器后端。而且这些程序在多个数据中心可用。图 1-2 所示为 Web 利用后端解决示例。
1-2 Web 利用后端解决示例
实时文件 / 数据处理
在视频利用、社交利用等场景下，用户上传的图片、音视频往往总量大、频率高，对解决零碎的实时性和并发能力都有较高要求。此时，对于用户上传的图片，咱们能够应用多个函数对其别离解决，包含图片的压缩、格局转换等，以满足不同场景下的需要。图 1-3 所示为实时文件解决示例。
1-3 实时文件解决示例
咱们能够通过 Serverless 架构所反对的丰盛的事件源、事件触发机制、代码和简略的配置对数据进行实时处理，例如：对对象存储压缩包进行解压、对日志或数据库中的数据进行荡涤、对 MNS 音讯进行自定义生产等。图 1-4 所示为实时数据处理示例。
1-4 实时数据处理示例
离线数据处理
通常，要对大数据进行解决，咱们须要搭建 Hadoop 或者 Spark 等相干的大数据框架，同时要有一个解决数据的集群。但通过 Serverless 技术，咱们只须要将取得到的数据一直存储到对象存储，并且通过对象存储配置的相干触发器触发数据拆分函数进行相干数据或者工作的拆分，而后再调用相干处理函数，之后存储到云数据库中。
例如：某证券公司每 12 小时统计一次该时段的交易状况并整顿出该时段交易量 top5；每天解决一遍秒杀网站的交易流日志获取因售罄而产生的谬误，以便精确剖析商品热度和趋势等。函数计算近乎有限扩容的能力能够使用户轻松地进行大容量数据的计算。
利用 Serverless 架构能够对源数据并发执行 mapper 和 reducer 函数，在短时间内实现工作。相比传统的工作形式，应用 Serverless 架构更能防止资源的闲置，从而节省成本。
数据 ETC 解决流程能够简化为图 1-5。
1-5 数据 ETL 解决示例
人工智能畛域
在 AI 模型实现训练，对外提供推理服务时，基于 Serverless 架构，将数据模型包装在调用函数中，在理论用户的申请达到时再运行代码。
绝对于传统的推理预测，这样做的益处是无论是函数模块还是后端的 GPU 服务器，以及对接的其余相干机器学习服务，都能够进行按量付费以及主动伸缩，从而在保障性能的同时确保服务的稳固。图 1-6 为机器学习（AI 推理预测）解决示例。
1-6 机器学习（AI 推理预测）解决示例
物联网（IoT）畛域
目前，很多厂商都在推出本人的智能音箱产品—用户对智能音箱说一句话，智能音箱通过互联网将这句话传递给后端服务，而后失去反馈后果，再返给用户。通过 Serverless 架构，厂商能够将 API 网关、云函数以及数据库产品联合起来，以代替传统的服务器或者虚拟机等。
Serverless 架构一方面能够确保资源能按量付费，即用户只有在应用的时候，函数局部才会计费；另一方面当用户量减少时，通过 Serverless 架构实现的智能音箱零碎的后端也会进行弹性伸缩，保障用户侧的服务稳固，且对其中某个性能的保护相当于对单个函数的保护，并不会给主流程带来额定危险，相对来说会更加平安、稳固等。图 1-7 为 IoT 后端解决示例。
图 1 -7 IoT 后端解决示例
监控与自动化运维
在理论生产中，咱们常常须要做一些监控脚本来监控网站服务或者 API 服务是否衰弱，包含是否可用、响应速度等。传统的办法是通过一些网站监控平台（例如 DNSPod 监控、360 网站服务监控，以及阿里云监控等）进行监控和告警。
这些监控平台的原理是用户本人设置要监控的网站和预期的工夫阈值，由监控平台部署在各地区的服务器定期发动申请，进而判断网站或服务的可用性。当然，这些服务器尽管说通用性很强，但实际上并不一定适宜。
例如，当初须要监控某网站状态码和不同区域的延时，同时设置一个延时阈值，当网站状态异样或者延时过大时，平台通过邮件等进行告诉和告警。目前，针对这样一个定制化需要，大部分监控平台很难间接实现，所以开发一个网站状态监控工具就显得尤为重要。
除此之外，在理论生产运维中，对所应用的云服务进行监控和告警也十分有必要。例如：在应用 Hadoop、Spark 时要对节点的衰弱进行监控；在应用 Kubernetes 时要对 API Server、ETCD 等的指标进行监控；在应用 Kafka 时要对数据积压量，以及 Topic、Consumer 等的指标进行监控。
对于这些服务的监控，咱们往往不能通过简略的 URL 以及某些状态进行判断。在传统的运维中，咱们通常会在额定的机器上设置一个定时工作，以对相干服务进行旁路监控。
Serverless 架构的一个很重要的利用场景就是运维、监控与告警，即通过与定时触发器联合应用，实现对某些资源衰弱状态的监控与感知。图 1-8 为网站监控告警示例。
1-8 网站监控告警示例
新书举荐
阿里云、蚂蚁团体的 4 位专家刘宇、田初东、卢萌凯、王仁达（排名不分先后）零碎梳理阿里在 Serverless 架构下的 AI 教训，联袂推出新书 《Serverless 架构下的 AI 利用开发：入门、实战与性能优化》。
本书是对于 Serverless 架构下机器学习实战的技术书，咱们心愿通过简单明了的语言、实在的案例，以及凋谢的源代码，为读者介绍 Serverless 架构与机器学习相干的基础知识，帮忙读者在 Serverless 架构下开发、上线机器学习我的项目。
新书将在收费在 Serverless 公众号连载，欢送大家订阅关注
