1、先对serveless的基本定义做了个介绍。 2、重点对AI，如TensorFlow的实践，做了详细的实验方法。 3、对基于CICD的实践集成做了介绍， 4、特别的不适用的场景做了描述，比如对定时任务的触发器，一定要通过FaaS平台的定时触发器触发

关注下

好东西

哦

学习了

哦

哦

哦

哦

　Serverless 支持函数应用开发，框架应用开发以及 SaaS 应用开发，要开发 Serverless 应用除了相关的代码外，仅需要额外配置一个 serverless 配置文件，就可以将代码部署为 serverless 应用。Serverless 应用的整个开发生命周期都需要使用 Serverless CLI 完成，详见 Serverless CLI 安装说明 以及 Serverless CLI 命令 Serverless从物理机或虚拟机的使用上进行了分离，更关注上层业务的运行情况。Serverless架构包含两块：函数即服务和后端即服务。函数即服务提供的是计算能力。原有的计算能力，无论是容器也好，虚拟机也好都承载在一定的操作系统之上，函数即服务把计算能力进行了进一步抽象，我们在后文再继续进行展开。另外，Serverless还有后端即服务，比如对象存储，数据库应用，缓存服务，我们也可以称之为Serverless，因为这些服务也能够在云上提供开通即服务，开通即使用的能力。在使用这些产品时同样不需要关注它的服务器是什么样的，它的服务器部署在哪里，而是服务开通就可以使用了，后面的运维工作都交给了云，所以不用感知它的最底层服务器，因此我们也可以把它称之为Serverless。这种服务就称之为Serverless后端即服务。这两个合起来可以称为Serverless架构。

哦

读完这本书，回顾历史，历史上第一个 Serverless 平台可以追溯到 2006 年的 Zimki（该公司已倒闭）， 这个平台提供服务端 JavaScript 应用，虽然他们没有使用Serverless 这个名词，但是他们是第一个“按照实际调用付费”的平台。 而真正第一个使用 Serverless 名词的是 iron.io。不过，Serverless 真正流行起来还的是 2014 年亚马逊推出的 AWS Lambda，然后其他公司也陆续跟进， 比较出名的有2016 年推出 Google Cloud 与 IBM 等厂商。而国内的要属阿里云起步最早，也最成功。阿里云在这方面取的了不错的成绩， 了解到了 Serverless 架构工具链 Serverless Devs 相关的基础知识，阿里云的这本电子书让我真正意义上理解Serverless Devs的重要价值。

读完Serverless 开发速查手册这本书后，理解了什么是Serverless，我觉得Serverless 仍然处于探索和发展阶段，并且对于Serverless也没有一个权威的定义， 我认为Serverless代表的是一种服务理念或模式。这种服务理念希望用户无需关注除了业务逻辑本身之外的主机管理、服务运维、配置等事务， 不需要关注运营维护问题。也即是说，只要有了Serverless，几乎可以不需要再考虑Devops工作流。 - Serverless是一种软件系统架构方法， 并不代表某种技术。通常我们称Serverless 为一种架构而不是某种技术框架。 - Serverless是一种云服务产品形态。通常我们称Serverless为一种产品， 阿里云推出的各种 Serverless 服务或能力、封装的 API 网关等产品。这本书算是一个可以给大家参考的最佳实践吧，我们一起来学习吧！！

读完这本170页的<<Serverless 开发速查手册>>，在阿里云的生态中 最常见的 Serverless 实现方案为 FaaS（函数即服务） + BaaS（后端即服务），我们经常听到的「云服务」就是基于 FaaS + BaaS 架构。 目前给感悟最深的在阿里云生态中现在Serverless Devs 应运而生，在 Serverless 架构持续赋能传统应用整体效能提升的同时， Serverless Devs 提供了 Serverless 应用全生命周期管理工具，为Serverless 应用综合效能的提升，让我们开发人员效率更高。这本电子书通过简单明了的语言， 真实的案例，以及开放的源代码，让我了解到了 Serverless 架构工具链 Serverless Devs 相关的基础知识，通过本书真正意义上理解Serverless Devs的重要价值。

本书作者刘宇是国防科技大学电子信息专业博士，阿里云 Serverless 产品经理，开源项目ServerlessDevs 发起人。从这几个头衔可以看出作者很厉害。要读懂理解这本书是有一定的门槛的。所以作者建议读3遍，逐步去的学习理解这本书所讲的知识内容。当然，底子好的同学应该接收能力强。这本书通过循序渐进的方法，介绍了云计算的发展历史，什么是 Serverless 架构，Serverless 架构下的工具链体系的重要性，然后讲解了通过快速上手案例，不同领域的实战案例，以及对 Serverless Devs 的开发者模型等几个部分。虽然这本书我还没读完一遍但是已经能从书中感受到作者专业领域的高度和著书的严谨态度。各位小伙伴如果有时间有这方面专业知识的需求不妨多读几遍来学习巩固拔高自己的专业素养。

学习学习

