前端圈从来不缺少新的技术、点子和话题，有些留下来了而有些则转瞬即逝。在决定一种新技术是否能够长久的所有因素里，最核心的必然是自身实力过硬能够经受住实践检验。而除此之外，这项技术所解决问题的广泛程度、受众群体规模等“非技术因素”也至关重要。
比如一经问世便话题性十足的React时至今日不论是自身还是其优秀的效仿者们都仍旧高歌猛进，高性能的vdom和高效率的数据驱动开发模式固然是其立足的基本，但React能够高度普及的另一个关键因素也不容忽略，那就是它解决了前端开发最表面也是最广泛的问题：UI编程。这可以说是从前端这一岗位自诞生以来最核心的关注点，而且不论什么类型的web应用都无法脱离它。
但是很少人知道React的数据驱动UI的模式早在2011年的D3.js中就有很成熟的应用，一个重要的原因是面向SVG编程的D3.js受众群体太小，只有从事SVG数据可视化编程的人才会使用它，所以没有很高的传播度。
之所以讲React和D3，是因为今天我们要讨论的是一种不论从普及的速度上还是话题性上都非常惊人的技术理念-Serverless。
Serverless解放了后端和运维，前端呢？业内对于Serverless的正式得名来自何处并没有绝对统一的看法，但一种相对普遍的认知是始于亚马逊AWS Lambda。自2014年始，在AWS Lambda之后，Google、IBM、Microsoft、腾讯等国内外云厂商们相继推出类似的云函数计算平台，称为FaaS。时至今日Serverless=FaaS的误解仍未完全消除，不过Serverless=FaaS+BaaS的理论模型已经趋于标准。各类社区、论坛和技术大会对此的讲解有很多，本文便不再赘述。
提一个有趣的东西，早年间折腾过“梯子”的小伙伴肯定熟悉一个很好用的工具：Google App Engine，简称GAE。虽然Google将GAE定位为一种SaaS产品，但GAE本身可以被拆解为很多细分的功能，在这些能力之上开发可以开发自己的SaaS产品。在这个角度上GAE很符合目前技术圈对于Serverless的解读。
Serverless最直观的优势是解放了传统后端和一部分运维工程师的生产力。原本由web server承载的业务逻辑转交给FaaS平台的一个个函数，没有了服务器硬件的束缚，也舍弃了MVC之类的架构模式，只剩下业务逻辑本身。服务部署在云端能够节省很多运维成本，什么交换机、路由器、刀片服务器等等全都与开发者无关。
Serverless可以称得上是一种转变软件开发范式的理论。软件开发技术经历几十年的发展历程到今天，开发者在Serverless的加持之下，从原始的聚焦于系统架构和软件架构两者，转变为只关注软件架构本身。
Serverless无疑是一个伟大的理论，但不论是系统架构还是软件架构，交付给用户的形式终究要依托应用端。而Serverless本身并没有关注于解决对端问题上。这像极了通信技术领域的“最后一公里”问题：通信服务商们克服了重重困难将电缆跨过了陆地和海洋，最终却在抵达用户计算机的最后一公里之前遇到了瓶颈。
在对端的最后一公里，Serverless还缺少什么？这个问题其实已经超越了狭隘Serverless的范畴，更准确地表达是：在Serverless的基础上，如何设计合理的对端解决方案？
解决问题的关键在于FaaS层。
目前市场上提供FaaS服务的云计算厂商中，包括AWS Lambda、Azure Functions、阿里云的Function Compute以及腾讯云的SCF，在应用端调用函数的方式大都以http API的形式为主。这跟传统的web server接口在调用方式上并无本质区别。
http api本身没有任何问题，问题在于调用请求直接送达FaaS函数有很多不便和隐患。FaaS函数很接近函数式编程思想里的纯函数。函数本身是无状态的，但是业务逻辑是有状态的，最典型的场景是用户鉴权。这并不是很复杂的业务逻辑，但是如果一个FaaS函数来承担的话，那么这个函数便跟业务有了强耦合性，变得不再“纯”，成为了一个“高阶函数”，同时还有一定的安全隐患。
对于这类FaaS平台，比较普遍的做法是在FaaS之上另行搭建一层API Gateway，用来做鉴权、session维护等与业务相关的工作，同时充当FaaS层代理的角色。
部分厂商提供了API Gateway能力。
这是一种比较合理的接入方式，但需要开发者付出一定的成本，不论是自行搭建API Gateway还是使用云厂商提供的能力。没有做到“开箱即用”的便捷性，这也是最能够体现云开发优势的一点。
云开发：Serverless最后一块拼图