|
背景：后端架构的演进
1. 「物理机时代」：最初，搭建一个服务器是非常繁琐的，需要购买一台主机，然后找一个机房对机器进行托管，要将外观拍照、将各项硬件参数提交到备案中心进行备案，链接电源和网线，安装好操作系统，搭建好代码的运行环境，部署程序代码后，再将申请的域名和静态IP做好解析，就算是上线部署完毕了。这样的服务器架构是单机版的单体架构，数据库、应用代码、HTTP服务器等服务全都在一台你自己管理的服务器上运行，因为我们要接触物理机，因此也把它成为“物理机时代”。
2. 「虚拟机时代」：随着技术的不断发展，逐步摆脱了物理机时代，跨入虚拟机时代。其中一个重要节点之一就是 2001年 VMWare 带来的针对 x86 服务器的虚拟化产品。通过虚拟化技术，可以把一台物理机分割成多台虚拟机提供给用户使用，充分利用硬件资源，而对于硬件设备的管理，统一由云厂商负责。对于开发者来说，就不用再买硬件了（不必关心硬件设备的管理），直接在云平台买虚拟机，比如 AWS 的 EC2、阿里云 ECS、腾讯云 CVM。不过业务量的不断增长，用户越来越多，数据库每天都有几千万条数据写入，数据库性能很快就会达到瓶颈。除此之外，每天也有上百万图片存到磁盘，磁盘也快要耗尽了。为了降低服务器负载，我们把数据库迁移到了云厂商提供的云数据库上，把图片存储迁移到对象存储。云数据库有专门的服务器，并且还提供了备份容灾，比自己在服务器上安装数据库更稳性能更强。对象存储能无限扩容，不用担心磁盘不够了。这样一来，服务器就只负责处理用户的请求，把「计算」和「存储」分离开来，既降低了系统负载，也提升了数据安全性。并且单机应用升级为了集群应用，通过负载均衡，会把用户流量均匀分配到每台服务器上。不过在服务器扩容的过程中，你还是会遇到一些麻烦。比如购买服务器后，都需要在上面初始化软件环境和配置，还需要保证所有服务器运行环境一致，这是个非常复杂还容易出错的工作。这对运维工程师也是一个非常大的挑战。3. 「容器时代」：2013 年 Docker 的发布，代表着容器技术替代了虚拟化技术，云计算进入容器时代。容器技术就是在虚拟化技术的基础上，把代码和运行环境打包在一起，这样，不论服务器的配置怎样，代码和运行环境均能保持一致性。有了容器技术，你在服务器上部署的就不再是应用了，而是容器。当容器多了的时候，如何管理就成了一个问题，于是出现了容器编排技术，比如 2014 年 Google 开源的 Kubernetes，就是俗称的 K8S 。在目前的后端架构中，容器技术依然是主流的服务器架构技术，但是随着互联网应用的普及，我们需要面对各种各样的应用场景，eg：每当大型购物节来临，在线商城会面临巨大的流量洪峰，而在平时，流量显然要小很多，为了迎接购物节的流量洪峰，需要大量扩充服务器，服务器的扩充和大量容器的编排工作，也是一个不小的难题，如果对流量的压力预估不到位，还会有服务器宕机的风险， 而在平时，如此多的服务器运行显然是在浪费资源增加成本。那么，有没有一种技术，让我们只关心业务代码的功能实现，脱离服务器的管理呢？让我们不再为运行环境劳心伤神，不再为服务器的扩缩容半夜惊醒，当流量洪峰来临时，自动调配更多的服务器资源支撑，当流量低谷时，自动释放服务器资源节约成本。4. 「Serverless时代」：不必关心运行环境和服务器资源的调配。
Serverless的基本概念
广义上来说，Serverless 是一种后端架构理念，直接翻译过来叫做 “无服务”，但是不要被字面意思误导，这并不代表着应用运行不需要服务器。 在 Serverless 时代之前，可以将传统架构统称为 Serverful 时代， 意思就是关于服务器的一切都需要人工干预。 而Serverless，更准确的说，应该是开发者不用关心服务器的意思，是将服务器相关的工作交给云平台来做，对于开发者来说，与服务器运维有关的所有工作都不再关心，Server（服务器）是不可能真正消失的。 Serverless 所希望的，是开发者用代码去支撑业务逻辑，而对于资源的管理交给工具和云。 在 Serverful 的架构下，我们需要关心的问题非常多，比如：根据业务流量大小等指标，响应式地调整服务规模，实现自动弹性伸缩。再比如异地容灾、负载均衡、日志监控、文件存储等等，解决这些复杂的问题需要投入大量的人力、物力， 而在 Serverless 架构下，开发者只专注于开发业务逻辑，所有的这些与业务无关的基础设施，全部交给云平台负责，由云平台统一调度、运维。 
在这样的理念指导下，各家云平台厂商，都有不同实现方案，每家云平台提供的 Serverless 服务，都或多或少的存在差异，但是，按照 CNCF (云原生计算基金会) 对Serverless 计算的定义： Serverless 架构应该是采用 FaaS（函数即服务）和 BaaS（后端即服务）服务来解决问题的一种设计。
从应用落地的角度，狭义的 Serverless 就是 FaaS+BaaS 的组合。
Baas 后端即服务
Serverless 把运维的工作全部包揽下来，硬件的维护，集群的管理，运行环境的搭建，全部由云平台完成。除此之外，像缓存、数据库、文件存储、消息中间件等，也全部由云平台帮我们做好，封装起来，以接口的形式提供服务，这就是 BaaS，所谓后端即服务。对于开发者，BaaS 就是一个黑盒，你不用知道我怎么做，更不需要关心我如何做，你需要什么过来拿就行了。设想一个场景：向数据库存一条数据，用户上传的照片裁剪以后存到文件存储中，这是需要我们编写业务逻辑代码完成的功能。 假设我现在已经把这些逻辑代码写好，用的是 Node.js ，前面说所有的服务器及运行环境都放在了 BaaS 这个黑盒子中，我怎么让这些代码运行呢？换句话说就是，我现在写的逻辑代码，是需要 Node.js 这个运行环境的，怎么办？ 只需要将写好的代码，交个 Serverless 就行了，Serverless 中有专门运行逻辑代码的地方，这个地方就是 FaaS。
Faas 函数即服务
FaaS 是以函数的方式运行代码，本质上 FaaS 就是一个函数运行平台，大多数的 Serverless 云平台提供的 FaaS ，都支持 Node.js、Python、Java、PHP 等编程语言，你可以选择你喜欢的编程语言编写函数并运行。对于开发者来说，使用 FaaS 几乎就是使用 Serverless 的一切了，在 FaaS 中，我们能够体会到 Serverless 全部的特性。首先 FaaS 函数运行时，开发者对底层的服务器是无感知的，FaaS 产品会负责服务器资源的调度和运维，这些就是我们前面说的 BaaS，这也是 Serverless 最大的特点，无运维。 其次，FaaS 中的函数也不是持续运行的，而是通过一定的条件进行触发，比如 HTTP 事件、消息事件、定时器事件等，产生事件的源头叫触发器，FaaS 平台会集成这些触发器，我们直接用就行，这是 FaaS的第二个特点，事件驱动。 再者就是 Serverless 的付费方式了，与其他云产品不同的是，Serverless 的付费方式是按量付费，是按照 FaaS 函数执行次数和执行时消耗的 CPU、内存等资源进行计费的，用多少付多少，不用不付费，同时，FaaS 会根据并发量自动生成多个函数实例，BaaS 会根据函数运行所需要的资源量自动调配服务器资源，理论上的资源调用量没有上限，这也就实现了不同访问量的弹性伸缩了，而且是实时的弹性伸缩。
总结
基于 FaaS 和 BaaS 的架构，是一种「计算」和「存储」分离的架构。计算和存储也被分开部署和收费。这使应用的存储不再是应用本身的一部分，而是演变成了独立的云服务，降低了数据丢失的风险。而应用本身也变成了无状态的应用，更容易进行调度和扩缩容。基于 FaaS 和 BaaS ，你的应用就实现了自动弹性伸缩、按量付费、不用关心服务器，这正是 Serverless架构的必要因素。所以说狭义的 Serverless 是 FaaS 和 BaaS 的组合。 
Serverless的优缺点
Serverless 可以不用运维、实现自动的弹性伸缩、按量付费节省成本、更高的安全性、易于迭代和部署。 缺点 Serverless 的能力是云厂商打包提供的，所以 Serverless 产品一定是和云厂商绑定的，又因为Serverless 理念和具体实现之间并没有统一的标准，比如 A 厂商认为 Serverless 的数据库必须使用标准SQL 规范，而 B 厂商则认为数据库可以使用 SQL 规范也可以使用 JSON 文件的存储方案，这就出现了不同的云厂商实现了不同的 FaaS 接口，我们的同一套代码，是无法在不同的 Serverless 产品上运行的，要想从一个云平台迁移到另一个云平台，成本非常高。 Serverless 应用依赖的云服务，难以在本地环境搭建，要想在本地开发调试非常复杂。同时，Serverless 架构正处于飞速发展的阶段，其开发、调试、部署工具链并不完善。 目前 Serverless 的技术实现是 FaaS 和 BaaS。我们的应用代码在 FaaS 上运行，但 BaaS 是个黑盒，其底层的硬件资源是不确定的，某些场景下，代码必须运行在某种类型的 CPU 或 GPU 上，目前云厂商并没有提供针对底层硬件的可选项。
|