cd

q

学习下

继续读书

如果你是爱学习的同学请免费点个赞支持下

一 能学到啥？

首先基础打牢，譬如Serverless Devs这个咋个用性质又如何？这种工具已在哪些领域有落地案例了啊？还有它架构是什么样？等等描述也很全面而具体。

如果你会Node.js或者Python语言，了解过云计算

我相信你很快就能上手

下面我就带着同学提炼下重点

二 还是基础

啥叫Serverless啊？说白点吧，它是一种构建和运行不要服务器来管的应用程序。是根据以前FaaS+BaaS总结出来的更细粒度的部署方式，过程是把应用打包为一个或多个功能，然后上传到平台执行、 扩展和计费，以响应当时确切的需求就是这么个过程。那你可能要问了特点是啥啊？

两个哈，弹性伸缩与按量付费，简单说对传统单点大规模服务器进一步抽象出来，就像你家里面自来水用一点交一点水费啊就这个意思。好处是运营成本与周期大幅下降的哈，一图胜千言

现在定义搞清楚，我们再来认识下Serverless Devs

是啥？

就是一个部署和管理应用的容易扩展开源平台。这下明白了吧！

看下图每个角色不一样的哈

再来看个给它用的“插件”-函数计算

它们俩是啥关系啊？

• Serverless Devs就是同学们小时候玩的红白机耍魂斗罗，而fc组件，oss组件，nas组件等就是一张游戏卡，游戏 机本身不具备啥功能，根据插入的游戏卡实现不同的功能； 
• 情不自禁让我想起VSCode工具，本身不具备太多的能力，但是可以安装不同的插件，来丰富 VSCode 的能力，而这些插件对应到 Serverless Devs 生态中，就是不同的 组件，例如 FC 组件，nas 组件，oss 组件。

FC组件可参与到项目的创建、开发、调试、部署与运维的全流程中，还是一图胜千言啊 （FC）组件已经支持的能力包括这些

如何安装这个自己去看文档，哪里详细

要有这个yaml格式如果是前端同学肯定会我也不说了

如果你不会命令行你总敲得来嘛？格式是啥呢？必须是 s cli 组件名 方法 参数的这种格式，具体场景拿去看书哈。只不过提醒你命令行用的少还是yaml文件方便

两种方式对比下，就没有伤害

还有不同项目场景你自己跟着文档做

下面要说一个很重要的如果保证业务更新它的一致性啊？

这是非常重要的

所谓的一致性指的是：通过工具在本地进行项目部署，此时再有其他人通过其他途径（例 如控制台等），对项目进行过更新等操作，此时再在本地进行项目部署，是不是会直接覆盖？

好吧你听不懂

例如，当用户 A 在本地更新了业务，因为一些特殊情况，导致出现了一个线上异常 x，此时用户 B 重新更新，将这个内容修复了，但是 B 没有及时同步给 A 这个事情，A 又更新了新的功能， 直接覆盖了 B 的内容，这个时候之前的异常 x 又出现了，如果此时在 A 更新的时候，可以感知 到线上资源已经变动，那么这种事情就不会再次发生。

学Java并发或者Mysql事务简直是直呼内行

FC组件，已经支持了线上“异动”的感知能力，包括 了以下几个情况 如果线上出现了，咋个做去看文档咋个做

三 要对性能心中有数

stress 命令的原理是通过创建辅助函数，对目标函数进行压测，如图啊 在 Serverless 领域内，通常会出现以下两种使用场景：  - CPU 密集型场景 对于 CPU 密集型场景，例如音视频处理、AI 推理或图片处理等，您一般会选择使用单实例 单并发。由于该类场景的函数内存大小和 CPU 能力成正比，因此您需要根据函数是成本敏 感型还是延迟敏感型选择合适的内存规格。 

• I/O 密集型场景 对于 I/O 密集型场景，您一般会选择使用单实例多并发。该类场景下由于函数内存和 CPU 能力成正比，建议您将函数内存规格设置足够大，但可能会出现浪费资源的现象，很难选择 合适的单实例并发值。

针对在以上两种使用场景无法设置合适的参数规格的情况，Serverless Devs 为您提供了探测功 能，可以实现内存探测和并发度探测，获取满足您需求的参数配置信息。eval 命令是对函数进 行探测的命令；通过 eval 指令，可以对函数探测内存(单实例单并发)或者探测并发度(单实例多 并发)。例如给 CPU 密集型场景的函数设置合适的内存，给 I/O 密集型场景的函数设置合适的 并发值，根据探测结果，获取满足需求的最佳内存大小或最佳并发度值。

四 下面说个AI的案例

• 部署前准备 在本地完成 ImageAI 的基本测试运行之后，可以将项目部署到 Serverless 架构上。在 Serverless 架构上，该项目的运行流程基本是： 按照以上流程，以阿里云函数计算和轻量级 Python Web 框架 Bottle 为例，可以分别实现页面 代码以及逻辑代码。其中逻辑代码主要是将上文在本地开发的案例进行稍作修改，与 Bottle 框 架进行结合。

