1.1.5 生态工具除Serverless Framework之外，Serverless Devs同样是无厂商锁定的多云开发者工具。目前按照Serverless Devs的官方仓库显示，其已经支持AWS Lambda，阿里云函数计算，腾讯云云函数，华为云Serverless工作流以及百度智能云函数计算等产品。与Serverless Framework不同的是，Serverless Devs主打的是Serverless应用全生命周期管理工具。如下图所示，以阿里云函数计算为例，Serverless Devs可以支持包括脚手架、调试、发布、运维等多个流程多种功能：另外值得一提的是，Serverless Devs不仅支持拥有完善的工具链产品，其在2021年还对外正式发布Serverless Devs Model（Serverless开发者工具模型：SDM）：通过Serverless Devs，开发者同样可以非常简单快速的使用各个厂商/平台的Serverless产品，以阿里云函数计算为例：# 安装 npm install -g @serverless-devs/s # 配置密钥 s config add --AccessKeyID AccessKeyID --AccessKeySecret AccessKeySecret # 创建一个项目 s init node.js12-http -d fc-hello-world-demo # 进入项目 cd fc-hello-world-demo # 部署项目 s deploy开发框架在传统架构下，开发者想要进行业务开发有着诸多的开发者个框架可供选择，以Web框架为例，Node.js语言类的有Expree.js，Nuxt.js，Egg.js等，Python语言类的有Django，Flask等，Java类的也有SpringBoot等，但是随着Serverless架构的不断发展，传统框架迁移到Serverless是一种解决Serverless应用开发者框架匮乏的方案之一，但是实际上这些框架并不是针对Serverles是架构设计的，很有可能有诸多的优秀特性丧失，例如某些框架的异步处理能力，尽管Serverless平台都已经提供了异步触发能力，但是框架本身的异步处理能力在Serverless架构下就很难被利用起来，所以针对Serverless架构所设计的Serverless First框架，就显得尤为重要。目前在社区生态中，有诸多优秀的Serverless应用层面的开发者框架，例如基于原有 Midway 的 IoC 体系设计，复用原有装饰器和解耦能力的同时，将代码分解到不同的函数中，并发布到各个云平台的Midway Serverless；基于 TypeScript 的 Serverless First、组件化、平台无关的渐进式应用框架Malagu等。以Midway Serverless为例，Midway Serverless 是用于构建 Node.js 云函数的 Serverless 框架，帮助开发者在云原生时代大幅降低维护成本，更专注于产品研发。Midway Serverless拥有诸多优点，例如：跨云厂商：一份代码可在多个云平台间快速部署，不用担心产品会被云厂商所绑定。云端一体化：提供了多套和社区前端 React、Vue 等融合一体化开发的方案。代码复用：通过框架的依赖注入能力，让每一部分逻辑单元都天然可复用，可以快速方便地组合以生成复杂的应用。传统迁移：通过框架的运行时扩展能力，让 Egg.js 、Koa、Express.js 等传统应用无缝迁移至各云厂商的云函数通过该框架，开发者可以快速构建的全栈应用，也可以发布的函数服务，Restful 接口等，也可以加上前端（react，vue）代码构建中后台项目，也可以使用 Midway 提供的方案迁移传统的 Egg/Koa/Express 应用上弹性容器等。以全栈应用为例：# 安装 npm i @midwayjs/faas-cli -g # 创建一个项目 f create --template-package=@midwayjs-examples/midway-hooks-react # 部署项目 f deploy除Midway Serverless之外，Malagu也是一款社区驱动的Serverless First框架。Malagu 是基于 TypeScript 的 Serverless First、组件化、平台无关的渐进式应用框架，又叫 M 框架。使用同一套编程语言和 IoC 设计，用于开发前端、后端和前后端一体化应用。并且结合了 OOP（面向对象编程）、AOP（面向切面编程）等元素，借鉴了很多 Spring Boot 设计思想。在后端，Malagu 抽象一套接口，方便适配任意的平台和基础框架，是一个平台或基础框架无关的上层框架。平台如阿里云函数计算、腾讯云云函数、AWS Lambda、Vercel 等，基础框架如 Express、Koa、Fastify 等。与大部分传统开发框架不同的是，Malagu 是一个全栈应用开发框架，如果只看后端部分，Malagu 与 Spring Boot 是同一层次的东西，如果只看前端部分，Malagu 是 React、Vue 等前端框架之上的更上层的抽象，所以 Malagu 是前端框架无关的。Malagu 与传统框架比较，Malagu 提供了前后端渐进式一体化方案，在前后端之上做了一层抽象，让前后端在开发、测试、部署拥有一致的体验。传统框架一般不考虑应用部署环节，Malagu 借助 Serverless 技术优势，让部署环节变得流畅且低成本。另外，Malagu 也是一个 Serverless 优先的框架，屏蔽了 Serverless 底层的细节，开箱即用。针对 Serverless 场景做了很多优化，如冷启动、数据库操作等等；同时，也提供了很多开箱即用的能力，比如安全、认证与授权、OAuth2.0、OIDC、数据库操作、缓存、前端框架集成、依赖注入、AOP、微服务等。

