互联网蓬勃发展的今天，大多数公司开发的应用软件都需要部署到服务器上，无论是选择公有云还是私有的数据中心，都需要提前了解服务需要多少计算资源、多少存储空间，并且还要预留部分资源应对可能突发的请求。这些细节耗费了我们大量精力，同时也产生了许多不必要的资源浪费。
从云计算的发展历史来看，弹性扩缩，按需使用就一直是用户关心的重要因素，也是云计算相对于传统计算的重大的优势。在云计算逐步成为互联网基石的今天，复杂的运维工作是每个公司不得不关心的事情。我们也在思考，是否有一种更简单的解决方案，让我们不用关心复杂的架构，以及更为极致的按需使用？
这个答案已经存在，这就是今天软件架构世界中新鲜但是很热门的一个话题 —— Serverless（无服务器）架构。
Serverless 是什么
作为一个新的概念，Serverless 并没有一个标准的定义，这里仅尝试表述我所理解的 Serverless 架构：Serverless 架构允许用户直接按需使用服务，而不必担心底层基础架构，仅依赖于第三方服务商。
Serverless 消除了基础设施管理任务，例如服务器或集群配置、操作系统维护和容量预留。当然，所谓“无服务器”，并不是说基于 Serverless 架构的软件应用不需要服务器就可以运行，其指的是用户无须关心软件应用运行涉及的底层服务器的状态、资源（比如 CPU、内存、磁盘及网络）及数量。软件应用正常运行所需要的计算资源由底层的云计算平台动态提供。
当然，Serverless 也不是说不需要编写服务端代码，服务端的逻辑代码仍然需要开发者编写。Serverless 的平台化，也使得开发者编写的代码将能够被更多人的共用。
这里，我更偏向认为 Serverless 是一种广义的概念，其所指代的是一类架构思想，而不是某种具体的事务，更不是某个具体的框架（没错，说的就是那个叫 Serverless 的框架）。
Serverless 与 FaaS
FasS（Function as a Service）可以说是 Serverless 的极致体现，一小段代码，即一个简单的函数，就可以是一个服务。FaaS 提供了一个计算平台，在这个平台上，应用以一个或多个函数的形式开发、运行和管理。FaaS 平台提供了函数式应用的运行环境，一般支持多种主流编程语言，如 JavaScript、PHP、Python 等。
大多数 FaaS 平台基于事件驱动（Event Driven）的思想，可以根据预定义的事件触发指定的函数应用逻辑，如 HTTP 访问触发，定时触发等。目前比较流行的 FaaS 平台有 AWS Lambda、Azure Functions、腾讯云云函数、阿里云函数计算 等。
有很多人在谈 Serverless 时，总是会把 Serverless 和 FaaS 划上等号，这种说法是有问题的。FaaS 是 Serverless 思想的一种体现，而不是等价的关系。事实上，除了 FaaS 这种 Serverless 计算平台之外，还有 [Serverless 数据库](https://cloud.tencent.com/document/product/409/42844)、Serverless 容器等。毫无疑问，在可以预见的未来，会有更多的 Serverless 产品出现。
理想与现实
理想总是如此美好，以至于我们经常会忽略一些不容易被察觉的问题。如果没有提前考虑到这些问题，可能会导致不愉快的开发体验，甚至无法达成预想的目标。下面我们以 FaaS 为例，谈谈 FaaS 的那些问题。
冷启动
在使用 FaaS 服务时，函数代码通常在需要响应事件的容器中运行，当请求来临时，平台才会启动容器，响应请求。当你的函数执行完成后，你的容器可能会保留一段时间，下次请求来临时，能够快速的响应请求。第一次请求时，容器启动通常耗时会比较旧，这被称为“冷启动”。当容器被保留还没被销毁时，它的响应速度要快得多，这通常被称为“热启动”。
冷启动的时间并没有一个准确值，可能是 1S，也可能是 10S，它取决于使用的运行时（或编程语言）、函数（以包的形式）的大小，特定云服务商的实现等。多年以来，随着云服务商在优化时延方面变得越来越出色，冷启动已经大为改善。如果你的服务量较大，或者是不在意请求延时，那你可以忽略这个问题。
无状态
FaaS 通常是无状态的，没有固定的存储空间，固定的内容空间。计算平台可能会启用全新的容器处理请求，也可能会继续复用已有的容器。我们无法像传统服务那样，通过直接使用服务器的缓存来提供服务的响应速度。我们也不会在本地存储文件，使用数据库等，数据随时会丢失。
即使我们可以直接购买已有的 Redis 或 MySQL 服务，我们任然要考虑无法使用缓存，频繁建立连接所带来的性能损耗。
长时间运行
FaaS 平台通常会对函数的执行时间予以限制，超时后会自动终止执行。相对于传统的服务器而言，长时间运行的函数也会更加昂贵。所以，FaaS 并不适合长时间执行类的服务，如 WebSocket 等。
服务编排
当服务规模变得庞大之后，不可避免的要考虑服务之间的关系，如何编排服务，处理服务间的相互调用，高效的响应请求等。目前的很多厂商都没有提供相关的解决方案，需要自行探索。
Serverless 是一个很好地技术进步，但是它也不是完美的，基于其的实现形式，可能会存在许多局限性。在使用到生产环境前，最好做一些必要的实践，确保是否满足自己的需求。
优缺点
在了解完 Serverless 的基本特点后，下面我们总结一下 Serverless 的优缺点，帮助大家更好的判断 Serverless 是否适合自己。
先来看优点：
- 高效、免运维：用户只需编写业务的“核心代码”，不再关心服务器等基础建设，极大地降低了服务搭建的复杂性，有效提升开发和迭代的速度
- 弹性伸缩：
Serverless计算平台可以自动安排合理的计算资源满足业务需求，轻松应对请求的波峰与波谷。 - 按需计费、降低成本：按实际使用计算资源计费，不占用计算资源则不计费，资源利用率可高达 100%（FaaS）。
- 稳定可靠：计算平台提供可用性保障，并采用多集群，多地域部署，保障服务高可用，抵御网络攻击。
当然，Serverless 也并不是完美无缺的，它也有一些缺点
- 可移植性：
Serverless应用的实现在很大程度上依赖于Serverless平台，不同的厂商可能会有不同的实现方式和解决方案，通常会和厂商的其他服务绑定。 - 生态：
Serverless还是一门相对较新的技术，虽然可以利用现有的生态，但是因其局限性，一些特有的解决方案，开发工具等还是不够健全。
应用场景
Serverless 的应用场景是十分广阔的，适合很多服务处理使用，举几个例子：
- Web 应用：处理前端请求
- 定时任务：定时触发云函数，执行处理逻辑
- 多媒体处理：图片处理、视频处理等
- 低频服务：请求少的服务
当然，这只是部分场景，Serverless 还有更大的使用场景。在了解了 Serverless 的技术特点后，大家可以多动手尝试，发掘更多的使用场景。
作为一个技术人，我们应当有敏锐的技术嗅觉，正确的判断技术的使用场景，并合理地将技术作为自己解决问题的利刃。当一门新技术出现的时候，我们要看它解决了什么问题，有什么优势，而不是盲目从众。
总结
Serverless 的出现给我们带来更多的选择与可能性，同时也带来了机遇与挑战。目前，国内的 Serverless 技术正在快速发展，相关的配套设施和服务也已经较为完善，越来越多的公司正在尝试使用 Serverless 开发他们的产品，生态也变得越来越繁荣。
可能，现在的 Serverless 还不够强大，但它仍在飞速发展进步。纵观科技的历史，一切都在向简单、易用发展进步，我也相信，这是技术发展的趋势。如果有一样东西，它能简单、高效的解决你的问题，那为何不尝试一下呢？
未来总会来临，请让子弹飞一会~