深度使用了下 Serverless，太丝滑了！
最近在开发自己的小项目的时候，因为各种原因使用上了云函数这个东西，不夸张的说开发时间直接减少一半，当然也没啥复杂业务逻辑，但是乱七八糟各种配置基本都可以摒弃掉了。
云函数就是一种 Serveless，准确来说，云函数属于 Serveless 中的 FaaS（Function as a Service，函数即服务），典型的产品有阿里云函数、腾讯云函数、AWS Lambda、Google Cloud Functions、Azure Functions 等等。
FaaS 本质上是一种事件驱动的由消息触发的服务，FaaS 供应商（比如阿里云、腾讯云）一般会集成各种同步和异步的事件源，通过订阅这些事件源，可以突发或者定期的触发函数运行。于传统服务需要将应用程序（Application）部署到拥有操作系统的虚拟机或者容器中并且需要长时间驻留的机制不同，FaaS 是直接将程序部署上到平台上即可，当有事件到来时触发执行，执行完了就可以卸载掉。
IaaS、PaaS、SaaS、Faas
看完上面这些介绍一定还有很多同学一头雾水，别急，下面我来详细介绍下 FaaS 的发展背景：
云计算这个词大伙肯定都听说过，这个概念听起来很牛逼，但其实核心目的就是云服务商能够为用户提供更强大、更便宜的算力。
当然，不要觉得云计算就是一个超大号的机房，只不过服务器更多些。
云计算的本质，不是算力资源的简单堆砌，而是池化。它将大量的零散算力资源（廉价的算力资源）进行打包、汇聚，实现更高可靠性、更高性能、更低成本的算力。
具体来说，在云计算中，CPU、GPU、内存、硬盘等计算资源被集合起来，通过软件的方式，组成一个虚拟的可无限扩展的“算力资源池”。如果用户有算力需求，“算力资源池”就会动态地进行算力资源的分配，构建一个虚拟的“计算机”。用户按需使用、付费，即可。相比于用户自购设备、自建机房、自己运维，云计算有明显的成本优势，可以节约大量资金和人力。
根据提供算力资源的层级不同，云计算通常也分为 IaaS（基础设施即服务）、PaaS（平台即服务）、SaaS（软件即服务）。如下图所示：
那么，云计算这种 “租” 的方式，是不是最终极的算力资源使用方式呢？我们作为用户，使用算力，还能更简单一点吗？
答案是肯定的。
不管是自建机房，还是云计算，用户都需要和服务器打交道，和软硬件环境打交道。这些都是工具和过程，而我们的最终目的是什么？是得到运算结果。
那么，为了得到结果，我们可不可以不要关心环境的搭建过程呢？能不能直接忽略掉数据库、缓存、消息队列等等各种乱七八糟的配置呢？或者说，既然环境可以租，那能不能直接 “租” 服务呢？
如此，Serverless 应运而生了！
Serverless 是架构、也是思想，它的目的就是在云计算的基础上，再向前迈进一步，彻底“包揽”所有的环境工作，直接提供计算服务。
那 Serverless 具体怎么做到直接租服务的呢，核心就是这个服务足够“细小”，变成了“函数级”的颗粒度。从层级上来看，Serverless 在传统云计算 SaaS 的 Application（应用）层级之上，又加了一层 Function（函数），它的颗粒度更细，可以更灵活地满足用户的算力需求。
在 Serverless 架构下，开发者只需编写代码并上传，云平台就会自动准备好相应的计算资源，完成运算并输出结果，从而大幅简化开发运维过程。
我深度体验了一把，这个开发体验真的太太太太丝滑了，开发到部署无缝衔接，再回到之前的开发方式我只能说有、笨重。
Serverless = FaaS + BaaS
说了半天 FaaS，还没有正式介绍 Serveless，简单记忆：Serveless = FaaS + BaaS
又出现了一个新概念 BaaS（Backend as a Service，后端即服务），BaaS 可让开发人员访问各种各样的第三方服务和应用。例如，云提供商可以提供认证服务、额外加密、云访问数据库以及高置信度使用数据。
而在 FaaS 下，开发人员仍然要编写自定义服务器端逻辑，但它可以在完全由云服务提供商管理的容器中运行。
综上，Serverless 的优点是勿容置疑的：
- 无需管理基础设施：在 Serverless 中，云提供商负责管理底层的服务器和基础设施，包括硬件和操作系统。这意味着开发者无需担心服务器的配置、维护和扩展，可以将更多精力放在应用程序的开发和功能上。
- 自动伸缩：Serverless 可以自动伸缩资源以满足流量需求，无需手动干预。这可以确保应用程序在高峰时期具有良好的性能，并在低流量时期降低成本。
- 按需计费：Serverless 模型按照实际使用的资源和执行时间来计费，因此开发者只需支付他们真正使用的部分，而无需预先购买或租赁资源。
- 快速启动：Serverless函数通常在几秒内启动，因此可以迅速响应请求。这对于需要快速扩展或处理瞬时负载的应用程序非常有用。
- 事件驱动：Serverless 函数通常是事件驱动的，可以响应各种事件，如 HTTP 请求、数据库更改、队列消息等。这使得它们非常适合构建微服务和处理异步任务。
至于缺点，首先说定论，对于业务逻辑复杂的大型项目来说，Serverless 可能还不是一个非常好的选择：
- 依赖云服务商：Serverless 的主动权掌握在云服务商的手上，就比如现在云函数主流还是用 Node.js 写，各厂商对 Java 云函数的支持普遍还不是那么好
- 调试复杂性：在 Serverless 中，本地调试和跟踪函数会更加复杂，因为函数的执行是在云提供商的环境中进行的。
- 状态管理：要想实现自由的缩放，无状态是必须的，而对于有状态的服务，使用 Serverless 这就丧失了灵活性，有状态服务需要与存储交互就不可避免的增加了延迟和复杂性。
- 延迟：应用程序中不同组件的访问延迟是一个大问题，我们可以通过使用专有的网络协议、RPC 调用、数据格式来优化，或者是将实例放在同一个机架内或同一个主机实例上来优化以减少延迟。而 Serverless 应用程序是高度分布式、低耦合的，这就意味着延迟将始终是一个问题。
- 成本不可控：虽然 Serverless 按需计费有助于降低成本，但对于某些高负载或长时间运行的工作负载，可能会导致不可控的费用增加。