1.1.4 生态发展Serverless架构的发展，离不开云厂商的驱动，离不开开源社区的支持，在过去的几年时间，无论是高校、实验室、云厂商等对Serverless架构的研究，还是CNCF等基金会对Serverless架构的持续关注和赋能，还是其他的Serverless社区、开源项目对Serverless架构的建设，Serverless架构都在逐渐的成为更通用，更好用的技术架构，都在成为更简单、更具价值的技术选型。学术建设Serverless架构从诞生到今天，正在逐渐的被更多人所关注，包括学术界也逐渐有越来越多的人，将目光投向Serverless架构，助力Serverless领域快速腾飞。这一部分，将会通过部分论文对Serverless架构在学术界的建设进行初步的分析和探索。2018年，Serverless的发展速度要比想象中的更加快速，这一年UC Berkeley发文《Serverless Computing: One Step Forward, Two Steps Back》，表达了对Serverless架构的担忧和挑战，在这篇文章中，作者认为“通过提供自动缩放功能，今天的FaaS产品在云编程方面迈出了一大步，它提供了一种实际上可管理的，看似无限的计算平台。但是，他们忽略了高效数据处理的重要性；其次，它们阻碍了分布式系统的开发”。任何一个新的技术、概念出现都会遇到一定的挑战和担忧，就如同当年云计算出现时，也被一些人（如Oracle公司总裁Larry Ellison、GNU发起人Richard Stallman）认为只是又一个商业炒作的概念，毫无新意，甚至蠢不可及。当然，事实也证明，任何一个新的事物，都只有在经历各种挑战和质疑之后，才能更茁壮的成长，Serverless也不例外。2019年，时隔一年，UC Berkeley针对Serverless架构再次发文《Cloud Programming Simplified: A Berkeley View on Serverless Computing》，在这篇文章中，作者犀利断言Serverless 将会在接下来十年被迅速采用，获得飞速发展，并对Serverless架构进行了更为激进的断言：Serverless 将会成为云时代默认的计算范式，将会取代 Serverful 计算，这也意味着服务器 - 客户端模式的终结，Serverless架构将会引领云计算的下一个十年。在学术界，不仅仅UC Berkeley 对Serverless发表过多篇论文，很多国内外高校都在Serverless领域投入了足够的精力进行科研探索。就目前来看， Serverless 已经成为学术界的研究热点，每年Serverless架构相关的论文都有比较明显的增长趋势：（该图片来自掘金社区）而到了2021年，Serverless架构在学术界的论文数量不仅仅再次上升，其研究内容和方向也是越发的完善和全面，其中包括不限于冷启动优化、镜像加速、调度策略、缓存机制等诸多热点问题。以阿里云函数计算团队和美国George Mason University Leap Lab合作发表在顶会USENIX ATC (USENIX Annual Technical Conference) 的论文《FaaSNet: Scalable and Fast Provisioning of Custom Serverless Container Runtimes at Alibaba Cloud Function Compute》为例，在文章中就针对容器镜像生态与Serverless架构结合之后的问题“镜像拉取与冷启动优化”问题进行了更为深入的探索，在加速镜像的分发速度方面，常见的业界成熟的 P2P 方案没有做到 function 级别的感知，并且集群内的拓扑逻辑大多为全连接的网络模式，对机器的性能提出了一定需求，这些前置设定不适配 FC ECS 的系统实现，为此设计并提出了一个具有高伸缩性的轻量级系统中间件FaaSNet，FaaSNet利用到镜像加速格式进行容器分发，目标作用场景是 FaaS 中突发流量下的大规模容器镜像启动（函数冷启动），FaaSNet 的核心组件包含 Function Tree (FT)，是一个去中心化的、自平衡的二叉树状拓扑结构，树状拓扑结构中的所有节点全部等价。FaaSNet 可以根据 workload 的动态性实现实时组网已达到 function-awareness，无须做预先的 workload分析与预处理，进而帮助Serverless平台解锁高伸缩性和快速的镜像分发速度技术瓶颈，赋能自定义容器镜像场景的更为深入和广泛的应用。除此之外，作为云计算领域的顶级会议SoCC，在2021年接收的论文中，也可以看到诸多Serverless架构的影子，例如以Microsoft Azure Functions作为实验平台的论文《FaaT:ATransparentAuto−ScalingCacheforServerlessApplications》，针对Serverless架构中函数stateless的特点，针对FaaS平台的Cache问题，提出了一种用于Serverless应用程序的自动伸缩分布式缓存FaaT: A Transparent Auto-Scaling Cache for Serverless Applications》，针对Serverless架构中函数 stateless 的特点，针对FaaS平台的Cache问题，提出了一种用于Serverless应用程序的自动伸缩分布式缓存FaaT:ATransparentAuto−ScalingCacheforServerlessApplications》，针对Serverless架构中函数stateless的特点，针对FaaS平台的Cache问题，提出了一种用于Serverless应用程序的自动伸缩分布式缓存FaaT，可以大幅度提升 Serverless 函数的性能，与已有的通过外部存储作为 Cache 系统的方法相比，Faa$T可以降低绝大多数的开销。另一篇文章《ServerMore: Opportunistic Execution of Serverless Functions in the Cloud》针对Serverless函数短执行时间与低资源需求的特点，介绍了一种服务器级资源管理器ServerMore，可将Serverless 函数与 Serverful 的虚拟机调度在同一台物理机上执行任务，ServerMore 动态调节服务器上的 CPU、内存带宽和 LLC 资源，以确保 Serverful 和 Serverless 工作负载之间的托管不会影响应用程序tail latencies。通过选择性地使用Serverless架构并推断相对黑盒的Serverful工作负载的性能，ServerMore 与之前的模式相比，平均提高了 35.9% 到 245% 的资源利用率；同时对 Serverful 应用程序和 Serverless 架构的延迟影响最小。Serverless架构的学术研究日渐火热，各领域的顶会也出现了诸多优秀的Serverless架构相关论文，这不仅有助于Serverless学术生态的繁荣，也非常有助于突破Serverless架构的技术瓶颈，实现云计算领域技术架构升级。除此之外，近年来国内的Serverless图书专著也逐渐多了起来，仅仅2021年一年的时间就先后有包括《前端Serverless：面向全栈的无服务器架构实战》、《Serverless从入门到进阶：架构、原理与实践》、《Serverless工程实践：从入门到进阶》、《华为Serverless核心技术与实践》等在内的图书被出版，大大丰富了国内的Serverless培训与教育的资料生态。随着时间的发展，Serverless架构在更多领域发挥着越来越重要的作用，在被更多人关注的同时，Serverless架构也逐渐的成为了诸多学者、实验室的研究对象，如何将学术和工业进行有机结合，如何通过工业赋能学术届的科研，通过学术届的科研赋能工业界技术架构的迭代升级，赋能整个行业的前进，这不仅仅是Serverless架构需要做的，也是如今的Serverless架构正在做的。工具链建设Serverless 正在改变未来软件开发的模式和流程，并被预测将引领云计算的下一个 10 年，但尽管如此，开发者在选择使用 Serverless 时仍有诸多担忧，这其中最受关注的无疑就是工具链体系的匮乏。所谓的工具链匮乏，一方面表现在市面上工具链不完善，这导致开发和部署难度大，进而增加成本；另一方面表现在，缺乏相关的工具链在体验层将 Serverless 体验进一步规范，优质工具链的匮乏导致本来就担心被厂商绑定的 Serverless 开发者变得更难与厂商解绑。2020年 10月，中国信息通信研究院发布国内首个《云原生用户调查报告》明确指出在使用 Serverless 架构之前，49% 的用户考虑部署成本，26% 的用户考虑厂商绑定情况，24% 的用户考虑相关工具集完善程度，这些数据背后透露的实际上是：开发者对于完善工具链的强烈需求。尽管，有一些开发者认为入门Serverless架构，通过白屏化的操作相对来说会更容易入门，在一定程度上通过各个云厂商的控制台进行函数的创建、更新也会更为方便。但是不可否定的是，Serverless开发者工具在一定程度上却有着更为重要的价值和作用：通过脚手架，快速创建Serverless架构的应用；在开发过程中，通过开发者工具进行应用的调试等；在开发完成之后，通过开发者工具将应用（可能包括多个函数以及相对应的BaaS类产品）一键部署到线上；项目运维阶段，通过开发者工具进行项目的可观测以及问题定位等；若需要实现科学部署，通过某些CI/CD平台/工具发布Serverless架构的应用，通常是离不开开发者工具的;目前Serverless领域，工具链建设分为两类：云厂商/Serverless框架所提供的针对自身的开发者工具，例如AWS的SAM CLI，阿里云的Funcraft，OpenWhisk的Ask等；由第三方提供的多云开发者框架（包括不限于开源社区驱动），例如Serverless Framework项目，Serverless Devs项目等；通过Serverless开发者工具，开发者可以非常简单的学习和使用Serverless架构，也可以在生产的过程中快速的使用这些工具进行开发效能的提升。以Serverless Framework为例，作为拥有近4万Star的海外老牌Serverless工具链开源项目，目前Serverless.com的官方网站支持11个常见的Serverless平台产品：可以通过Serverless Framework开发者工具，以AWS Lambda为例进行实践，可以通过几行命令快速体验AWS Lambda：# 安装 npm install -g serverless # 配置密钥 serverless config credentials --provider aws --key key--secret secret # 创建一个项目 serverless create --template aws-python3 --path my-service # 进入项目 cd my-service # 部署项目 serverless deploy -v除了对项目的部署和发布操作之外，Serverless Framework还支持项目的删除，回滚等更多的操作，以常见的部分云厂商和开源项目为例，Serverless Framework的常见能力表如下：

1.1.3 工作原理作为云时代新的计算范式，Serverless架构本身属于一种天然的分布式架构，其工作原理与传统架构虽没有翻天覆地的变化，但也是有细微的不同。如下图所示，传统架构下，开发者开发完成应用之后，还需要购买虚拟机服务，初始运行环境，安装需要的软件（例如MySQL等数据库软件，Nginx等服务器软件等），完成环境的准备之后，还需要上传开发好的业务代码，启动该应用，此时用户才可以通过网络请求，成功的访问到目标应用。此时，如果应用的请求量过大或者过小时，开发者或运维人员，还需要针对实际的请求数量进行相关资源的扩充或缩容，并在负载均衡&反向代理模块增加相对应的策略，以确保扩缩容操作的及时生效，当然，在做这些操作的时候还要保证线上用户不会受到影响。而在Serverless架构下，整个应用发布的过程和工作的原理，将会发生一定的变化：如上图所示，当开发者开发完整业务代码之后，只需要部署或更新到对应的FaaS平台即可，完成之后根据真实的业务需求，进行相关的触发器配置，例如为了对外提供Web应用服务，可以配置HTTP触发器等，此时用户就可以通过网络，访问到开发者所发布的应用。在这个过程中，开发者不需要再额外关注服务器的购买，运维等相关的操作，也无需对一些软件的安装，应用资源的扩缩容进行额外的精力支出，开发者所需要关注的仅仅是自身的业务逻辑，至于在传统架构下需要安装配的各种服务器软件等，均变成配置项交给云厂商来管理，同样，传统架构下需要根据服务器的利用进行资源的扩缩行为，也全都自动化的交给云厂商来实现。在整个Serverless工作的流程中，不难发现FaaS平台实际上会作为计算资源，承载着诸多核心能力，包括不限于执行开发者的业务代码，自动进行资源的扩缩等操作，那么Serverless架构中的FaaS平台是什么样子的呢？通常情况下一个简化的Faas系统分为APIServer，Scheduler，ResourceManager，NodeService，ContainerService一共有5个组件。如上图所示：APIServer往往对外暴露整体能力的API服务，例如invokeFunction的功能等；Scheduler模块用于管理系统的Container，例如APIServer通过Scheduler获得可以执行Function的Container；ResourceManager模块用来管理系统里的Node，负责申请和释放，可以认为Node对应于虚拟机，占用虚拟机需要一定的成本，因此Scheduler的一个目标是如何最大化的利用Node，比如尽量创建足够多的Container，不用的Node应该尽快释放。当然申请和释放Node又需要一定的时间，造成延迟增加，Scheduler需要平衡延迟和资源使用时间；NodeService管理单个Node上创建和销毁Container，Node可以认为是一个虚拟机，Scheduler可以在Node上创建用于执行Function的Container；ContainerService用于执行函数；正是这些组件或者模块的联动，才得以让FaaS平台可以为应用提供更为稳定、安全，性能更高的技术支持；对FaaS平台的组成结构有了初步了解之后，可以进一步探索一下FaaS平台的工作流程。如上图所示，当开发者把代码和配置交付到FaaS平台之后，FaaS平台并不会按照用户的预定配置进行资源的分配，而是会将这一部分的内容进行持久化。只有请求到来时，FaaS平台才会根据真实流量进行资源的分配。从FaaS平台接受到函数调用或者被触发的请求时，到函数正式执行并反馈最终结果，粗略的可以认为是两个过程。容器&Runtime准备阶段：这个阶段主要是进行相关的资源准备，例如某些计算资源的准备，某些网络资源的准备等，准备好这些资源之后，系统会根据用户的函数进行相对应的代码的下载，然后在进行实例的启动；这个过程通常也可以认为是冷启动的过程；函数执行阶段：函数执行阶段指的是实例启动之后，函数代码进行初始化以及指定方法执行的过程。当然，在某些开发者眼中，或者某些平台的定义中，代码初始化的过程往往也会被算作是资源准备阶段；当函数执行完成之后，返回了结果之后，就意味着本次触发已经完成。此时函启动的实例通常会有三种处理方案：实例会被搁置一段时间，如果搁置的这段时间内，没有被分配处理新的触发请求，实例会被释放掉；实例会被搁置一段时间，但是在搁置的这段时间内，被分配处理新的触发请求，此时实例会处理新的触发请求；实例由于一些特殊的配置，被标记为长期活跃实例，即使被搁置很久（超过释放的时间阈值）也不会被释放；通过上面所表述的三种处理方法，不难发现实例是可能存在被复用的情况，所以函数在被触发的时候，通常也可能会有两种可能：当前时间段，并没有已经准备好且可以被利用的实例（例如函数的首次调用/触发），此时FaaS平台会全新启动实例，包括容器&Runtime准备以及函数执行等；当前阶段，有已经准备好且可以被利用的实例（例如上述函数执行完成的三种情况中的2，3情况），此时FaaS平台会优先复用已存在的实例，以避免再次进行容器&Runtime准备而浪费时间，提升请求效率，降低请求时延；由此也可见，Serverless架构之所以被认为是天然分布式架构，其原因是Serverless架构的模型实现，是请求级别的隔离，可以认为每次请求都可能会出现一个实例（部分厂商提供的单实例多病发的情况除外），即同一时间段的请求数量会和实例数量成正相关。除此之外，还值得注意的是，Serverless应用是由事件驱动的，即FaaS平台中的函数是由事件触发的，事件的产生者按照某些规范描述不同的事件，并以参数的形式在调用函数指定方法时，传递给函数。所以事件生态也是影响Serverless架构应用领域、应用场景的重要影响因素。如上图所示，按照CNCF白皮书中的规范，FaaS平台可以根据不同的用例从不同的事件源调用函数，例如：同步请求（Req / Rep），例如HTTP请求，gRPC调用客户发出请求并等待立即响应。异步消息队列请求（发布/订阅），例如RabbitMQ，AWS SNS，MQTT，电子邮件，对象（S3）更改，计划事件（如CRON作业）消息发布到交换机并分发给订阅者；没有严格的消息排序，以单次处理为粒度。消息/记录流：例如Kafka，AWS Kinesis，AWS DynamoDB Streams，数据库CDC一组有序的消息/记录（必须按顺序处理）；通常，每个分片使用单个工作程序（分片消费者）将流分片为多个分区/分片；可以从消息，数据库更新（日志）或文件（例如CSV，Json，Parquet）生成流；事件可以推送到函数运行时或由函数运行时拉动。批量作业，例如ETL作业，分布式机器学习，HPC模拟作业被调度或提交到队列，并在运行时使用并行的多个函数实例进行处理，每个函数实例处理工作集的一个或多个部分（任务）当所有并行工作程序成功完成所有计算任务时，作业完成综上所述，将Serverless架构工作原理用一张图完整表示，可参考下图：

