1.1.9 核心诉求
为什么需要Serverless
前端为什么想要上Serverless，其实也很好理解，随着node.js的普及、前端工程化以及BFF的兴起，越来越多的前端需要关心服务的构建、部署、运维，服务的日志、监控报警等等，严重拖累了前端的开发效率，让前端花很多时间在服务器上排查问题，无疑是痛苦而低效的。
对于前端来说，最原始的诉求是，我不愿意管服务器等底层资源，哪台节点宕机了，麻烦不用通知我；流量太大了，服务需要扩容了，我也不想关心；我只需要写好代码，就可以自动部署到服务器上，代码有bug，能让我看日志和监控排查问题就行。
其实这也不单单是前端的梦想，很多后端或者数据类的研发，也有同样的需求。不过咋看很美好，但是仔细想想，有一些后端的业务很复杂，服务间调用关系以及各种特异化需求其实很难适用于Serverless，想完全不关心底层的服务器，有点困难。
所以，Serverless并非银弹，关键是看业务场景和需求，就算只有50%的业务适合，能解决这50%业务的问题，那也是了不起的成就。
Faas和Baas又是什么？
了解Serverless的同学，或多或少都听过Faas，Faas即Function as a service，一般称作函数即服务。
作为开发人员，只需要写一个函数，就可以在例如AWS Lambda等各种函数计算平台上运行起来，真正实现了对服务器的无感知，同时可以对外快速暴露API接口，可以基于函数级别的自动扩缩容，可以监听各种事件进行触发。
而且Faas结合云平台的webIDE，如果webIDE设计的足够好，可以给我们带来云平台上更方便的开发体验，结合云上的各种工具和生态，未来会有更大的想象空间。
不过，显而易见，以函数为最小粒度，有一些局限性。
微服务是以功能职责为划分，拆分成一个一个专注于特定功能和需求的服务，为了解决微服务之间的网络调用和流量管理，引入了很多服务治理等相关的功能和组件，可以想象一下，如果把服务模块再拆分为函数的粒度，函数之间的调用关系无疑会爆炸，再思考一下，如何把老的服务改造成Faas形态，如何复用函数之间的逻辑，如何管理大量函数代码，这无疑对开发者带来了很多困扰。
所以，Faas不太适合一般后台长期运行的web服务型应用，真正适合的是那些数据计算、批处理等业务，这些业务逻辑比较单一，运行完可以停止，而且更适合Serverless中基于事件触发的特性，冷启动的延时也无所谓。
Faas的一个基本特征是无状态，那实际上的数据或者状态该如何存储呢，所以说到Faas一般都会提及Baas，即Backend as a service，不过类似的Xaas的名词太多了，Baas这个名词看着就像是有人为了强行补充Faas没有干的活儿而起的。因此有些人粗暴的总结Serverless = Faas + Baas，当然如果你要强行认为Serverless就是函数计算，那这个也没有问题。
不过，我们的观点是：Faas只是Serverless的一种特例。在这个世界上，除了Faas，还有更多的无状态工作负载适合以Serverless的形态去运行。
