云开发如何解决serverless对端的最后一公里问题

前端圈从来不缺少新的技术、点子和话题，有些留下来了而有些则转瞬即逝。在决定一种新技术是否能够长久的所有因素里，最核心的必然是自身实力过硬能够经受住实践检验。而除此之外，这项技术所解决问题的广泛程度、受众群体规模等“非技术因素”也至关重要。

比如一经问世便话题性十足的 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 最后一块拼图

云开发并不是 Serverless，准确地说，它不是 Serverless 的全部。在目前技术圈对 Serverless 的认知基础之上，云开发以“最后一块拼图”的形态弥补了 Serverless 对端能力的不足。

云接入层不仅仅是一层传统的 API Gateway，同时会对应用端的每一次请求进行权限验证，包括云函数、存储以及数据库在内的所有能力都有细分的权限管理策略。

端与云接入层的通信流程隐藏在端 SDK 中，开发者使用比 http API 更便捷、更具语义化的函数语法进行调用。

关于函数语法与 http API 的优劣对比后续文章会详细讲解，敬请关注。

在云开发体系下，开发者省去了搭建 API Gateway 的人力和经济成本，真正做到了“开箱即用”。在端 SDK 的加持之下，开发者能够以更便捷友好的编码方式进行开发。

这些已经超出了 Serverless 的狭隘范畴，所以将本节开始那句话补充完整即为：云开发不是 Serverless 的全部，同时 Serverless 也不是云开发的全部。云开发的目标是在 Serverless 的基础上进一步弱化开发者对后台的感知，聚焦于应用开发本身上。

总结

“含着金汤匙出生”的 Serverless 仅用不到 5 年的时间便经历了从诞生到普及的历程，在当前的时间节点业内对于 Serverless 虽有公知但仍未绝对统一，大家都是踩着石头过河。云开发自 2018 年 9 月在小程序落地之后，从一开始的质疑大过认可到成为小程序开发的标配仅用了不到一年的时间，未来也将以成为标准的 Serverless 对端解决方案为目标。