1.1.2 概念定义云计算飞速发展的十余年，整个互联网也发生了翻天覆地的变化，作为被UC Berkeley认为是云计算下一个十年的Serverless架构，被很多开发者认为是“实现了云计算最初的梦想”，那么Serverless架构到底是什么呢？其实，Serverless架构与云计算、云原生的情况类似：Serverless架构到底是什么，在不同的人心中也是有着不同的答案的。如上图所示，从目前的认可度来看，Serverless架构可以从狭义与广义两个角度进行探索与分析：从狭义上来看，Serverless架构是FaaS与BaaS的结合；从广义上来看，Serverless架构表示的是服务端免运维的一种形式，一种思想；狭义定义Martin Fowler在Serverless Architectures一文中认为Serverless实际上是BaaS与FaaS的组合，而这一说法也是被最为广泛认可的一种说法。所谓BaaS，就是Backend as a Service（后端即服务），指的是服务商为客户(开发者)提供整合云后端的服务，如提供文件存储、数据存储、推送服务、身份验证服务等功能，以帮助开发者快速开发应用；所谓FaaS，指的是Function as a service（函数即服务），即服务商提供一个平台，允许客户开发、运行和管理应用程序功能，而无需构建和维护通常与开发和启动应用程序相关的基础架构的复杂性，典型的产品包括AWS的Lambda，阿里云的函数计算（FC），腾讯云的云函数（SCF）等。除此之外，CNCF在CNCF WG-Serverless Whitepaper v1.0中也对什么是Serverless架构进行了进一步的描述，CNCF认为：“Serverless是指构建和运行不需要服务器管理的应用程序概念。它描述了一种更细粒度的部署模型，其中将应用程序打包为一个或多个功能，上传到平台，然后执行、扩展和计费，以响应当时确切的需求”。同时CNCF在白皮书中也强调了：Serverless所谓的“无服务器”并不是“没有服务器”，而是说Serverless的用户不再需要在服务器配置、维护、更新、扩展和容量规划上花费时间和资源，将更多的精力关注到业务逻辑本身，至于服务器，则“把更专业的事情交给更专业的人”去做，即由云厂商来提供统一的运维。在2019年UC Berkeley的文章Cloud Programming Simplified: A Berkeley View on Serverless Computing中，作者对Serverless架构的定义进行了进一步的完善和表达，首先作者肯定了Serverless架构是FaaS与BaaS的结合，除此之外，作者认为：在对于被认为是Serverless的服务，它必须具备弹性伸缩和按量付费的特点。广义定义云计算的发展是飞速的，Serverless架构也在不断迭代升级，不断的进行演进，在随着时间发展的过程中，很多人逐渐发现了Serverless架构不应该是狭义的认为是FaaS与BaaS的结合，而是需要进一步泛华，即符合服务端免运维的这种架构，就可以认为是Serverless架构。在信通院云原生产业联盟所发布的《云原生发展白皮书（2020年）》中对Serverless是什么有这样的一段描述：无服务器（即Serverless）是一种架构理念，其核心思想是将提供服务资源的基础设施抽象成各种服务，以 API 接口的方式供给用户按需调用，真正做到按需伸缩、按使用收费。这种架构体系结构消除了对传统的海量持续在线服务器组件的需求，降低了开发和运维的复杂性，降低运营成本并缩短了业务系统的交付周期，使得用户能够专注在价值密度更高的业务逻辑的开发上。可以看到，Serverless架构一面可以精确的定义成是FaaS与BaaS的结合，另一面则可以广义的看成是一种思想：一种具备弹性伸缩和按量付费特性的架构思想；一种服务端免运维或者低运维的思想；于是广义的Serverless产品，就逐渐的逐渐如雨后春笋般发展起来，以应用托管的Serverless产品或服务为例，就有阿里云的Serverless应用引擎，Google的CloudRun等。综上所述，或许在2019年的时候，UC Berkeley的文章中或认为某些形态的Serverless产品或者服务，“违背了Serverless精神”，但是事实上，不可否定的是，随着技术的迭代升级，随着用户需求的不断驱动，技术的发展会逐渐的更为泛化。事实也证明，如今广义的Serverless架构概念，已经被更多人更多的厂商逐渐的接受和认可，Serverless架构的形态和未来的机会，也在不断的发生改变。

