开发者学堂课程【Serverless 技术进阶：serverless Devs 案例与体验】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/995/detail/15023
serverless Devs 案例与体验
快速入门正在改变未来软件开发的模式和流程，并被预测将引领云计算的下一个十年。但尽管如此，开发者在使用serverless时仍有诸多担忧，这其中最关注的无疑是工具链体系的匮乏。
所谓工具链匮乏，一方面表现在市面上的工具链不完善，这导致开发和部署难度大，进而增加成本，另一方面表现在缺乏相关的工具店，在体验层将service企业进一步规范。优质工具店的匮乏，导致本来就担心被厂商绑定的serverless开发者变得更难与厂商解绑。
2020年10月中国信通院发布国内首个预约。用户调查报告明确指出，在使用搜累架构之前，49%的用户考虑部署成本，26%的用户考虑厂商绑定，24%的用户考虑相关工具及完善程度，这些数据的背后透露的实际上是开发者对于完善工具链的强烈需求。尽管有一些开发者认为入门serverless架构，通过白屏化的操作，相对来说会更容易，在一定程度上通过各个云厂商的控制台进行函数的创建更新，也会更加方便。但是不可否定的是，serverless开发者工具在一定程度上有着更为重要的价值和作用：具体体现在我们可以通过脚手架快速创建serverless架构的应用，
在开发过程中，通过开发者工具可以进行业务的调试等，在开发完成之后，通过开发者工具将应用一键部署到线上
项目运维阶段，通过开发者工具可以进行项目的可观测以及问题定位等，若需要实现科学部署，通过某些CICD平台工具发布架构的应用通常是离不开开发者工具的，就目前来看，Serverless领域的开发者工具复杂多样且功能不完善。
并没有绝对统一一致的serverless开发者工具。每个厂商都有自己的开发者工具，而且使用刑事行为表现并不相同，这就导致了开发者在开发前的调试、开发中的调试、部署后的运维等多个层面面临着很严峻的挑战。
绝大部分的serverless开发者工具更多的是资源编排部署工具，并不能真正意义上称之为开发工具。工具、运维工具，尤其是在开发太的调试，如何保证线上线下环境的一致性，如何在运维态可以快速的对业务进行调试？如何更简单的排查错误、定位问题等方面并没有统一的完整的方案，这就导致serverless架构的学习成本高使用成本对开发者来说会变得非常高。
综上所述，作为可以提升service应用开发效能、降低serverless架构使用难度的serverless工具链体系建设，显得尤为重要。也正是因为此，serverless Devs应运而生。
serverless Devs是一个开源开放的serverless开发者平台，致力于为开发者提供强大的工具链体系。通过该平台，开发者不仅可以一键体验多云serverless。极速部署serverless Devs项目还可以在serverless应用全生命周期进行项目的管理，并且非常简单快速的将serverless Devs与其他工具或平台进行结合，进一步提升研发、运维效能。
serverless Devs究竟有哪些优势呢？
在这里总结出了六点，首先无厂商锁定，得益于功能的可插拔特性，可以非常简单地支持不同云厂商的项目部署或者一键部署的不同云平台。目前serverless Devs已经支持了阿里云函数计算、AWS Lambda、百度智能云函数计算、华为云函数工作流、腾讯云函数等多云的faas产品。
发产品开源形式建设项目，通过开源代码、开放生态进行建设，开发者可以随时查看和参与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的集成等平台集成案例。
关于serverless的设计哲学是什么呢？serverless Devs是一个开源开放的serverless领域的工具链项目，它不仅仅表示单纯的某个命令行工具，在一定程度上指的是一个完整的工具链体系。
在serverless Devs中拥有两个角色，
开源贡献者将按照serverless package model进行组件/应用的开发，并将内容发布到serverless Hub中，既可以被更多人所使用。
serverless开发者通过开发者工具，包括命令行工具以及客户端等工具进行应用的初始化以及组件的使用，通过开发者工具将业务按照预期部署到线上。
在这样一个serverless devs应用框架上，不难发现可以与其他任何一种模式/生态，具有相似的命运以及模块:
Serverless Hub类似于一种组件应用案例中心类似于docker hub 等。
serverless registry，类似于一种组件应用的管理工具或者规范模型，类似于python生态中的PYP，类似于note JS生态中的NPM。
当然，在serverless hub中有两种形态的package组件和应用，同时也可以看到两个比较明显的词汇component和application
component指的是组件，是由package developer开发并发布的组合。Serverless package motor规范整理一段代码。通常这段代码会在应用中被引用，并且在serverless Devs开发者工具中被加载，并按照预定的规则进行执行某些动作，例如将用户的代码部署到serverless平台，将serverless应用进行构建和打包，对serverless应用进行调试等。
application指的是应用可以由package developer公开发布的registry提供更多人学习和使用。例如，某位贡献者贡献了一个猫狗识别的案例，到registry也可以由搜狗的洗发露和开发。例如，某人发布了一个人脸识别的应用，通常情况下，一个应用可以引用一个或者多个组件，并通过serverless devs开发者根据部署到serverless平台，例如我曾经开发了一个猫狗识别的应用，在这个应用中引用lambda组件帮助我将部分业务逻辑部署到faas平台，同时我也引用了website组件，帮助我把前端业务代码部署到对象存储中。
Serverless Devs的模型设计原则是希望可以通过更加简单，科学规范的serverless工具链体系，让开发者更。专注于业务逻辑，提升serverless应用开发、部署、运维效率。通过该模型，开发者可以通过一种更灵活、更通用的方法，使用不同云厂商以及开源的serverless的产品，进而更高效、更简洁、更便利地实现serverless应用管理。
接下来，我要介绍一下serverless Devs的成长历史，如果说serverless提升了传统应用的开发效能呢？那么Devs开发者工具所提升了serverless应用开发的效能。随着时间的发展，serverless Devs也从1.0的版本到了2.0的版本，更是从简单的效能提升变成了更加规范、更加科学的效能提升，希望可以通过serverless Devs的工具链模式和思路。对应用的开发，传统项目上的serverless架构提供更大的便利和更科学的管理.
阿里云函数计算组件简介，阿里云函数计算组件以下检查非主线是一款符合surface depth规范的组件，通过在思维Devs开发者工具中使用该组件，可以快速帮助开发者使用阿里云函数计算产品。expect和SC组间的关系，serverless devs是一个无厂商锁定的serverless工具，框架本身不具备任何功能，用户可以通过引入不同的组件使用不同的功能，而SC组件则是这个工具框架的一个组件，主要是对阿里函数计算进行操作的，例如创建函数、删除函数、发布版本、业务构建、在线调试等。
如果需要进行比喻，serverless devs是小时候玩的红白机，Esc组件、OS组件、那组件等都是游戏卡,游戏机本身不具备啥功能，根据插入的游戏卡实现不同的功能，serverless就相当于使用Vs code工具本身不具备太多的能力，但是可以安装不同的插件来丰富serverless devs这些插件对应到serverless devs生态中就是不同的组件，例如SC组件、那组件、os组件等。
接下来介绍一下devs的五大亮点
一、全生命周期管理组件，拥有项目的创建、开发、调试、部署、运维全生命周期管理能力，
二、安全发布，通过其他形式对函数进行变更，组件可以感知并安全更新，三、快速集成，借助于superstar的集成性和被集成性，可以与常见的CD平台工具。
四、可观测性，拥有完善的可观测性，在客户端可以通过指标查询matrix以及日志查询logs等命令，进行业务的数据、指标、执行、日志等多重维度观测。
五、多模调试，提出了调试方案，可以同时满足开发太运维态的不同调式需求。包括本地运行、在线运行、云端调试。多元面条等功能支持阿里云函数计算组件，可参与到项目地创建、开发、调试，不属于运维的全流程中。
在项目的创建阶段，可通过命令行工具或者应用中心进行项目的最初创建，在项目开发过程中，可以通过本地开发、调试等能力来验证本地开发的正确性。在项目调试的环节，可以通过本地调试、远程调用、日志查询等能力来进行项目的最终调试。再部署环节可以先通过依赖安装、项目构建等流程构建出完整的部署包在进行，在后期运维环节，可以通过指标查询来进行项目健康度检查，通过日志查询等来进行问题定位，通过项目发布等能力进行版本发布、联名发布以及灰度发布等。接下来，请同学们查找书中36页到63页，详细了解工具安装、密钥配置以及yam1的使用规范，多种操作模式下的工具体系。
众所周知，目前大部分的serverless开发者工具均是通过某等进行资源描述，少部分的serverless开发者工具是通过命令行直接操作，无论是通过yam1进行资源描述，还是通过纯利银行的操作，可以说两者各有各的好处，而在serverless devs开发者工具中。这两者均得以有效地支持serverless devs开发者工具，从根本上提供了两种使用方法呀，模式需要依赖自己资源描述文档进行操作的模式。CR模式可以在任何目录下直接执行，而不需要依赖资源描述文档。这两者的核心区别是，如果想要使用yam1，模式在当前目录下。必须要有SM文件。或通过template指定的资源部描述文件，如如果想要使用CL模式，则必须使Sci组建方法参数的格式进行，此时不需要yam1文件，存在yam1式和CR模式呢？因为在长期的实践过程中发现，通过某进行资源描述会相对来说更加方便简单，例如K8S等也都是通过某进行资源描述的。但是在某些情况下，yam1文件也可能成为一种负担，例如想要查看某个服务下的函数列表，想要看各个地区下的服列表，因为这样的一个简单的事情需要额外的去完成一个压缩文件就显得过于臃肿，所以在serverless devs项目中，同时保留了两种方法，接下来请同学们查看书中15页到63页，这部分给大家介绍了一些体验项目，包括hello world，人工智能传统框架给予的jungle的博客项目等，另外还介绍了包括部署、调用、可观测性指标等一些功能性的上手体验。
