浅析基于Serverless的前后端一体化框架

Posted 2021-04-30 前端之巅

作者｜杨苏博

Serverless 是一种“无服务器架构”模式，它无需关心程序运行环境、资源及数量，只需要将精力聚焦到业务逻辑。基于 Serverless 开发 web 应用，架构师总是试图把传统的解决方案移植到 Serverless 上，虽然可以做到既拥有 Serverless 新技术带来的红利，又能维持住传统开发模式的开发体验。但是，Serverless 技术带来的改变可能不止这些，可能是颠覆整个传统 web 应用开发模式的革命性技术。

开发模式

业务应用的开发模式发展是从一体到分裂为前后端，再到前后端融合为一体的过程。

注意：后面所说的后端特指后端业务逻辑。

早期：一体

没有前后端的概念，那时候的应用都是单机版，所有的业务逻辑都写一起，开发人员不需要关心网络请求，这个时期的工程师完全专注于业务代码的开发。随着业务规模的增长，也暴露了很多问题：

• 高并发问题；

• 高可用问题。

说明：业务应用升级困难等一些问题，不是本篇文章所关心，所以就不一一列举出来。

现在：分裂

前端 + 高可用高并发运维裹挟着的后端业务逻辑：

说明：现在 Serverless 技术已经出现有一段时间了，不但没有解决开发体验的问题，反而带来更多开发体验问题。所以，在这里我并没有突出 Serverless 技术。

解决的问题：

• 高并发： 通过分布式部署和多级负载均衡等技术解决了业务的高并发问题。

• 高可用： 通过主从架构等技术解决了业务的高可用问题。

解决一个问题，带来一堆问题：

• 分裂业务应用： 为了解决高可用和高并发，业务应用引入了分布式架构，通过负载均衡和主从模式来保证高可用和高并发问题，但是这种解决方案对业务应用是侵入式的，从而导致原本高内聚一体化的应用分裂成前端和后端。
• 污染业务代码： 与高可用、高并发和运维相关的逻辑与后端业务逻辑交织在一起，让后端技术门槛变高，导致需要多个后端工程师才能掌握所有后端技术。
• 增加联调成本： 前后端的联调工作日益繁重，成了工程开发效率提升的瓶颈，新功能和 BUG 需要前后端工程师配合才能完成。如果你是全栈开发工程师，肯定深有体会，很多 BUG 一看就知道是前端问题，还是后端问题。
• 不匹配的前后端技术发展速度： 前端技术发展迅猛，后端技术相对稳定，前端只能被动地去适配后端，让前端最新的技术在使用体验上大打折扣。最理想的方式是前后端通盘考量，整体发展，不要出现本来后端只需要优化一行代码的事，让前端写一百行代码来实现。
• 限制了代码抽象： 因为实现的是同一个业务需求，所以前后端代码有高度的相关性。如果我们能在前后端代码之上抽象代码逻辑，肯定能有很大的作为。同时，代码的开发和维护也有质的提升，前后端分裂导致我们不得不局限在前端或者后端进行代码的抽象，抽象出来的代码可能是片面而重复的。
• 增加技术复杂度： 前后端分裂，前后端工程师各自为营，形成各自的技术栈，包括语言、工具和理念，导致单个工程师维护整个业务应用变得极度困难，也让前后端工程师排斥彼此的技术栈。随着时间的推移，技术栈差异越来越大。一个项目，不管多小，至少两位工程师以上，全栈开发工程师另当别论。

• 增加运维成本： 需要专门的运维工程师来运维。虽然现在通过技术手段降低了运维的成本，但是目前运维成本依然很高，难度依然很大。这也是为什么创业小公司喜欢全栈开发工程师，因为在创业早期，高可用和高并发的需求不是那么迫切，因而运维也相对简单。使用全栈开发工程师，不仅缩短了项目交付周期，而且也降低了公司的运营成本，这对创业小公司是至关重要的。

未来：融为一体

前端 + 后端 + Serverless + 平台服务   =>  业务应用 + Serverless + 平台服务：