从IaaS到FaaS再到SaaS，再到Serverless，云计算的发展在近十余年中发生了翻天覆地的变化，从虚拟空间到云主机，从自建数据库等业务到云数据库等服务，云计算的发展是迅速的，Serverless架构也被诸多人寄予厚望，或许Serverless架构正当时，其已然开启从概念到实践的大规模落地之路，正如 Gartner 报告中的预测，到 2025 年，全球一半的企业将采用 FaaS 部署；或许，时至今日的Serverless架构，依旧不是最终形态的的Serverless架构；或许Serverless的精神也需要进一步的建设和完善，但是不可否定的是，Serverless架构都正在：More and more energetic, more and more fast and powerful.Serverless架构迅速发展的过程，其实也映射着云计算领域前进的方向，本节将会通过对Serverless架构的发展历程介绍、概念规范进行探索以及工作原理的研究，生态发展的分析，对Serverless架构进行基础的学习和了解。1.1.1 发展历程自1961年约翰·麦卡锡（1971年图灵奖获得者）在麻省理工学院百周年纪念典礼上第一次提出了“Utility Computing”概念：“计算机在未来，将变成一种公共资源，会像生活中的水、电、煤气一样，被每一个人使用”，云计算的“最初的”，“超前的”遐想模型，就逐步的诞生；经历过1984年，SUN公司联合创始人John Gage（约翰·盖奇）提出“网络就是计算机（The Network is the Computer）”的重要猜想，用于描述分布式计算技术带来的新世界，到1996年，康柏（Compaq）公司的一群技术主管在讨论计算业务的发展时，首次使用了Cloud Computing这个词，并认为商业计算会向Cloud Computing的方向转移。这也是“云计算”从雏形到正式被提出的基本过程。伴随着云计算概念的逐渐完善，云计算的技术也逐渐的完善起来，2003年到2006年间，谷歌发表了The Google File System、MapReduce: Simplified Data Processing on Large Clusters 、Bigtable: A Distributed Storage System for Structured Data等论文，这些论文指明了HDFS（分布式文件系统），MapReduce（并行计算）和Hbase（分布式数据库）的技术基础以及未来机会，至此奠定了云计算的发展方向；随着云计算的飞速发展，因云而生的产品，技术也越来越多，于是Pivotal公司的Matt Stine在2013年首次提出云原生（CloudNative）的概念；随后的2015年云原生计算基金会（CNCF）成立，并为最初的云原生定义范围：容器化封装、自动化管理、面向微服务；到了2018年，CNCF更新了云原生的定义，把服务网格(Service Mesh)和声明式API给加了进来。直到今天，如图所示，云原生的战略版图越来越宏伟，覆盖的产品越来越多，覆盖的领域也越来越完整。有人说，因云而生的软件、硬件、架构，就是真正的云原生；因云而生的技术，就是云原生技术。确实如此，出生于云，成长在云，因云而生，或许就是真正意义上的云原生。在云原生技术发展前后，云计算领域又有一个新的概念诞生，那就是Serverless架构，一个主张降本提效的技术范式，一个主张业务聚焦，把更专业的事情交给更专业的人，开发者可以付出更多精力在自身的业务逻辑上的技术架构。2012年，Iron.io的副总裁Ken Form在文章Why The Future of Software and Apps is Serverless中，提出了一个新的观点：“即使云计算的已经逐渐的兴起，但是大家仍然在围绕着服务器转。不过，这不会持续太久， 云应用正在朝着无服务器方向发展，这将对应用程序的创建和分发产生重大影响”。并首次将“Serverless”这个词带进了大众的视野。2014年Amazon发布了AWS Lambda让“Serverless”这一范式提高到一个全新的层面，为云中运行的应用程序提供了一种全新的系统体系结构，至此再也不需要在服务器上持续运行进程以等待HTTP请求或API调用，而是可以通过某种事件机制触发代码执行，通常这只需要在AWS的某台服务器上配置一个简单的功能。2015年，在AWS的re:Invent大会上，Serverless的这个概念更是反复地出现，其中包括了The Serverless Company Using AWS Lambda和JAWS：The Monstrously Scalable Serverless Framework的这些演讲。随着Serverless这个概念的进一步发酵；此外，Ant Stanley 在2015年7月名为Server are Dead…的文章中更是围绕着AWS Lambda及刚刚发布的AWS API Gateway这两个服务解释了他心目中的Serverless，并说Servers are dead … they just don't know it yet.2016年10月在伦敦举办了第一届的ServerlessConf，在两天时间里面，来自全世界40多位演讲嘉宾为开发者分享了关于这个领域进展，并且对未来进行了展望，提出来了Serverless的发展机会以及所面临的挑战，这场大会是针对Serverless领域的第一场具有较大规模的会议，在Serverless的发展史上具有里程碑的意义。2017年，各大云厂商基本上都已经在Serverless进行了基础的布局，尤其是国内的几大云厂商，也都先后在这一年迈入“Serverless时代”。同年，CNCF Serverless WG成立了，并且开始以社区的力量推动Serverless快速前行，包括CNCF Serverless Whitepaper、CloudEvents等相关的立项研究与探索，2017年年末，eWEEK的Chris J. Preimesberger发表文章Predictions 2018: Why Serverless Processing May Be Wave of the Future来表达在“全新的阶段下”大家对Serverless的看法和期盼。2018年，Serverless的发展速度要比想象中的更加快速，在这一年，Google 发布了 Knative， 一个基于 Kubernetes 的开源 Serverless 框架，具备构建容器、流量调配、弹性伸缩、零实例、函数事件等能力。AWS 发布了 Firecracker，一个开源的虚拟化技术，面向基于函数的服务，创建和管控安全的、多租户的容器。Firecracker 的目标是把传统虚拟机安全性和隔离性，和容器的诉求，资源效率结合起来。在这一年，CNCF也正式发布了Serverless领域的白皮书：CNCF Serverless Whitepaper V1.0，阐明Serverless技术概况、生态系统状态，为 CNCF 的下一步动作做指导，同时CloudEvnent规范，进入CNCF Sandbox；同样在2018年，全球知名IT咨询调研机构Gartner发布报告，将Serverless Computing列为十大未来将影响基础设施和运维的技术趋势之一。2019年开始，Serverless进入到了一个真正意义上的生产应用，最佳实践快速发展阶段而2019年对Serverless而言是非常关键的一年，也是Serverless具有里程碑式发展的一年，被很多人定义为“Serverless正式发展的元年”。在这一年不仅有KubeCon在中国上海的CloudNativeCon中关于Serverless的“海量主题演讲”，这些演讲包括来自Captial One银行的Kevin Hoffman的WebAssembly、无服务器和云，IBM的Doug Davis的CNCF CloudEvents项目：迈向无服务器互操作的一步等；同年，UC Berkeley在论文Cloud Programming Simplified: A Berkeley View on Serverless Computing表示“Serverless 计算将会成为云时代默认的计算范式”。2020年，CNCF 发布了2020年度中国云原生调查报告，在报告中明确显示Serverless 正在持续增长，31% 的单位在生产中使用无服务器，41% 在评估，12% 计划在未来12个月使用；同年，Flexera 2020年云状况报告称，Serverless是2020年增长最快的五项PaaS云服务之一；与此同时，Forrester 认为，Serverless 计算的兴起，让 FaaS（Function As A Service）成为继 IaaS、PaaS、SaaS 之后一种新的云计算能力提供方式。预计 2021 年，将会有大量主流企业的核心应用，从原来的主机架构迁移到 Serverless。随着时间的发展，Serverless架构逐渐从2021年，Serverless架构在权威咨询机构 Forrester 发布的The Forrester Wave™: Function-As-A-Service Platforms, Q1 2021中，开始了新一年的蓬勃发展，在这个报告中，不仅对全球主流的Serverless平台，进行了相对应的评测，对过去的技术发展进行了更为科学的总结，同样也对未来的规划、产品的发展视野进行了展望和探索，作为未来十年云计算的重要趋势之一，Serverless架构已经展示出不俗的潜力。Forrester 认为，Serverless 计算的兴起，让 FaaS（Function As A Service）成为继 IaaS、PaaS、SaaS 之后一种新的云计算能力提供方式。预计 2021 年，将会有大量主流企业的核心应用，从原来的主机架构迁移到 Serverless。至此，云计算的发展逐渐从IaaS，到PaaS，向Serverless架构升级过渡，同样，Serverless架构也逐渐的从鲜为人知，开始走进寻常百姓家。从2012年，Serverless概念被正式提出之后，2014年AWS带领Lambda开启了Serverless的商业化，再到2017年各大厂商纷纷布局Serverless领域，再到2019年，Serverless成为热点议题在KubeCon中被众多人参与探讨，UC Berkeley发文断言Serverless将引领云计算的下一个十年，Serverless随着时间的不断推进，各种技术部的不断进步，正在逐渐地朝着更完整，更清晰的方向发展，随着5G时代的到来，Serverless将会在更多领域发挥至关重要的作用。

最开始其实还是有点忐忑的 但是跟着实验指导书一起发现实验并不难，并且学到了不少东西​在这里已经将index.js文件复制到了对应的窗口中，一定要注意不要复制错误了在点击测试之后，返回到日志即可查看情况，一定要刷新一下，不然可能看不了这是最后完成了，查看网页的界面，还是有点小成就感的

完成实操截图实践一：10分钟开发我的个人主页实践二：OBS自动化文件解压实践三：定时拨测场景学习笔记Serverless直译为中文是“无服务器”，但是实际上它仍需要服务器，只不过服务器的管理以及资源分配部分对用户不可见，为避免误导读者，译文中还是将英文保留。最开始，一台单用户的物理服务器便能满足我们的日常所需，它快速，可靠并且安全，只对管理员负责。但是在实际中配置和扩展都很麻烦。虚拟机的出现满足了灵活性和可扩展性的需求，之后云服务提供商为我们带来了基础架构即服务（IaaS），云平台自助服务也由此诞生。在这片肥沃的土壤中出现AWS（Amazon Web Services），编排，以及基础设施即代码（IaC），之后开始了集装箱化，带来了平台即服务（PaaS）的架构，一切看起来都很顺利......但程序员仍想要更多的功能，如独立于编程语言（language agnostic）的端点，服务器的水平伸缩能力，以及可以实时支付服务使用量的能力。为了满足这些需求，Serverless计算应运而生，Serverless计算也被称为功能即服务（FaaS）。运行时只会执行程序但不会存储数据。这意味着像AWS（Amazon Web Service），谷歌云以及微软Azure云这样的云服务提供商会动态的管理资源的分配和分布。Serverless是付完即走，基于实际的消费而不是基于预测的预付款进行收费的。这本是基础设施应该有的样子，在2018年终于出现在我们面前。

三个实践做下来能较全面地体验实现serverless需要的步骤。实践一：10分钟开发我的个人主页这个代码是静态页面，实现一个静态网站的访问 。部署和测试比较简单，教学文档也很清晰。实践1完成！实践二：OBS自动化文件解压这个主要 实现在一个obs桶上传压缩文件，在另一个obs桶输出解压后的文件。如果转换失败，需要看日志，确认参数有没有配置错误。实践2完成！实践三：定时拨测场景这个主要实现定时测试url等通不通，代码的第三个url是不存在的，所以会发告警到短信或者邮箱。告警间隔是自己设置的3mins实践3成功！

