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

Posted 2020-11-22 cloudbase

云开发如何解决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对端解决方案为目标。

源码地址

https://github.com/TencentCloudBase/Good-practice-tutorial-recommended

---

如果你想要了解更多关于云开发CloudBase相关的技术故事/技术实战经验，请扫码关注【腾讯云云开发】公众号～