Serverless 开发速查手册.pdf

前言随着云计算的不断发展，Serverless 架构逐渐成为了近些年来备受关注的焦点，作为被认为将会引领云计算下一个十年的技术架构，Serverless 架构一方面继承云计算优点的同时，另一方面也为业务带来了极致弹性、按量付费、低运维等优势；在 Serverless 架构逐渐成为诸多业务的技术选型之时，其也暴露出了包括调试困难，厂商锁定严重，资源琐碎管理难度大等在内一些列的问题，Serverless Devs 作为开源建设的 Serverless 工具链生态，一方面从开源开放的角度出发，为开发者们提供更安全、可靠、自主的工具；另一方面也通过 Serverless 应用全生命周期角度出发，为开发者提供一款可以“像玩手机一样玩转 Serverless 架构”的应用生态。为什么写作本书随着时间的发展，Serverless 架构在最近几年变得越发的火热，其凭借着极致弹性、按量付费、低运维等特性，在很多领域发挥着越来越重要的作用；而伴随着 Serverless 架构越发火热，Serverless 架构在工具链层面的匮乏逐渐显露；以提高研发效能为核心优势之一的 Serverless架构，因为没有完善的工具链体系，导致开发困难、调试困难、管理困难、运维困难；此时Serverless Devs 应运而生，在 Serverless 架构持续赋能传统应用整体效能提升的同时，Serverless Devs 提供了 Serverless 应用全生命周期管理工具，助力 Serverless 应用综合效能的提升，让应用开发效率更上一层楼。本书希望通过更简单明了的语言，真实的案例，以及开放的源代码，为读者介绍 Serverless 架构工具链 Serverless Devs 相关的基础知识，希望读者可以通过本书真正意义上理解Serverless Devs的重要价值，以及可以顺利在Serverless架构下开发，并上线 Serverless 应用项目，更加直接地获得云计算带来的时代技术红利。关于本书作者刘宇：国防科技大学电子信息专业博士；阿里云 Serverless 产品经理，开源项目 ServerlessDevs 发起人；Serverless 架构：从原理、设计到项目实战、Serverless 工程实践：从入门到进阶、架构师特刊：人人都能学会的 Serverless 实践等热门图书作者；阿里云麒麟布道师。本书主要内容本书是一本关于 Serverless 开发者工具助力 Serverless 应用研发效能提升的书，本书一共有 5个章节，通过这 5 个章节读者可以从 Serverless 架构以及 Serverless Devs 开发者工具的基础入门，通过快速入门案例，在 AI 领域下的应用，在 CI/CD 中的实战案例，等多个维度进行学习和了解 Serverless Devs 开发者工具。第一章：介绍什么是 Serverless 以及 Serverless Devs，并且为读者分享 Serverless 工具链的必然性和重要性；第二章：帮助读者快速入门 Serverless 以及 Serverless Devs 开发者工具；包括不限于工具的下载，部署，调试，以及相关规范等内容；第三章：通过一些常见的，有趣的 AI 案例，帮助读者可以更为深入的学习和了解 ServerlessDevs 开发者工具；第四章：通过在 CI/CD 工具/平台下的实战，为读者介绍 Serverless Devs 的集成性与被集成性；第五章节：是 Serverless 应用的开发经验和常见的应用思路，包括传统框架的迁移案例，应用调试调优的方法等；如何阅读本书在阅读此书前，读者应当具有一定的编程技术，例如掌握 Node.js、Python 等语言的编程能力或具备这方面的知识，同时也需要对云计算有初步的了解，有使用过阿里云的经验，另外也需要读者对 Serverless 架构相关的基础有一定的了解。这本书将会通过循序渐进的方法，从云计算的发展历史，什么是 Serverless 架构，Serverless 架构下的工具链体系重要性说起，通过快速上手案例，不同领域的实战案例，以及对 Serverless Devs 的开发者模型的介绍等几个部分为读者介绍 Serverless Devs 助力 Serverless 架构带来的研发效能变革，我建议读者分几遍阅读本书。第一遍先将书通读，主要弄清楚概念，再完成 Serverless Devs 的基础入门，并对基于Serverless Devs 哲学思想，使用流程等有一个较为基础的了解；第二遍通过对本书在不同领域的实践案例，进行进一步的学习和探索，了解 ServerlessDevs 如何助力 Serverless 架构在不同行业的发力，助力业务综合效能的提升；第三遍可以针对本书的开发经验分享等部分，对 Serverless 架构有更为深入的了解，帮助开发者可以更好的了解 Serverless 架构，上手 Serverless 应用开发；阅读是一个反复又枯燥的过程，读者只有在反复的研读中，才能使自己在 Serverless 架构的学习不断深入，通过 Serverless Devs 工具链的加持，实现更多的应用案例，本书的案例代码可能会存在失效的情况，但是笔者会尽快在每个案例的代码仓库中更新代码，希望读者可以切实利用好每个案例提供的仓库地址，帮助自己更加高效的了解、学习 Serverless 架构下如何更简单、更方便、更科学地开发、部署、运维机器学习项目。致谢本书是一本 Serverless 工具链相关的书籍，在进行本书编写的时候，曾遇到过很多的困难，在此特别感谢阿里云云原生团队给予的大力支持。感谢杨秋弟（曼红）、杨浩然（不瞋）等前辈，是你们在这本书从开始到结束的过程中，不断给予鼓励和支持，才得以让本书在预期的时间内顺利完成；感谢阿里云云原生开发者运营姜曦（筱姜），在本书对外宣传过程中给予的帮助和支持；感谢、罗松（西流）、张千风（千风）等人在本书编写过程中，指导部分代码的完成，功能、案例的实现。同时，也要感谢我的家人对我工作的鼓励和支持，对我每走一步的信任和鼓舞；感谢身边的小伙伴，对我的关心和帮助；感谢身边每一个人，谢谢你们。由于作者水平有限，书中不足及错误之处在所难免，敬请专家和读者给予批评指正。江昱（刘宇）2022 年 2 月目录前言3为什么写作本书3关于本书作者3本书主要内容4如何阅读本书4致谢51.引言101.1 从云计算到 Serverless101.2 Serverless 架构简介181.3 Serverless 架构应用场景211.3.1 Web 应用/移动应用后端221.3.2 实时文件/数据处理231.3.3 离线数据处理241.3.4 人工智能领域241.3.5 IoT 等物联网领域251.3.6 监控与自动化运维251.4 Serverless Devs 简介271.4.1 工具链建设的必要性271.4.2 六大优势281.4.5 设计哲学291.5 阿里云函数计算（FC）组件简介331.5.1 Serverless Devs 和 FC 组件的关系331.5.2 五大亮点341.5.3 功能支持342.快速入门与功能案例362.1 Serverless Devs 基础入门362.1.1 工具安装362.1.2 密钥配置362.1.3 Yaml 的使用规范422.1.4 多种操作模式下的工具体系512.2 案例与体验552.2.1 项目上手体验552.2.2 功能上手体验632.3 让发布更安全的：线上异动感知712.3.1 部署前检测722.3.2 部署异动感知742.3.3 在自动化流程中的策略742.4 性能心中有数：一键压测函数计算752.4.1 实现原理752.4.2 操作案例752.5 从工具看函数资源评估782.5.1 内存探测模式782.5.2 并发度探测模式802.6 Serverless Devs 与 Funcraft/Fcli 的对比822.6.1 形式对比822.6.2 功能对比822.6.3 场景对比832.6.4 迁移案例843.Serverless 架构下 AI 最佳实践873.1 PaddleOCR 项目开发与部署873.1.1 本地开发873.1.2 部署到 Serverless 架构903.1.3 项目优化933.2 Tensorflow 与目标检测系统953.2.1 本地开发953.2.2 部署到 Serverless 架构973.2.3 项目优化1034.Serverless Devs 与 CI/CD 实战1044.1 与 CI/CD 平台/工具集成1044.1.1 与 Github Action 的集成1054.1.2 与 Gitee Go 的集成1074.1.3 与 Jenkins 的集成1104.1.4 与云效的集成1134.2 Custom Container 的 CI/CD 最佳实践案例1154.2.1 实验准备1154.2.2 流程1164.2.3 项目测试1184.2.4 案例总结与注意事项1194.3 基于 Gitee Go 的函数代码更新与版本发布1234.3.1 实验准备1234.3.2 基于 Gitee 的 CD 能力建设1254.3.3 案例总结1325.Serverless 应用开发经验/常见思路1335.1 如何上传文件1335.2 文件读写与持久化方法1355.3 慎用部分 Web 框架的特性1365.3.1 异步1365.3.2 定时任务1365.4 要注意应用组成结构1375.4.1 静态资源与业务逻辑1375.4.2 业务逻辑的进一步拆分1375.5 善于利用函数的厂商特性1395.6 传统框架迁移方案与策略1415.6.1 传统框架迁移案例1415.6.2 通过开发者工具快速迁移/部署1435.7 可观测性1495.7.1 通过工具进行 Metrics 查看1515.7.2 通过工具进行 Logs 查看1525.8 如何对应用进行调试1545.8.1 在线调试1545.8.2 端云联调1555.8.3 本地调试1625.8.4 其他调试方案164附录1671.引言1.引言自“云计算”被提出之后，其可谓是如同雨后春笋般，蓬勃发展：2003 年到 2006 年间，谷歌发表了 The Google File System、MapReduce:Simplified Data Processing on LargeClusters、Bigtable:A Distributed Storage System for Structured Data 等文章，这些文章指明了 HDFS（分布式文件系统），MapReduce（并行计算）和 Hbase（分布式数据库）的技术基础以及未来机会，至此奠定了云计算的发展方向；2006 年，Google 首席执行官埃里克施密特（Eric Schmidt）在搜索引擎大会（SESSanJose2006）首次公开正式地提出“云计算”（Cloud Computing）的概念，同年亚马逊第一次将其弹性计算能力作为云服务进行售卖，这也标志着云计算这种新的商业模式正式诞生。两年后，即 2008 年，微软发布云计算战略和平台Windows Azure Platform，尝试将技术和服务托管化、线上化。到了 2009 年，UC Berkeley发表了：Above the Clouds:A Berkeley View of Cloud Computing，在该文章中，明确指出：云计算是一个即将实现的古老梦想，是计算作为基础设施这一长久以来梦想的新称谓，它在最近正快速变为商业现实。在该文章中，明确的为云计算做了定义：云计算包含互联网上的应用服务及在数据中心提供这些服务的软硬件设施。同时在该文章中，也提出了云计算所面临的挑战和机遇：问题机会服务的可用性选用多个云计算提供商；利用弹性来防范 DDOS 攻击数据丢失标准化的 API；使用兼容的软硬件以进行波动计算数据安全性和可审计性采用加密技术，VLANs 和防火墙；跨地域的数据存储数据传输瓶颈快递硬盘；数据备份/获取；更加低的广域网路由开销；更高带宽的 LAN 交换机性能不可预知性改进虚拟机支持；闪存；支持 HPC 应用的虚拟集群可伸缩的存储发明可伸缩的存储大规模分布式系统中的错误发明基于分布式虚拟机的调试工具快速伸缩基于机器学习的计算自动伸缩；使用快照以节约资源声誉和法律危机采用特定的服务进行保护软件许可使用即付许可；批量销售1.引言1.引言如上图所示，而截至 2017 年，各大云厂商基本上都已经在 Serverless 进行了基础的布局，尤其是国内的几大云厂商，也都先后在这一年迈入“Serverless 时代”。从 IaaS 到 PaaS 再到 SaaS的过程中，如图所示，云计算所表现出的去服务器化越来越明显，那么 Ken Form 所提出来的Serverless 又是什么，它在云计算发展的过程中，又在扮演什么角色呢，它的去服务器化又到了什么程度呢？Serverless 翻译成中文是无服务器，所谓的无服务器并非是说不需要依靠服务器等资源，而是说开发者再也不用过多考虑服务器的问题，可以更专注在产品代码上，同时计算资源也开始作为服务出现，而不是作为服务器的概念出现，Serverless 是一种构建和管理基于微服务架构的完整流程，允许用户在服务部署级别而不是服务器部署级别来管理用户的应用部署。与传统架构的不同之处在于，它完全由第三方管理，由事件触发，存在于无状态（Stateless），暂存（可能只存在于一次调用的过程中）在计算容器内，Serverless 部署应用无需涉及更多的基础设施建设，就可以基本实现自动构建、部署和启动服务。近些年来，微服务（Micro Service）是软件架构领域另一个热门的话题，如果说微服务是以专注于单一责任与功能的小型功能块为基础，利用模组化的方式组合出复杂的大型应用程序，那么可以进一步认为 Serverless 架构可以提供一种更加“代码碎片化”的软件架构范式，而这一部分称之为 Function as a Services（FaaS）。而所谓的“函数”提供的是相比微服务更加细1.引言1.引言Accelerite 首席执行官 Nara Rajagopalan：Serverless 将改变开发模式。而到了 2018 年，Serverless 的发展速度要比想象中的更加快速，在这一年，Google 发布了Knative，一个基于 Kubernetes 的开源 Serverless 框架，具备构建容器、流量调配、弹性伸缩、零实例、函数事件等能力。AWS 发布了 Firecracker，一个开源的虚拟化技术，面向基于函数的服务，创建和管控安全的、多租户的容器。Firecracker 的目标是把传统虚拟机安全性和隔离性，和容器的诉求，资源效率结合起来。在这一年，CNCF 也正式发布了 Serverless 领域的白皮书：CNCF Serverless Whitepaper V1.0，阐明 Serverless 技术概况、生态系统状态，为CNCF 的下一步动作做指导，同时 CloudEvnent 规范，进入 CNCF Sandbox；在这一年，UCBerkeley 发文 Serverless Computing:One Step Forward,Two Steps Back，表达了对Serverless 的担忧和挑战，在这篇文章中，作者认为 Serverless 会对开源服务创新有所阻塞，作者认为 Serverless 是：One Step Forward，Two Steps Back，关于这个部分内容的描述如下：One Step Forward通过提供自动缩放功能，今天的 FaaS 产品在云编程方面迈出了一大步，它提供了一种实际上可管理的，看似无限的计算平台。Two Steps Back首先，他们忽略了高效数据处理的重要性；其次，它们阻碍了分布式系统的开发。任何一个新的技术、概念出现都会遇到一定的挑战和担忧，就如同当年云计算出现时，也被一些人（如 Oracle 公司总裁 Larry Ellison、GNU 发起人 Richard Stallman）认为只是又一个商业炒作的概念，毫无新意，甚至蠢不可及。当然，事实也证明，任何一个新的事物，都只有在经历各种挑战和质疑之后，才能更茁壮地成长，Serverless 也不例外，从 2019 年开始，Serverless 进入到了一个真正意义上的生产应用，最佳实践快速发展阶段而 2019 年对 Serverless 而言是非常关键的一年，也是 Serverless 具有里程碑式发展的一年，被很多人定义为“Serverless 正式发展的元年”。在这一年不仅有 KubeCon 在中国上海的 CloudNativeCon 中关于 Serverless 的“海量主题演讲”，这些演讲包括来自 Captial One 银行的 Kevin Hoffman1.引言1.引言如上图所示，从 2012 年，Serverless 概念被正式提出之后，2014 年 AWS 带领 Lambda 开启了Serverless 的商业化，再到 2017 年各大厂商纷纷布局 Serverless 领域，再到 2019 年，Serverless 成为热点议题在 KubeCon 中被众多人参与探讨，UC Berkeley 发文断言 Serverless 将引领云计算的下一个十年，Serverless 随着时间的不断推进，各种技术的不断进步，正在逐渐地朝着更完整，更清晰的方向发展，随着 5G 时代的到来，Serverless 将会在更多领域发挥至关重要的作用。从 IaaS 到 FaaS 再到 SaaS，再到如今的 Serverless，云计算的发展在近十余年中发生了翻天覆地的变化，从虚拟空间到云主机，从自建数据库等业务，到云数据库等服务，云计算的发展是迅速地，未来的方向和形态却是模糊的，没人知道云计算的终态是什么。诚然，现在有人说Serverless 实现了当初了云计算目标，Serverless 才是真正的云计算，但是没人可以肯定地说，Serverless 就是云计算的终态表现，或许，Serverless 也仅仅是一个过渡的产物，但是这就要交个时间去验证了，目前就不得而知了。1.引言1.引言如上图所示，Martin Fowler 认为，在 Serverless 架构中，应用的一部分服务端逻辑依然由开发者完成，但是和传统架构不同，它运行在一个无状态的计算容器中，由事件驱动、生命周期很短（甚至只有一次调用）、完全由第三方管理，这种情况称为 Functions as a service/FaaS。AWS Lambda 是目前的热门 FaaS 实现之一；除此之外，Serverless 架构还要有部分依赖于第三方（云端）应用或服务来管理服务器端逻辑和状态的应用，这些应用通常是富客户端应用（单页应用或者移动端 App），建立在云服务生态之上，包括数据库（Parse、Firebase）、账号系统（Auth0、AWS Cognito）等，而这些服务最早被称为“(Mobile)Backend as a Service”，即所认为“BaaS”部分。在同样认为 Serverless 有 FaaS 与 BaaS 结合而成的同时，CNCF 在对 Serverless 架构的定义进行了进一步完善描述：Serverless 是指构建和运行不需要服务器管理的应用程序概念。它描述了一种更细粒度的部署模型，其中将应用程序打包为一个或多个功能，上传到平台，然后执行、扩展和计费，以响应当时确切的需求。与此同时，在 2019 年 UC Berkeley 的文章CloudProgramming Simplified:A Berkeley View on Serverless Computing中也同样从Serverless 架构特性的角度，对什么是 Serverless 也进行了补充描述和定义：简单地说，Serverless=FaaS+BaaS。在对于被认为是 Serverless 的服务，它必须具备弹性伸缩和按量付费的特点；在信通院云原生产业联盟所发布的云原生发展白皮书（2020 年）中对 Serverless 的概念也有相关的描述：无服务器（即 Serverless）是一种架构理念，其核心思想是将提供服务资源的基础设施抽象成各种服务，以 API 接口的方式供给用户按需调用，真正做到按需伸缩、按使用收费。这种架构体系结构消除了对传统的海量持续在线服务器组件的需求，降低了开发和运维的复杂性，降低运营成本并缩短了业务系统的交付周期，使得用户能够专注在价值密度更高的业务逻辑的开发上。至此，Serverless 架构从结构上，行为上以及特性上的定义，就可以总结成下图的形式：1.引言1.引言1.3 Serverless 架构应用场景UC Berkeley 曾犀利断言“Serverless 架构将成为云时代的默认计算范例，主要取代服务器计算，从而为客户端-服务器时代带来封闭”，在信通院云原生产业联盟所发布的云原生发展白皮书（2020 年）中，也对云原生发展趋势进行了大胆的预测“应用服务 Serverless 化，更加聚焦业务的核心价值。Serverless 架构作为云原生技术未来的演进方向，无服务器架构技术（Serverless）也从观望逐渐落地，据 Gartner 的过往预测数据显示：到 2020 年全球将有 20%的企业部署无服务器架构。Serverless 将进一步释放云计算的能力，将安全、可靠、可伸缩等需求交由基础设施实现，使用户仅需关注业务逻辑而无需关注具体部署和运行，极大地提高应用开发效率。同时这个方式促进了社会分工协作，云厂商可以进一步通过规模化、集约化实现计算成本大幅优化。“由此可见，Serverless 架构将会成为未来云计算领域中重要的技术架构，将会被更多的业务所采纳，成为其技术选型。那么再进一步的深究，Serverless 在什么场景下可以有非常优秀的表现，在什么类型的场景下可能表现得并不是很理想呢？或者说，有哪些场景更适合 Serverless架构呢？Serverless 架构的应用场景，通常是由其特性决定方向，所支持的触发器决定具体场景。如上图所示，在 CNCF Serverless Whitepaper v1.0 关于 Serverless 架构所适合的用户场景包括：异步的并发，组件可独立部署和扩展的场景应对突发或服务使用量不可预测的场景短暂、无状态的应用，对冷启动时间不敏感的场景1.引言1.引言1.3.2 实时文件/数据处理视频应用、社交应用等场景下，用户上传的图片、音视频往往总量大、频率高，对处理系统的实时性和并发能力都有较高的要求。例如：对于用户上传的图片，可以使用多个函数对其分别处理，包括图片的压缩、格式转换、鉴黄鉴恐等，以满足不同场景下的需求。例如：通过 Serverless 架构所支持的丰富的事件源，通过事件触发机制，可以通过几行代码和简单的配置对数据进行实时处理，例如：对对象存储压缩包进行解压、对日志或数据库中的数据进行清洗、对 MNS 消息进行自定义消费等：1.引言1.引言1.3.5 IoT 等物联网领域目前很多厂商都在推出自己的智能音箱产品，用户可以对智能音箱说出一句话，智能音箱可以通过互联网将这句话传递给后端服务，然后获得到反馈结果，再返回给用户。通过 Serverless架构，可以将 API 网关、云函数以及数据库产品进行结合来替代传统的服务器或者是虚拟机等，通过这样的一个架构，一方面，可以确保资源的按量付费，只有在使用的时候，函数部分才会计费，另一方面当用户量增加之后，通过 Serverless 实现的智能音箱系统的后端，也会进行弹性伸缩，可以保证用户侧的服务稳定，当要对其中某个功能进行维护，相当于对单个函数进行维护，并不会对主流程产生额外风险。相对来说会更加安全、稳定等：1.3.6 监控与自动化运维在实际生产中，经常需要做一些监控脚本来监控网站服务或者 API 服务是否健康，包括是否可用、响应速度等。传统的方法是通过一些网站监控平台（例如 DNSPod 监控、360 网站服务监控，以及阿里云监控等）来进行监控和告警服务，这些监控平台的原理是通过用户自己设置要监控的网址和预期的时间阈值，由监控平台部署在各地区的服务器定期发起请求对网站或服务的可用性进行判断。当然，这些服务很多都是大众化的，虽然说通用性很强，但是实际上并不一定适合。例如，现在需要监控某网站状态码，不同区域的延时，并且设置一个延时阈值，当网站状态异常或者延时过大时，通过邮件等进行通知告警，针对这样一个定制化需求，目前来说大部分的监控平台很难直接实现，所以定制开发一个网站状态监控工具就显得尤为重要。除此之外，在实际的生产运维中，还非常有必要对所使用的云服务进行监控和告警，例如在使用Hadoop、Spark 的时候要对节点的健康进行监控，在使用 K8S 的时候要对 API Server、ETCD等多维度的指标进行监控，在使用 Kafka 的时候，也要对数据积压量，以及 Topic、Consumer等指标进行监控；这些服务的监控，往往不能通过简单的 URL 以及某些状态来进行判断，在传统的运维中，通常会在额外的机器上设置一个定时任务，对相关的服务进行旁路监控。1.引言1.引言1.4 Serverless Devs 简介1.4.1 工具链建设的必要性Serverless 正在改变未来软件开发的模式和流程，并被预测将引领云计算的下一个十年，但尽管如此，开发者在选择使用 Serverless 时仍有诸多担忧，这其中最受关注的无疑就是工具链体系的匮乏。所谓的工具链匮乏，一方面表现在市面上工具链不完善，这导致开发和部署难度大，进而增加成本；另一方面表现在，缺乏相关的工具链在体验层将 Serverless 体验进一步规范，优质工具链的匮乏导致本来就担心被厂商绑定的 Serverless 开发者变得更难与厂商解绑。2020 年 10月，中国信息通信研究院发布国内首个云原生用户调查报告明确指出在使用 Serverless 架构之前，49%的用户考虑部署成本，26%的用户考虑厂商绑定情况，24%的用户考虑相关工具集完善程度，这些数据背后透露的实际上是：开发者对于完善工具链的强烈需求。尽管，有一些开发者认为入门 Serverless 架构，通过白屏化的操作相对来说会更容易入门，在一定程度上通过各个云厂商的控制台进行函数的创建、更新也会更为方便。但是不可否定的是，Serverless 开发者工具在一定程度上却有着更为重要的价值和作用：通过脚手架，快速创建 Serverless 架构的应用；在开发过程中，通过开发者工具进行应用的调试等；在开发完成之后，通过开发者工具将应用（可能包括多个函数以及相对应的 BaaS 类产品）一键部署到线上；项目运维阶段，通过开发者工具进行项目的可观测以及问题定位等；若需要实现科学部署，通过某些 CI/CD 平台/工具发布 Serverless 架构的应用，通常是离不开开发者工具的;就目前来看，Serverless 领域的开发者工具复杂多样，且功能不完善；并没有绝对统一/一致的 Serverless 开发者工具，每个厂商都有自己的开发者工具，而且使用形式，行为表现并不相同，这就导致了开发者在开发前的调研、开发中的调试、部署后的运维等多个层面面临很严峻的挑战；1.引言1.引言开源形式建设：项目通过开源代码，开放生态进行建设，开发者可以随时查看和参与Serverless Devs 开发者工具的贡献，也可以随时随地进行相关组件和应用的贡献。当然，除了这种开源开放的形态，也鼓励一些企业级团队，通过 Serverless Registry Model 建设自己的私有 Registry 以定制化某些不便公开的自定义组件；功能灵活可插拔：Serverless Devs 开发者工具本身，不具备任何业务能力，所有的业务能力均是通过组件化的形式，进行可插拔式使用，并且每个组件可以根据需要，自定义相对应的命令和功能；开发者可以在一个应用中，选择不同的组件完成对应的业务能力，以满足对不同模块的诉求；简单快速上手：通过开放 Serverless Registry 的模型/规范，该项目可以通过应用的模式，为开发者提供多种形式，多种领域以及多种场景的上手案例，帮助开发者快速了解、学习、深入、上手 Serverless 架构，例如新手引导中的 Serverless：Hello World；人工智能：目标检测；传统框架：基于 Django 的博客项目等项目；应用全生命周期管理：通过组件化的支持，Serverless Devs 可以在应用的全生命周期发挥重要作用，以阿里云函数计算的 FC 组件为例，开发者可以在项目创建、项目的开发、调试、可观测性等多个层面进行项目的建设和管理；良好的集成与被集成性：项目具有非常好的集成性与被集成性，可以通过组件化的支持，非常简单的与传统的生态进行有机结合。同时，Serverless Devs 开发者工具也可以非常简单的被集成到海量的自动化流程中，例如 CI/CD 文档中，就举例了与 Github Action 的集成、与 Gitee Go 的集成、与 Jenkins 的集成等平台集成的案例；1.4.5 设计哲学Serverless Devs 是一个开源开放的 Serverless 领域的工具链项目，它不仅仅表示单纯的某个命令行工具，在一定程度上指的是一个完整的工具链体系。在 Serverless Devs 中，拥有两个角色：开源贡献者：开源贡献者将按照 Serverless Package Model 进行组件/应用的开发，并将内容发布到 Serverless Hub 中，既可以被更多人所使用；Serverless 开发者：通过开发者工具（包括命令行工具以及桌面端等工具），进行应用的初始化，以及组件的使用；通过开发者工具，将业务按照预期部署到线上。1.引言1.引言多个组件，并通过 Serverless Devs 开发者工具部署到 Serverless 平台，例如我开发了一个猫狗识别的应用，在这个应用中引用了 Lambda 组件帮助我将部分业务逻辑部署到 FaaS平台，同时我也引用了 Website 组件帮助我把前端业务代码部署到对象存储中。Serverless 工具链体系，让开发者更专注于业务逻辑，提升 Serverless 应用开发、部署、运维效率，通过该模型，开发者可以通过一种更灵活、更通用的方法使用不同云厂商以及开源的Serverless 产品，进而更高效、更简洁、更便利的实现 Serverless 应用管理。成长历史如果说 Serverless 提升了传统应用的开发效能，那么 Serverless Devs 开发者工具就是提升了Serverless 应用开发的效能。随着时间的发展，Serverless Devs 也从 1.0 版本 到了 2.0 版本，更是从简单的效能提升，变成了更加规范、更加科学的效能提升。希望可以通过Serverless Devs 的工具链模式和思路，为应用的开发，传统项目上 Serverless 架构提供巨大的便利和更科学的管理。2020 年 10 月 23 日，Serverless 开发者平台 Serverless Devs 正式开源2020 年 11 月，Serverless Devs 被 CNCF Landsacpe 收录,成为国内首个进驻的Serverless 工具2020 年 11 月，Serverless Developer Meetup 首召开，成 Serverless 开发者技术新渠道2020 年 11 月，入围 InfoQ 评选 2020 年度十大开源新锐项目1.引言1.引言1.5 阿里云函数计算（FC）组件简介阿里云函数计算（FC）组件是一款符合 Serverless Devs 规范的组件，通过在 Serverless Devs开发者工具中，使用该组件，可以快速帮助开发者使用阿里云函数计算产品。1.5.1 Serverless Devs 和 FC 组件的关系1、Serverless Devs 是一个无厂商锁定 Serverless 的工具框架，本身不具任何能力，用户可以通过引入不同的组件使用不同的功能，例如：1.引言1.引言在项目的创建阶段，可通过命令行工具或者应用中心进行项目的最初创建；在项目开发过程中，可以通过本地开发、调试等能力来验证本地开发的正确性；在项目调试的环节，可以通过本地调试与远程调用、日志查询等能力，来进行项目的最终调试；在部署环节，可以先通过依赖安装、项目构建等流程构建出完整的部署包，再进行项目的部署；在后期运维环节，可以通过指标查询来进行项目健康度检查，通过日志查询等来进行问题定位，通过项目发布等能力进行版本发布，别名发布以及灰度发布等；目前为止，阿里云函数计算（FC）组件已经支持的能力包括：构建&部署可观测性调用&调试发布&配置其他功能部署 deploy指标查询metrics本地调用 local版本 version硬盘挂载 nas构建 build日志查询logs函数触发 invoke别名 aliasFun 项目迁移 fun2s移除 remove端云联调 proxied预留 provision查看函数 info计划变更 plan实例登陆 instance按量资源 ondemand资源同步 sync内存&并发度探测eval层 layer压测 stressAPI 调用 api2.快速入门与功能案例=10.8.0)与 NPM 包管理工具；第二步：安装 Serverless Devs 开发者工具；$npm install serverless-devs/s-g第三步：可以通过 s-v 判断工具是否安装成功，如果安装成功可以看到相对应的版本信息，例如：serverless-devs/s:2.0.89,serverless-devs/core:0.1.7,arwin-x64,node-v12.15.02.1.2 密钥配置2.1.2.1 获取密钥配置 Serverless Devs 的阿里云密钥，一般需要密钥信息，获取页面为：https:/ AK 信息AccessKeySecret：用户的 SK 信息关于密钥信息的获取流程如下：打开获取密钥信息372.快速入门与功能案例2.1.2.2 引导式密钥配置通过引导式进行密钥配置，可以通过 s config add 命令，进行引导式创建：执行 s config add，并选择 Alibaba Cloud(alibaba)：$s config add?Please select a template:Alibaba Cloud(alibaba)Refer to the document for alibaba key:http:/ select a template:Alibaba Cloud(alibaba)Refer to the document for alibaba key:http:/ 此处填写 AccessKeyID?AccessKeySecret 此处填写 AccessKeySecret?Please create alias for key pair.If not,please enter to skip alibaba-accessAlias:alibaba-accessAccessKeyID:此处填写 AccessKeyIDAccessKeySecret:此处填写 AccessKeySecretConfiguration successful2.快速入门与功能案例2.快速入门与功能案例$s config add-AccessKeyID*-kl key1,key2,key3-il info1,info2,info3-a demo-2Alias:demo-2key1:info1key2:info2key3:info3Acce