完成实操截图实践一：10分钟开发我的个人主页实践二: OBS自动化文件解压实践三:定时拨测场景学习笔记“Serverless 计算将会成为云时代默认的计算范式，并取代 Serverful（传统云）计算模式。”Serverless作为一种新的开发范式，软件的架构也一定随着这种新范式的出现而做出对应的变化。传统的单体是个完全封闭的架构，业务模块耦合，牵一发而动全身。微服务架构采用标准的接口来解耦各个业务模块，通过容器技术也使得开发更有效率，但是开发者仍需要关注容器的部署位置，需要Devops的紧密联动。Serverless的架构进一步让开发者回归业务本质，免去非业务相关的运维，通过函数的方式来构建应用，使得应用解耦的颗粒度更小。Serverless 带来的业务价值主要体现在三个方面：更轻量化：用户专注于业务创新和代码开发，代码运行环境由云平台提供，无需管理基础设施资源。更快弹性：根据请求的并发数量自动调度资源运行函数，毫秒级弹性伸缩，高效应对业务峰值。更低成本：根据函数调用次数、运行时长和节点转换次数计费，函数不运行时不产生费用，更加节省成本。

获奖公示恭喜以上获奖小伙伴，礼品将于5月6日前安排发放~请留意“华为云PaaS小助手”论坛私信或企业微信私信（添加小助手微信请备注“中奖华为云账号名+DevStar体验活动领奖”）活动详情DevStar是啥？是基于模板快速开发云应用的开发平台，提供丰富的应用模板和一站式创建代码仓、生成框架代码、集成中间件以及建立DevOps流水线等能力，让开发无须从零开始，效率得以大幅提高。本任务10分钟带你上手一个实践 — 如何基于DevStar模板开发serverless应用，并带你斩获“华为云高校实习生技能大比拼”活动的10积分，还有50元京东卡等你赢取活动截止时间：2022/4/24（与主线活动同步） 规则1、点击这里获取指导书2、按照指导书成功完成体验后，将部署截图（示例见置顶评论，需露出华为云账号首尾部分字符，以便辨别不同账号）和识别结果截图在本帖回复。（完成到此就斩获积分啦）3、新增额外福利：进产品体验交流群还可以参与抽50元京东卡等福利活动，具体细则群内公示，快进群吧PaaS产品体验大本营附则：论坛活动通用规则   1）请务必使用个人账号参与活动（IAM、企业账号等账号参与无效）。2）严禁灌水，严禁带有色情、政治、宗教、推广、外链广告内容，严禁抄袭、复制他人内容，一经发现，取消中奖资格。3）请确保您邀请的用户为真实有效的用户，如发现存在恶意注册、恶意邀请等行为（“恶意”是指为获取奖励资格而异常注册账号等破坏活动公平性的行为），我们将取消相关人员获奖资格。同时，将对该账号进行禁言禁止参与社区活动3个月的处罚，行为严重的将对账号进行永久封号。4）获奖用户需在华为云进行实名认证，同一身份信息只能获奖一次。5)对于严重违反活动规则的用户，将纳入社区失信黑名单，取消获奖资格，并做封号处理。6）所有参加本活动的用户，均视为认可并同意遵守《华为云用户协议》《华为云社区运营机制》。其他未尽事宜请参考：1、华为云社区常规活动规则：https://bbs.huaweicloud.com/forum/thread-5766-1-1.html2、所有参加社区活动的开发者用户，均视为认可并同意遵守《华为云开发者用户协议》，包括以援引方式纳入《华为云开发者用户协议》的《可接受的使用政策》、《法律声明》、《隐私政策声明》、相关服务等级协议（SLA），以及华为云服务网站规定的其他协议和政策（统称为“云服务协议”）的约束。云服务协议链接的网址：http://www.huaweicloud.com/declaration/sa_cua.html如您不同意以上活动规则及相关条款，请勿参加论坛相关活动。

