前言：如今，越来越多的大厂企业开始大规模使用 Serverless，处于变革中的开发者，大多已从观望状态转向尝试阶段，越来越多 Serverless 落地场景被解锁。作为基础研发底座，越来越多企业开始接受 Serverless，并将其应用于业务实践中。预计 Serverless 架构将引领云计算的下一个十年已成为共识。这个 Serverless 不仅适合与小场景，同样适用与大厂秒杀，12306 抢票的大业务场景。Serverless 不是不需要 Server，而是需要我们前端较少的关注服务器端，前端程序员可以好好研究一下。
培养自己的 Serverless 思维与认知
以前很多开发者都是采用的单体架构，为了保证服务的稳定性，只需要维护一台服务器及数据库就可以啦，但是随着业务的增长会面临两个问题，如果流量比较大，这个服务器可能顶不住这么大的流量，其次硬件啥的损坏也会导致整个系统瘫痪。
解决这个问题的办法就是使用负载均衡，分担各个服务器的压力。然后整个系统就有一定的水平伸缩能力，如果一台服务器坏了，其它的服务器也能正常运行，保证系统稳定运行。
随着业务的进一步增长，增加大量的开发人员去处理这种单体应用，就会出现大量的冲突问题，这个就需要管理者进行人工协调，公司整体研发效率比较低，后台大家想到一个好办法就是把这个单体应用分为一个个独立开发、测试及部署。每个环节都是独立而又有一定的联系，这个就是微服务的雏形。服务和服务之间采用 API 通信，这种微服务架构大大提升了研发人员的工作效率。
再到后来，估计大家都有所了解，如果从物理的角度思考这个问题就会发现分布式的一些困难与挑战，比如大家使用分布式服务及框架，使用一些 Redis 缓存、配置服务 ACM 以及分布式追踪系统等。这个微服务架构给运维也带来不少的难题，感觉运维大哥都快成全能底层人才了，以前运维只需要维护一个应用，现在估计一个人都得看几十个、几百个应用。对应用分发、自动化弹性等能力有一定的要求。
现在很多人都谈云计算，云架构，简单理解就是这个架构长在“云”上就是云架构。 有了应用分发的标准和生命周期的标准，云就能提供标准化的应用托管服务。在整个架构的演变的过程中，我们发现，研发运维人员希望用平台系统的去管理机器，而不是人去管理这些个玩意。这可能就是 server is less.
Serverless 的使用价值及常见的架构模式
我们抛去这些抽象的概念，看一下这个 Serverless 的使用价值主要有以下几点：
1.不用过多的关注服务器。 （Serverless 平台具备自动识别故障，移除故障的能力） 2.自动弹性。 （Serverless 平台自动及时稳定的实现自动弹性） 3.按照实际资源的消耗进行计费。 （Serverless 模式下，按照实际消耗资源及使用存储进行计费） 4.更少的代码，更快的交付速度。 （Serverless 提供成熟的代码构建发布、版本切换等特性，交付速度更快）
Serverless 由开发者实现的服务端逻辑运行在无状态的计算容器中，它由事件触发， 完全被第三方管理，其业务层面的状态则被开发者使用的数据库和存储资源所记录。Serverless 涵盖了很多技术，分为两类：FaaS 和 BaaS。
FaaS（Function as a Service，函数即服务）
FaaS 意在无须自行管理服务器系统或自己的服务器应用程序，即可直接运行后端代码。其中所指的服务器应用程序，是该技术与容器和 PaaS（平台即服务）等其他现代化架构最大的差异。
FaaS 可以取代一些服务处理服务器（可能是物理计算机，但绝对需要运行某种应用程序），这样不仅不需要自行供应服务器，也不需要全时运行应用程序。
FaaS 产品不要求必须使用特定框架或库进行开发。在语言和环境方面，FaaS 函数就是常规的应用程序。例如 AWS Lambda 的函数可以通过 Javascript、Python 以及任何 JVM 语言（Java、Clojure、Scala）等实现。然而 Lambda 函数也可以执行任何捆绑有所需部署构件的进程，因此可以使用任何语言，只要能编译为 Unix 进程即可。FaaS 函数在架构方面确实存在一定的局限，尤其是在状态和执行时间方面。
在迁往 FaaS 的过程中，唯一需要修改的代码是“主方法/启动”代码，其中可能需要删除顶级消息处理程序的相关代码（“消息监听器接口”的实现），但这可能只需要更改方法签名即可。在 FaaS 的世界中，代码的其余所有部分（例如向数据库执行写入的代码）无须任何变化。
相比传统系统，部署方法会有较大变化 – 将代码上传至 FaaS 供应商，其他事情均可由供应商完成。目前这种方式通常意味着需要上传代码的全新定义（例如上传 zip 或 JAR 文件），随后调用一个专有 API 发起更新过程。
FaaS 中的函数可以通过供应商定义的事件类型触发。对于亚马逊 AWS，此类触发事件可以包括 S3（文件）更新、时间（计划任务），以及加入消息总线的消息（例如 Kinesis）。通常你的函数需要通过参数指定自己需要绑定到的事件源。
大部分供应商还允许函数作为对传入 Http 请求的响应来触发，通常这类请求来自某种该类型的 API 网关（例如 AWS API 网关、Webtask）。
BaaS（Backend as a Service，后端即服务）
BaaS（Backend as a Service，后端即服务）是指我们不再编写或管理所有服务端组件，可以使用领域通用的远程组件（而不是进程内的库）来提供服务。理解 BaaS，需要搞清楚它与 PaaS 的区别。
首先 BaaS 并非 PaaS，它们的区别在于：PaaS 需要参与应用的生命周期管理，BaaS 则仅仅提供应用依赖的第三方服务。典型的 PaaS 平台需要提供手段让开发者部署和配置应用，例如自动将应用部署到 Tomcat 容器中，并管理应用的生命周期。BaaS 不包含这些内容，BaaS 只以 API 的方式提供应用依赖的后端服务，例如数据库和对象存储。BaaS 可以是公共云服务商提供的，也可以是第三方厂商提供的。其次从功能上讲，BaaS 可以看作 PaaS 的一个子集，即提供第三方依赖组件的部分。
BaaS 服务还允许我们依赖其他人已经实现的应用逻辑。对于这点，认证就是一个很好的例子。很多应用都要自己编写实现注册、登录、密码管理等逻辑的代码，而对于不同的应用这些代码往往大同小异。完全可以把这些重复性的工作提取出来，再做成外部服务，而这正是 Auth0 和 Amazon Cognito 等产品的目标。它们能实现全面的认证和用户管理，开发团队再也不用自己编写或者管理实现这些功能的代码。
函数计算介绍及其应用
从用户角度，他需要做的只是编码，然后把代码上传到函数计算中。上传代码就意味着应用部署。当有高并发请求涌入时，开发者也无需手动扩容，函数计算会根据请求量毫秒级自动扩容，弹性可靠地运行任务，并内置日志查询、性能监控、报警等功能帮助开发者发现问题并定位问题。
函数计算是事件驱动的无服务器应用，事件驱动是说可以通过事件源自动触发函数执行，比如当有对象上传至 OSS 中时，自动触发函数，对新上传的图片进行处理函数计算支持丰富的事件源类型，包括日志服务、对象存储、表格存储、消息服务、API 网关、CDN 等。
除了事件触发外，也可以直接通过 API/SDK 直接调用函数。调用可以分为同步调用与异步调用，当请求到达函数计算后，函数计算会为请求分配执行环境，如果是异步调用，函数计算会将请求事件存入队列中，等待消费。
函数的测试与部署
服务是函数计算资源管理的单位，同一个服务下有很多函数，这些函数共享服务的网络 配置、权限配置、存储配置、日志配置。 服务可以对应成一个“应用”，这个应用由很多函数共同组成，这些函数具有相同的访 问权限、网络配置，日志也记录到相同的 logstore。这些函数本身的配置可以各不相同， 比如同一服务下有的函数内存是 3G，有的函数内存是 512M，有些函数用 Python 写， 有些函数用 Node.js 写。
开发流程
函数测试部分，Serverless 稍微薄弱一点，软肋，这个调试一般可以采用云调试、命令行工具、VSCode 插件、无工具调试等方式，具体怎么调试我就不一一说明了，有兴趣的可以尝试一下。
至于部署，比较简单，我们可以使用在线部署、客户端部署（通过命令行工具、通过 VSCode 插件）。命令行工具的 - h 指令真的很棒， 无论使用什么指令，我们都可以通过 - h 查看到使用方法。
Serverless 容器服务及部署
Serverless Kubernetes 是以容器和 kubernetes 为基础的 Serverless 服 务，它提供了一种简单易用、极致弹性、最优成本和按需付费的 Kubernetes 容器服务， 其无需节点管理和运维，无需容量规划，让用户更关注应用而非基础设施的管理。我们可以把把 Serverless Kubernetes 简称为 ASK。
当下各大云厂商都推出了自己的 Serverless 容器服务，上图为 Gartner 评估机构 整理的 Serverless 容器产品 Landscape，其中阿里云有 Serverless Kubernetes ASK 和 ECI；AWS 有 Fargate，基于 Fargate 有 EKS on Fargate 和 ECS on Fargate 两种形态；Azure 有 ACI。另外 Gartner 也预测，到 2023 年，将有 70% 的 AI 应用以容器和 Serverless 方式运行。
在对 Serverless Kubernetes 的基础概念有了充分了解之后，我们直接进入容器服务控制台进行集群的创建。集群创建完成后，接下来我们部署一个无状态的 nginx 应用，主要分成三步：
1.应用基本信息：名称、POD 数量、标签等； 2.容器配置：镜像、所需资源、容器端口、数据卷等； 3.高级配置：服务、路由、HPA、POD 标签等
创建完成后，在路由中就可以看到服务对外暴露的访问方式了。
Serverless 应用引擎
主要的挑战：
1.开发难度和入门门槛高，业务轻量化困难，不能平滑地迁移现有应用 ；
2.担心被云厂商锁定，如 FaaS 形态的 Serverless 产品，每个厂商都希望推出自己的 标准，缺乏开源的规范和开源的生态支持。相似的一幕曾经在容器领域上演，直到后来 Kubernetes 成为事实标准，Serverless 还在寻找自己的事实标准；
3.如何方便地本地开发调试、监控，和现有业务做深度整合。
低门槛，无需任何代码改造就能直接使用的 Serverless PaaS 平台（SAE），是企业在线业 务平滑上云的最佳选择。
SAE 提供了成本更优、效率更高的应用托管方案。底层基于统一的 K8s 技术底座， 帮用户屏蔽复杂的 IaaS 层和 K8s 集群运维，提供计算资源、弹性、隔离性等能力，用 户只需关心应用实例的规格和实例数。 在应用层，除提供了生命周期管理、多发布策略外，还提供监控、日志、微服务治理能 力，解决应用可观测性和治理需求。同时提供一键启停、应用编排等高级能力，进一步提效 和降本。核心场景主要面向在线应用：微服务应用、Web 应用、多语言应用等。 在开发者工具方面，和 CI/CD 工具做了良好的集成，无论是 Jenkins 还是云效，都 能直接部署应用到 SAE，也可以通过 Cloud Toolkit 插件工具实现本地一键部署应用到 云端，可以说 SAE 覆盖了应用上云的完整场景常见的业务场景及经典案例。
至于行业一些经典案例这个场景，这个简单提一下 ，不过多介绍，有兴趣的可以查阅项目资料。
比如：Serverless 应用引擎弹性伸缩实践、基于函数计算实现 AI 推理、基于函数计算实现快速建站、基于函数计算快速搭建 Hexo 博客系统等等，然后再提一下相关的产品吧，比如函数计算（Function Compute）是一个事件驱动的全托管 Serverless 计算服务， 您无需管理服务器等基础设施，只需编写代码并上传，函数计算会为您准备好计算资源，并 以弹性、可靠的方式运行您的代码。Serverless 应用引擎（Serverless App Engine，简称 SAE）实现 Serverless 架构 微服务架构的完美融合，真正按需使用、按量计费，节省闲置计算资源，同时免去 IaaS 运维，有效提升开发运维效率。弹性容器实例 ECI 提供安全的 Serverless 容器 运行服务。您无需管理底层服务器，只需要提供打包好的 Docker 镜像，即可运行容器， 并仅为容器实际运行消耗的资源付费。GPU 云服务器基于 GPU 应用的计算服务，多适用于 AI 深度学习、视频处理、 科学计算、图形可视化等应用场景等。
好啦，本期内容就分享到这里，我们下期见！