说明：共享逻辑是前后端的共享逻辑。在过去，由于前后端分裂，很难做到前后端层面的代码抽象。前后端融合后，这件事变得简单自然。

带来的困惑：

• 前后端分工合作，不是很好吗？ 在过去，将一个复杂的问题分解成多个简单的子问题，高并发和高可用没法做到不侵入业务应用，这确实是一种很好的解法，也是没办法中的办法。前后端分工合作带来的成本问题越发凸显。现在 Serverless 透明地解决了高并发和高可用问题，那么我们为什么还需要从技术维度来划分，我们不是更加推荐按业务维度来划分吗？

• 后端依然很难，驾驭前后端的门槛依然很高？ 后端代码逻辑虽然没有了高并发和高可用的裹挟，还是会很难，比如 AI。我相信类似这种很难的业务，现在可能有，未来一定会有相关的开发工具包或者平台服务为我们解决，让这些很难的技术平民化。难的技术交给专业的人解决。

找回初心：

• 回归业务，前后端一体化。Serverless 技术的出现，解决了高可用、高并发和运维问题。作为工程师的我们是不是应该回头看看，找回初心，专注于业务代码。让原本在一起的后端业务代码与前端代码再次融合。因此，前后端一体化难道不是我们失去已久的应用开发终极解决方案吗？

现 状

Serverless 已经做到了以下两点：

• 工程师只需要关心业务逻辑上的技术；

• 拥有接近于传统应用开发体验（解决历史遗留问题，可能还有些距离）。

传统应用框架，食之无味，弃之可惜：

• 目前，很多用户已经感知到了 Serverless 带来的高可用、高并发和免运维的好处，用户能够很自然地想到如果能将现有的开发框架移植到 Serverless 上，那就再好不过了。Serverless 平台很自然会提供现有框架的移植方案。解决的问题是将传统的解决方案移植到 Serverless 上，让用户在 Serverless 上拥有传统的开发体验。

应用框架找回初心：

• 前后端业务逻辑代码的融合，即前后端一体化。

前后端一体化解决了什么问题：

• 解决了第二阶段开发模式中出现的问题，具体请参考：“解决一个问题，带来一堆问题”。

实现前后端一体化，欠缺如下：

• 基于 Serverless 的前后端一体化框架；

• 工具。

其中，基于 Serverless 的前后端一体化框架解决前后端一体化问题；工具屏蔽掉 Serverless 平台细节，提供一致的部署运维体验。

未 来

未来，开源社区会涌现大量基于 Serverless 的前后端一体化的框架和工具。WebAssembly 让前后端一体化打破了开发语言的限制，可以用任意开发语言开发前后端，如 Java、Go 等等。由于 javascript 是为前端而生，TypeScript 是目前活跃的前端开发语言，前后端统一用 TypeScript，其他语言可以通过 WebAssembly 技术让 TypeScript 语言来调用可能是最好的选择。

想要成为一个流行的基于 Serverless 的前后端一体化框架，需要具备这么几个特质：

• 开源不绑定；
• 社区化运营；
• 形成标准；

• 模型简单。

结 语

Serverless 技术让我们向新世界大门迈出了左脚，请让基于 Serverless 的前后一体化框架帮我们迈出右脚。同时，请别再叫我前端开发工程师，我是业务应用开发工程师。

作者介绍

杨苏博，阿里云高级开发工程师， 多年沉浸于基础软件研发，目前在函数计算团队从事工具链相关工作，致力于提升 Serverless 研发效能的全栈工程师。

12 月 6 日，ArchSummit 全球架构师峰会邀请美团点评研究员梁士兴担任“大前端趋势”专题出品人，与贝壳找房、滴滴、百度、阿里的专家们一起聊聊各自的前端技术实践经验。专题详情见下图：

想了解详情可以扫描图中二维码或点击【阅读原文】。大会报名倒计时，团购享更多优惠！联系票务小姐姐灰灰：15600537884 （同微信）