本文分享自华为云开发者社区《[CNCF Serverless工作流社区携手华为云FunctionGraph，开拓Serverless编排新时代](https://blog.csdn.net/devcloud/article/details/123323056?spm=1001.2014.3001.5501)》，作者： 技术交流。 企业应用从微服务架构向Serverless（无服务器）架构演进，开启了无服务器时代，面向无服务器计算领域的Workflow也应运而生。CNCF为了给业界提供一种标准方法，建立100%由社区贡献者驱动的Serverless Workflow开源社区，携手社区伙伴，以更全面的规范、更丰富的元素，赋能企业产品化，并有效解决厂商锁定等问题，推进无服务器计算领域的发展。 华为云作为CNCF Serverless Workflow社区的官方合作伙伴，联合2012实验室华为元戎团队在函数工作流优化、版本兼容等多方面提供了优质高效的改进建议。在2021年10月的KubeCon NA 2021（North America）活动中，Tihomir Surdilovic社区领导人介绍了CNCF Serverless Workflow的开源合作伙伴，华为是2021年度CNCF Serverless Workflow 社区贡献排名榜前五中唯一的国内厂商。 # 工欲善其事，必先利其器 许多Serverless应用程序是由系列函数组成，这些函数可能会根据不同的事件触发器依次执行、并行执行或在分支中执行，我们称之为函数工作流。为了使Serverless 平台正确执行 Serverless 应用程序的函数工作流，应用程序开发人员需要对系列函数进行编排，如何支持应用开发人员简单快速进行函数编排，需要定义一套完整、易用的工作流规范。 就像在微服务架构中，只需要编写Workflow定义的JSON，就可以完成对不同业务流程的调度、编排与自动化，同时国际工作流管理联盟（Workflow Management Coalition，WfMC）还对微服务的Workflow定义了一套完整的参考规范，以使不同厂商的微服务工作流产品之间可以平滑地交换工作单元。 当下，Serverless大行其道，各个大厂纷纷下场布局。Workflow作为其工具链中的一部分，每个厂商都有一套自己的服务接口，当某一厂商暂停服务或者用户想要更换厂商时，这种各自为政的模式导致用户陷入被厂商锁定、移植困难、成本高甚至需要重构系统的艰难境地。 因此，如同WfMC为微服务的Workflow定义参考规范一样，Serverless Workflow也急需一种完整的标准方法和参考规范来打破各大厂商闭门造车的局限。 # 集众人之长，成Serverless之利 为了给业界提供一种标准方法，CNCF在2020年7月成立了Serverless Workflow 社区，与社区贡献者一起共同构建、完善Serverless Workflow 规范，以促进Serverless应用程序在不同厂商平台之间的可移植性。该社区的开源项目包括：基于DSL的工作流规范、为编程语言提供SDK等，同时与CNCF其他项目也有深度的合作，比如CloudEvents, OpenAPI等。 CNCF Serverless Workflow规范针对无服务技术领域，所以关注点会在事件驱动应用、函数或微服务。CNCF Serverless Workflow规范是一种用于微服务、事件和函数编排的工作流语言规范，可以通过YAML或JSON的格式描述和定义工作流，具有以下优势： **基于通用的、声明式的思想提炼语言，更容易表达** 目前，工作流语言分为四个类型（如下图所示），CNCF Serverless Workflow 规范是一种基于通用的、声明性的思路提炼出的工作流规范，且支持通过YAML或JSON的格式描述和定义工作流，更容易表达像functions, events, retries这些无服务器技术领域的元素。  四类工作流语言 **支持强大的、业界通用的控制流逻辑** CNCF Serverless Workflow规范本身提供了非常强大的控制流逻辑，包括了大多数业界支持的核心功能，如顺序执行，以便用户可以定义流水线。在顺序执行的基础上，用户也可以定义并行的执行，如并行调用函数或微服务。另外，也支持使用不同种类的循环结构执行数据库循环调用之类的工作流。此外，重试、错误处理、工作流的手工干预，还有诸如等待和恢复之类的标准能力都被CNCF Serverless Workflow的规范所支持。 为解决实践中业务级的问题，CNCF Serverless Workflow规范增强了诸多重要功能： - 自动重试、密钥和常量； - 定义可插拔的表达语言，以便用户可以插入自己选择的表达语言； - 不同类型的超时，如全局超时或分支超时等； - 短时和长时工作流的支持； - 工作流执行期间的补偿处理，如撤销已经成功完成的工作或状态； - 休眠，如等待某种事件或状态。 此外，CNCF Serverless Workflow规范还提供了继续属性的功能，针对工作流在达到云平台运行限制后被迫停止，用户可以编排继续属性，停止当前工作流实例，启动新的工作流实例执行停止前的状态。  工作流逻辑说明图示 **提供自定义拓展能力** 除了上述核心的控制流逻辑，CNCF Serverless Workflow规范也提供了自定义扩展能力。目前社区规范提供两个拓展：关键性能指标和限流。 用户可以通过关键性能指标的扩展能力（如工作流的整体指标、事件的消费与生产指标、函数使用指标、工作流状态指标等）定义工作流，使用自定义指标衡量工作流的性能，对性能和成本进行增强。此外，用户也能够通过限流的拓展能力对调用进行速率的限制，这在无服务器领域尤为重要，比如函数调用并发的限制、调用事件数量的限制、工作流状态总数的限制、工作流执行期间转换的限制等。  拓展能力说明图示 **功能更全面，能支持更多复杂场景** CNCF Serverless Workflow Specification支持更多元素，比如：CloudEvent、OpenAPI、AsyncAPI、GraphQL、gRPC等开源事件和服务标准的集成。 - **在功能方面**，支持建模人工决策、定义超时和重试、定义并行执行逻辑和循环、做出基于数据或事件的决策、定义回调、编写强大的表达式、设置秘密和常量等。 - **在应用方面**，支持广泛的复杂场景，比如：网上车辆拍卖、网上订餐、付款处理、数据分析、错误通知、持续集成和部署等。 所以CNCF Serverless工作流规范更加全面，能支持更多复杂场景，也具备产品化更多新特性的潜力。基于CNCF Serverless Workflow 规范本身的优势，不仅能有效避免厂商锁定，也能助力企业创新。目前，已有国内外企业关注并使用此规范产品化。 # CNCF群策群力，华为云竭诚尽智 从KubeCon NA 2021大会发布的各项数据可以看出，当前社区处于初期快速的成长阶段。2021年全年，10多家不同公司参与社区贡献，社区整体取得了显著的成就，工作流规范也已更新至0.8版本。 社区在2021全年总共有500合入的PR、2K commits， CNCF Serverless Workflow Specification有超过200个新星关注的增长，去年实现了新星关注的100%增长，同时，社区的各类社交平台也受到广泛关注。在2021年KubeCon EU大会中，共计300+人参与CNCF Serverless Workflow项目的办公时间；190+人参加了2021年KubeCon NA北美大会社区项目的办公时间。 作为社区官方合作伙伴，以及CNCF Serverless Workflow的开源合作伙伴，华为云联合2012实验室华为元戎团队，提供持续的技术能力支撑，主要贡献包括： 1. Action支持重试和错误处理已合并到0.7版本； 2. 支持分支内部进行编排的想法，已被社区采纳，并规划在0.9版本中实现； 3. 发现并提出规范版本之间兼容性不足的问题，社区确认从0.8版本之后会确保向后兼容； 4. 帮助社区在0.7和0.8版本的发布做出了贡献，包括审查与规范相关的设计文档，审阅社区新提交的PR（拉取请求）和Issue. 作为 CNCF Serverless Workflow 社区官方合作伙伴，华为云与社区伙伴携手并进，共同推动无服务器计算领域的发展。 # FunctionGraph Workflow——更上一层楼 在繁荣向上的社区生态中，华为云以CNCF Serverless Workflow 规范为标准，联合2012实验室华为元戎团队共同打造了华为云FunctionGraph Workflow，为用户提供函数流管理功能，并支持可视化拖拽式的函数编排。 在使用FunctionGraph Workflow时，用户无需进行二次开发，只要通过可视化拖拽的方式，即可将多个独立的无服务器函数用顺序、分支、并行等方式轻松快速地编排一个完整的应用。  FunctionGraph Workflow 可视化编排示意图 同时，FunctionGraph Workflow提供监控和管理平台，用于诊断和调试应用，支持跟踪每次执行的状态，执行中的输入输出等，快速定位故障，用户可以轻松配置重试，处理异常分支。  FunctionGraph Workflow 监控管理平台示意图 目前，FunctionGraph Workflow 已应用于事务型业务流程编排、多媒体文件处理、数据处理流水线等场景。面向未来，华为云期望通过不断的技术突破，将华为云开源引擎打造为 CNCF Serverless Workflow 社区的默认实现，形成应用社区 Serverless Workflow规范产品化案例，并在社区内部共享。

原文链接：https://bbs.huaweicloud.com/blogs/335406NodeJS 后端开发09 多环境Profiling优雅根据不同环境自适应学委好久没有更新NodeJS专栏，还以为NodeJS冷门，没想到最近看到几个读者留言问怎么优雅的管理多环境的配置。太忙了，写篇短文简单展示一下原理。正好基于前篇 【NodeJS 后端开发 07 MySQL数据库连接池开发生产应用 】简单尝试了mysql库来连接数据库。本篇尝试一个更加优雅的方式，通过环境变量来控制程序动态加载不同的配置。这个搞Java的同学最清楚，比如我们开发springboot应用的时候会放置多个application.yml。然后部署的时候通过环境变量来选择配置。这个用NodeJS来做就更加简单了NODE_ENV=process.env.NODE_ENV console.log('NODE_ENV:', NODE_ENV)直接贴在node REPL 终端查看：process对象为Node上下文的内置对象，可以直接获取，这个对象管理了node进程相关的数据。比如 process.env就是我们获取环境变量设置的入口了（读者可以自行打印查看更多信息）。配置一个环境变量，重试代码export NODE_ENV=雷学委打开node的终端这里我们看到，设置的环境变量被进程内部读取到了。继续根据环境自适应的profiling。上面展示了设置不同变量代码中能够获取到该环境变量的值。安照这个机制，我们可以把配置文件按照下面进行命名，让程序加载不同的文件名，比如下面：[ ] config.dev.json[ ] config.testing.json[ ] config.prod.json然后只需要写一份应用代码：复制下面代码保存为app.js//雷学委Demo代码 const NODE_ENV=process.env.NODE_ENV || 'dev' console.log('NODE_ENV:', NODE_ENV) //定位当前目录下的config.<环境类型>.json const configPath = __dirname + '/config.' + NODE_ENV + '.json' console.log('configPath:', configPath) //加载并打印数据库的配置细节 const dbConfig = require(configPath) console.log('dbConfig:', dbConfig)运行代码在这：#开发环境启动应用 node app.js#测试环境启动应用 export NODE_ENV=testing && node app.js#生产环境启动应用 export NODE_ENV=prod && node app.js很轻松吧，一份代码根据不同的环境适配了。实际运行应用app.js的服务器，上面会配置环境变量NODE_ENV为对应的dev/testing/prod值。上面代码仅为原理展示。好了到这里读者应该能够懂得profling如何做了。（可以三连了）下面看看为什么。为啥搞这么多外部配置，直接写在代码里面根据主机名字加载不好么？一般企业会有大量的服务器，然后会把服务器划分为几类，比较典型的划分为：很多中大公司会有下面这样一个划分：这样能够把一个应用层层把关提拔到最上层的生产环境（production）。学委想对小白说的： 比如说一个游戏的新功能，往往会经过开发机器调试，然后大量测试，把大量的潜在的重要的bug解决了，提拔到预发布，最后到生产环境。这个过程通过一些列的自动化测试，回归测试，可以大大保证系统的质量。还有一种高端玩法就是灰度发布，加上这个制度，这就是我们常说产品平滑上线的流程了。这好像扯远了，产品发布这一套能再写亿篇！我们回到主题，通常就是只开发一份代码，发布到不同环境之后，程序动态的连接到正确的数据库，加载对应的数据，数据虽不同但是程序在任意环境的行为要绝对一致。这里配置外部化考量是：配置外部化可以减少代码跟环境的耦合而不是发布一个类型的环境，就得修改代码。特别是互联网/金融项目都会有严苛的质量把关，哪怕是修改一个标点符号，整个产品提升的过程都得从开发环境重新来过。因此，配置外部化很有必要。那么，应用能否跟外部环境毫无关联？比较有经验的朋友，可能会想匿名函数，或者亚马逊的lamda，或者serverless app（无服务器应用）如果业务没有任何环境区分，那就可以做到程序跟环境没有耦合，这就充分的说明了serverless的一个优点！（没有耦合，意味着随便拿一个云服务器部署，即可轻松实现弹性伸缩了，但这并非此文出发点，有机会再说）对了，学委还有这个可以关注长期阅读 =>雷学委趣味编程故事汇编或者=> 雷学委NodeJS系列持续学习持续开发，我是雷学委！编程很有趣，关键是把技术搞透彻讲明白。创作不易，请多多支持，点赞收藏支持学委吧！更多代码可以查看/Star： LearnNodeJS代码下载

>摘要：Serverless将是微服务的“封顶之作”，也是推动应用现代化的基石。本文分享自华为云社区《[【深入浅出，Paas之路】华为云.云享专家曹宗南： Serverless，引领云计算下一个阶段](https://bbs.huaweicloud.com/blogs/325811?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)》，作者： 我们都是云专家 。 2009 年，伯克利以其独特的视角发布了一篇文献，正式定义了云计算。自此，千行百业的 IT 基础设施开启上云之路。 2019年，伯克利在《Cloud Programming Simplified》预言： “Serverless计算将会成为云时代默认的计算范式，并取代Serverful（传统云）计算模式。” 2009-2019年，互联网技术飞速发展。在这期间，出于对计算机技术的兴趣，曹宗南大学期间选择了计算机专业，之后便开启了他的技术开发生涯。 只要对开发有所了解，都知道程序员和开源是密不可分的，曹宗南亦是如此。毕业之后的一次项目中遇到数据库开发相关的瓶颈，他在经过一番查询，发现开源项目分布式数据库中间件Mycat能够完美的解决遇到的问题。他表示，Mycat在使用的过程中，后端可以挂接N个普通的MySQL数据库，数据可以按照多种规则进行分布，对外表现的却像一个MySQL实例一样来使用，业务代码不需要做大的改动。  自此，曹宗南便对MySQL产生了极大的兴趣，逐渐的也从使用者到开源的贡献者。陆续给Mycat贡献了多数据库后端支持、动态平滑扩容、分片算法、压缩协议等多个核心特性，还参与Mycat线下技术峰会的演讲。“对Mycat源码也熟悉的像自己的掌纹一样清楚。”曹宗南说道。 # 触摸新技术时代的网红Serverless 在谈及现在的工作内容中，曹宗南提到了Serverless技术。正如开篇所提到伯克利在《Cloud Programming Simplified》中的预言，Serverless将成为云计算的下一代默认计算范式。 曹宗南解释道，Serverless架构是在微服务架构基础上的进一步延伸，按照业界通常的定义，Serverless = FaaS(Function as a Service) + BaaS(Backend as a Service)。相比微服务，FaaS将资源调度的粒度缩小到函数，针对无状态、短时处理任务，通过函数式编程方式，进一步降低了应用开发门槛，缩短了应用上线周期。 为了更好的便于理解，曹宗南从三个典型场景，解读了Serverless架构所具有的IT资源可根据需求弹性伸缩的特点。  场景一：Web类应用。典型的应用有小程序后端、Web后端、三方服务商对接、前端BFF等。这类应用使用函数编程可以极大简化开发流程，能够做到小时级交付； 场景二：IoT、媒体处理类应用，如实时的图片处理、实时的数据流处理、IoT的事件处理等。这是Serverless最典型的一类应用，特点是事件驱动+计算胶水层，计算胶水层的逻辑通过函数来实现，以事件驱动的方式执行服务，按需供给，开发者无需关注业务波峰波谷，节省闲时成本，最终降低运维的成本； 场景三：AI处理应用，如视频直播、AI推理、人脸识别、车辆识别等，这类应用的特征是基于各行各业的业务智能化，通常无法预知流量大小，需要基础设施能够做到底层资源无感，自动的快速弹缩而不影响业务层的处理。 随着在Serverless技术的研究和实践过程中发现，Serverless作为云计算下半场的计算范式，需要解决通用应用开发、原有应用系统无缝对接、支持异构硬件等问题，并且有完备的工具链、云服务，才能让更多的开发者享受Serverless带来的红利。 # 华为云FunctionGraph开启Serverless新时代 在华为全联接2021上，华为公司高级副总裁、华为云CEO、消费者云服务总裁张平安重磅发布了华为云FunctionGraph函数计算服务。 FunctionGraph是一款带编排能力的函数计算服务，提供了界面化管理、一站式的函数开发上线功能，支持6大类语言、支持10+类的函数触发器类型；拥有丰富的触发器类型，通过事件触发集成多种云服务，满足不同场景需求；根据请求的并发数量自动调度资源运行函数，实现按需极速弹性；函数运行实例出现异常，系统会启动新的实例处理后续的请求，实现秒级故障自愈。 曹宗南作为华为云FunctionGraph首席架构师，全程参与了FunctionGraph 2.0全新架构的设计和研发。针对FunctionGraph 2.0全新架构，他从5个特性做了诠释。 **• 特性1：丰富的函数开发语言及触发方式让设计更灵活**  支持Python、Java、Node.js、Go等常见的编程语言，也支持容器镜像和自定义运行时。函数调用支持同步和异步两种方式，最长支持12小时，可满足长时间任务的需求，大大突破传统Serverless的适用场景。 **• 特性2：可视化拖拽式函数流支持编排复杂业务场景**  支持通过图形化拖拽方式进行函数编排，支持并行分支、条件分支、子流程、循环、异常处理等，可以满足多函数场景下的快速编排需求。 **• 特性3：统一插件支持云上和云下的开发与调试**  如何对函数进行调试作为Serverless场景的一个难点，华为云针对云上和云下两个场景都提供了解决方案，而且作为业界首家支持多函数调试能力。 **• 特性4：Http函数让WEB服务近乎0成本改造，享受Serverless优势能力**  微服务和函数在未来几年会是一个共存的形态，当前存在着大量微服务应用，如何高效的支撑其Serverless化，让现有微服务快速享用到Serverless的优势能力，是一个待解决的问题。 针对Web服务，华为云推出API网关加FunctionGraph的Http函数方案，用户只需把原有的Web Server代码打包为一个Http 函数，即可完成Serverless化改造。该方案价值体现在多语言WEB框架支持方面，例如：Java - Spring Boot，Nodejs - Express等框架，这样对于开发的应用通过极小修改就是能完成Serverless 函数化改造。开发人员可以继续使用熟悉的开发框架和测试工具，降低开发人员学习负担。而且，改造后也无需额外的运维，简单配置即可实现100ms级自动弹性和灰度升级。 **• 特性5：函数支持在运行时动态指定资源，灵活调度节省成本**  图片压缩、水印处理、文档转换、视频转码是典型的事件触发，波峰波谷明显的场景，越来越多地使用Serverless 函数来开发业务。以视频转码为例，典型的处理流程如下：  视频文件的大小从MB到GB，不同编码格式和分辨率对转码需要的计算资源要求差别很大，为保证转码函数的性能，通常配置一个很大的资源规格，但是在低分辨率的（例如短视频）场景下，会造成资源浪费。Functiongraph提供了一种方案支持函数执行时可根据业务需要动态指定资源规格，最小化资源占用，可以给用户带来更精细的资源控制，更低的成本开销。 目前，在华为云Serverless场景落地方面，已全面实现了在移动端的应用实践。曹宗南举例道，2020年新型肺炎疫情牵动着全球人民的心，基于Serverless服务，华为负一屏快速上线“新型肺炎疫情实时播报”，实现了一天上线，资源利用率提升50%。 在视频处理应用场景中，华为视频前端基于函数开发，实现前端开发和后端开发解耦，前端界面逻辑变化不需要后端参与，开发上线效率提升100%以上，大幅减少前后端团队沟通协同，效率提升50%以上。 在海外的合作伙伴应用中，阿联酋海关基于Functiongraph的弹性收缩轻松应对业务波峰波谷，TCO成本较传统方案降低30%以上，较传统开发模式上线周期减少50%（6个月->3个月） # 最后 事实上，目前的Serverless发展已经远远超出了预期。对于云计算应用架构来说，“无服务器”时代的Serverless技术必将引领云计算下一个阶段。正如华为2012实验室分布式与并行软件Lab主任谭焜博士所说，Serverless将是微服务的“封顶之作”，也是推动应用现代化的基石。

2009 年，伯克利以其独特的视角发布了一篇文献，正式定义了云计算。自此，千行百业的 IT 基础设施开启上云之路。2019年，伯克利在《Cloud Programming Simplified》预言：“Serverless计算将会成为云时代默认的计算范式，并取代Serverful（传统云）计算模式。”2009-2019年，互联网技术飞速发展。在这期间，出于对计算机技术的兴趣，曹宗南大学期间选择了计算机专业，之后便开启了他的技术开发生涯。只要对开发有所了解，都知道程序员和开源是密不可分的，曹宗南亦是如此。毕业之后的一次项目中遇到数据库开发相关的瓶颈，他在经过一番查询，发现开源项目分布式数据库中间件Mycat能够完美的解决遇到的问题。他表示，Mycat在使用的过程中，后端可以挂接N个普通的MySQL数据库，数据可以按照多种规则进行分布，对外表现的却像一个MySQL实例一样来使用，业务代码不需要做大的改动。自此，曹宗南便对MySQL产生了极大的兴趣，逐渐的也从使用者到开源的贡献者。陆续给Mycat贡献了多数据库后端支持、动态平滑扩容、分片算法、压缩协议等多个核心特性，还参与Mycat线下技术峰会的演讲。“对Mycat源码也熟悉的像自己的掌纹一样清楚。”曹宗南说道。触摸新技术时代的网红Serverless在谈及现在的工作内容中，曹宗南提到了Serverless技术。正如开篇所提到伯克利在《Cloud Programming Simplified》中的预言，Serverless将成为云计算的下一代默认计算范式。曹宗南解释道，Serverless架构是在微服务架构基础上的进一步延伸，按照业界通常的定义，Serverless = FaaS(Function as a Service) + BaaS(Backend as a Service)。相比微服务，FaaS将资源调度的粒度缩小到函数，针对无状态、短时处理任务，通过函数式编程方式，进一步降低了应用开发门槛，缩短了应用上线周期。为了更好的便于理解，曹宗南从三个典型场景，解读了Serverless架构所具有的IT资源可根据需求弹性伸缩的特点。场景一：Web类应用。典型的应用有小程序后端、Web后端、三方服务商对接、前端BFF等。这类应用使用函数编程可以极大简化开发流程，能够做到小时级交付； 场景二：IoT、媒体处理类应用，如实时的图片处理、实时的数据流处理、IoT的事件处理等。这是Serverless最典型的一类应用，特点是事件驱动+计算胶水层，计算胶水层的逻辑通过函数来实现，以事件驱动的方式执行服务，按需供给，开发者无需关注业务波峰波谷，节省闲时成本，最终降低运维的成本； 场景三：AI处理应用，如视频直播、AI推理、人脸识别、车辆识别等，这类应用的特征是基于各行各业的业务智能化，通常无法预知流量大小，需要基础设施能够做到底层资源无感，自动的快速弹缩而不影响业务层的处理。随着在Serverless技术的研究和实践过程中发现，Serverless作为云计算下半场的计算范式，需要解决通用应用开发、原有应用系统无缝对接、支持异构硬件等问题，并且有完备的工具链、云服务，才能让更多的开发者享受Serverless带来的红利。华为云FunctionGraph开启Serverless新时代在华为全联接2021上，华为公司高级副总裁、华为云CEO、消费者云服务总裁张平安重磅发布了华为云FunctionGraph函数计算服务。FunctionGraph是一款带编排能力的函数计算服务，提供了界面化管理、一站式的函数开发上线功能，支持6大类语言、支持10+类的函数触发器类型；拥有丰富的触发器类型，通过事件触发集成多种云服务，满足不同场景需求；根据请求的并发数量自动调度资源运行函数，实现按需极速弹性；函数运行实例出现异常，系统会启动新的实例处理后续的请求，实现秒级故障自愈。曹宗南作为华为云FunctionGraph首席架构师，全程参与了FunctionGraph 2.0全新架构的设计和研发。针对FunctionGraph 2.0全新架构，他从5个特性做了诠释。• 特性1：丰富的函数开发语言及触发方式让设计更灵活支持Python、Java、Node.js、Go等常见的编程语言，也支持容器镜像和自定义运行时。函数调用支持同步和异步两种方式，最长支持12小时，可满足长时间任务的需求，大大突破传统Serverless的适用场景。• 特性2：可视化拖拽式函数流支持编排复杂业务场景支持通过图形化拖拽方式进行函数编排，支持并行分支、条件分支、子流程、循环、异常处理等，可以满足多函数场景下的快速编排需求。• 特性3：统一插件支持云上和云下的开发与调试如何对函数进行调试作为Serverless场景的一个难点，华为云针对云上和云下两个场景都提供了解决方案，而且作为业界首家支持多函数调试能力。• 特性4：Http函数让WEB服务近乎0成本改造，享受Serverless优势能力微服务和函数在未来几年会是一个共存的形态，当前存在着大量微服务应用，如何高效的支撑其Serverless化，让现有微服务快速享用到Serverless的优势能力，是一个待解决的问题。针对Web服务，华为云推出API网关加FunctionGraph的Http函数方案，用户只需把原有的Web Server代码打包为一个Http 函数，即可完成Serverless化改造。该方案价值体现在多语言WEB框架支持方面，例如：Java - Spring Boot，Nodejs - Express等框架，这样对于开发的应用通过极小修改就是能完成Serverless 函数化改造。开发人员可以继续使用熟悉的开发框架和测试工具，降低开发人员学习负担。而且，改造后也无需额外的运维，简单配置即可实现100ms级自动弹性和灰度升级。• 特性5：函数支持在运行时动态指定资源，灵活调度节省成本图片压缩、水印处理、文档转换、视频转码是典型的事件触发，波峰波谷明显的场景，越来越多地使用Serverless 函数来开发业务。以视频转码为例，典型的处理流程如下：视频文件的大小从MB到GB，不同编码格式和分辨率对转码需要的计算资源要求差别很大，为保证转码函数的性能，通常配置一个很大的资源规格，但是在低分辨率的（例如短视频）场景下，会造成资源浪费。Functiongraph提供了一种方案支持函数执行时可根据业务需要动态指定资源规格，最小化资源占用，可以给用户带来更精细的资源控制，更低的成本开销。目前，在华为云Serverless场景落地方面，已全面实现了在移动端的应用实践。曹宗南举例道，2020年新型肺炎疫情牵动着全球人民的心，基于Serverless服务，华为负一屏快速上线“新型肺炎疫情实时播报”，实现了一天上线，资源利用率提升50%。在视频处理应用场景中，华为视频前端基于函数开发，实现前端开发和后端开发解耦，前端界面逻辑变化不需要后端参与，开发上线效率提升100%以上，大幅减少前后端团队沟通协同，效率提升50%以上。在海外的合作伙伴应用中，阿联酋海关基于Functiongraph的弹性收缩轻松应对业务波峰波谷，TCO成本较传统方案降低30%以上，较传统开发模式上线周期减少50%（6个月->3个月）最后事实上，目前的Serverless发展已经远远超出了预期。对于云计算应用架构来说，“无服务器”时代的Serverless技术必将引领云计算下一个阶段。正如华为2012实验室分布式与并行软件Lab主任谭焜博士所说，Serverless将是微服务的“封顶之作”，也是推动应用现代化的基石。

感谢各位小伙伴对本次活动的大力支持，根据大家提交的课后习题和实践任务截图，在符合获奖条件的用户中，已根据活动规则抽出各奖项的获奖者，截图如下请各位获奖开发者在12月31日前完成领奖信息反馈，逾期未反馈领奖信息，将视为自动放弃领奖！反馈链接： https://devcloud.huaweicloud.com/expertmobile/qtn?id=dbc9fccc5bf44605b80955f78654ec9f 我们将在所有获奖者完整填写领奖信息后14个工作日内，统一发出奖品，敬请期待哦！为保护大家账号隐私，已对账号进行模糊处理，请大家仔细核对哦1. 通关王者奖2. 高阶大师奖3. 进阶达人奖4. 入门新生奖5. 探知小白奖说明：按要求完成该奖项所对应的预习期实践任务的开发者为93人，根据活动规则，抽取10位开发者获奖。6. 学习达人奖说明：该奖项奖品设置数量为50，按要求将预习期、入门期、进阶期、高阶期课后习题全部回答正确用户23人，小于50人，故23人全部获奖，恭喜大家！7. 邀请有礼奖说明：该奖项奖品设置数量为30，按要求邀请3位以上好友报名活动的用户为13人，小于30人，故13人全部获奖，恭喜大家！为保证活动公平公正，已对抽奖过程进行录屏，抽奖过程请参见如下链接，抽奖入围名单请见附件。https://res-static.hc-cdn.cn/cloudbu-site/china/zh-cn/Serverless/1640334810314091271.rar你是否有过如下困扰：资源利用率如何提升？业务暴增时如何扩容？如何解决运维中的难题？何时才能只聚焦应用创新，不用关心如何管理服务器？别急，无服务器时代已来，Serverless助你摆脱底层资源的管理困扰，专注应用创新，促进快速迭代~图灵奖获得者David A. Patterson和Spark共同创始人Ion Stoica，在19年伯克利的会议上发布Serverless将是下一代默认的计算范式。 那么究竟什么是Serverless？什么是FaaS和BaaS？不购买服务器如何构建应用呢？华为云一线大咖带你从0到1入门Serverless，体系化课程搭配场景化实践操作，更有无线耳机、华为音箱、京东卡等好礼等你拿哦~1. 活动时间：2021.11.16-2021.12.20；招募期&预习期：2021.11.16-2021.11.29；入门期：2021.11.30-2021.12.6；进阶期：2021.12.7-2021.12.13；高阶期：2021.12.14-2021.12.20；2. 适合人群：对Serverless感兴趣，饱受底层资源管理困扰，有志在无服务器时代弯道超车的开发者们3. 参与流程：(1) 活动报名 点此报名活动      邀请3位以上好友报名活动，即可获得抽奖资格，奖品为案例学院会员卡一张哦！奖品数量上限为30个，中奖概率（≤100%）为30/完成任务人数。(2) 添加小助手微信，回复“Serverless”加入学习群(3) 加入Classroom课堂，获取学习材料及实操任务指导文档，完成实践任务，按要求提交任务完成截图至Classroom课堂，获取抽奖资格；点此加入Classroom课堂(4) 审核截图，抽奖，公布获奖名单4. 任务完成截图提交规则：(1) 提交时间：2021年11月16日-2021年12月20日，由于各学员报名活动的时间不统一，完成任务的时间有早晚，为鼓励大家积极性，保证活动公平公正，所有实践任务完成截图的提交截止时间统一为2021年12月20日23:59，在此时间之前加入活动的学员均可提交任务完成截图。(2) 截图提交方式：进入Classroom课堂找到对应阶段学习课程，点击提交作业，上传截图即可；(3) 截图中需显示华为云中国站账号，社群助手将在实操指导文档中提供截图示例；(4) 活动结束后，社群助手将对所有截图内容进行审核，审核周期为3-5个工作日，未按要求上传截图的学员，将无法参与评奖；5. 奖励规则：本活动不仅可以跟随华为专家学习干货知识，更有免费奖品可以拿哦，详细获奖规则请见下图6. 活动注意事项：所有获奖用户名单将在活动结束后3个工作日内在本帖公示，请获奖用户按照反馈路径及时反馈获奖信息，活动结束且用户填写完整领奖信息后14个工作日内，将统一发出奖品，不额外收取任何费用。由于获奖用户自身原因（包括但不限于提供的联系方式有误、身份不符或者通知领奖后超过30天未领取等）造成奖品无法发送的，视为获奖用户放弃领奖；活动奖品颜色随机，且部分奖品数量有限发完即止，如对应奖品无库存会更换等价奖品；为保证活动的公平公正，华为云有权对恶意刷活动资源（“恶意”是指为获取资源而异常注册账号等破坏活动公平性的行为），利用资源从事违法违规行为的用户收回抽奖及奖励资格。本活动规则由华为云在法律规定范围内进行解释。华为云保留不时更新、修改或删除本活动规则的权利。本次活动回帖内容需满足华为云论坛发帖规范：https://bbs.huaweicloud.com/forum/thread-23077-1-1.html