后面具体代码，上线与测试

自己看书学下

五 和CI/CD平台或工具集成

CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概 念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案，CI/CD 主要 针对在集成新代码时所引发的问题。具体而言，CI/CD 可让持续自动化和持续监控贯穿于应用 的整个生命周期（从集成和测试阶段，到交付和部署）。这些关联的事务通常被统称为“CI/CD 管道”，由开发和运维团队以敏捷方式协同支持。 在 Serverless 架构下，通常会有很多函数构成一个完整的功能或者服务，Serverless 架构下， 这种比较细粒度的功能开发往往会给后期的项目维护带来了极大的不便，包括不限于函数管理 的不便、项目的构建、发布层面的不便等。此时在 Serverless 架构中，CI/CD 就显得尤为重要。 更加科学、安全的持续集成和部署过程，不仅仅会让整体的业务流程更加规范，也会在一定程 度上，降低人为操作，手工集成部署所产生错误的概率，同时也会大规模降低运维人员的工作 负担。 如果想要通过 CI/CD 平台或者工具，科学且方便的进行 Serverless 应用的持续集成与交付部署， 那么通常情况下是需要借助相对应的开发者工具，例如著名的开源项目 Se r ve rl e s s Framework，Serverless Devs 等。整体的流程通常是：

还有它兼容Github Actions这个持续集成工具，我自己也用的非常多自己看下

六 关于Serverless的一点经验

1 那如何上传文件

• 一般情况下，一些云平台的 API 网关触发器会将二进制文件转换成字符串；不便直接获取和 存储；
• 一般情况下，API 网关与 FaaS 平台之间传递的数据包有大小限制，很多平台被限制在 6M； 
• FaaS 平台大都是无状态的，即使存储到当前实例中，也会随着实例释放而导致文件丢失；

所以，传统框架中常用的上传方案是不太适合在 Serverless 架构中直接使用的，在 Serverless 架构上传文件的方法通常有两种：  - 一种是 BASE64 后上传，持久化到对象存储或者是 NAS 中，这种做法可能会触及到 API 网关 与 FaaS 平台之间传递的数据包有大小限制，所以一般使用这种上传方法的通常是上传头像 等小文件的业务场景； 5. Serverless 应用开发经验/常见思路 < 134  - 第二种上传方法是通过对象存储等平台来上传，因为客户端直接通过密钥等信息来将文件直 传到对象存储是有一定风险的，所以通常情况是客户端发起上传请求，函数计算根据请求内 容进行预签名操作，并将预签名地址返回给客户端，客户端再使用指定的方法进行上传，上 传完成之后，可以通过对象存储触发器等来对上传结果进行更新等：

2 慎用部分Web框架特性哦

函数计算是请求级别的隔离，所以可以认为这个请求结束了，实例就有可能进入到一个“静默” 的状态了，而在函数计算中，API 网关触发器通常是同步调用（以阿里云函数计算为例，通常只 在定时触发器、OSS 事件触发器、MNS 主题触发器和 IoT 触发器等几种情况下是异步触发）， 这就意味着当 API 网关将结果返回给客户端的时候，整个函数就会进入“静默”状态，或者被 销毁，而不是会继续执行完异步方法，所以通常情况下像 Tornado 等框架就很难在 Serverless 架构下发挥其异步的作用。当然，如果使用者需要异步能力，可以参考云厂商所提供异步方法， 以阿里云函数计算为例，阿里云函数计算为用户提供了一种异步调用能力，当函数的异步调用 被触发后，函数计算会将触发事件放入内部队列中，并返回请求 ID，而具体的调用情况及函数 执行状态将不会返回。如果用户希望获得异步调用的结果，则可以通过配置异步调用目标来完成；

3 用工具快速迁移/部署

如果通过开发者工具进行传统框架的支持，可以直接通过 Serverless Devs 的命令，进行案例的 项目的创建。目前 Serverless Devs 已经支持下面框架

4 能端云联调

指的是在本地进行 Serverless 应用开发时，往往会涉及到一些线上资源，例如 通过对象存储触发器触发函数执行，通过 VPC 访问数据库等，此时由于线上线下环境的不一致 性，会让线下的开发、调试面临极大的挑战。Serverless Devs 团队通过搭建 Proxy 辅助函数的 方法，将线上线下资源打通，可以快速帮助开发者在本地进行函数的开发与调试。

端云联调可以通过三个非常简单的步骤快速实现： - 步骤1: 在已有的项目下，创建端云联调的辅助资源，开启端云联调模式：s proxied setup；  - 步骤2: 在完成端云联调模式开启动作之后，通过 s proxied invoke 或者线上的事件进行函 数的触发，调试； - 步骤3: 完成端云联调之后，通过 s proxied clean 命令，对对因端云联调而产生的辅助资源 进行清理；

写笔记也不容易，那请你一个小小的赞吧，感谢你哦！