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

概述

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

开发模式

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

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

1. 早期，一体

没有先后端的概念，那时候的应用都是单机版，全部的业务逻辑都写一块儿，开发人员不须要关心网络请求，这个时期的工程师彻底专一于业务代码的开发。随着业务规模的增加，也暴露了不少问题：

• 高并发问题
• 高可用问题

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

1. 如今，分裂

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

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

解决的问题：

• 高并发。经过分布式部署和多级负载均衡等技术解决了业务的高并发问题
• 高可用。经过主从架构等技术解决了业务的高可用问题

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

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

这也是为何创业小公司喜欢全栈开发工程师，由于在创业早期，高可用和高并发的需求不是那么迫切，于是运维也相对简单，使用全栈开发工程师，不只缩短了项目交付周期，并且也下降了公司的运营成本，这对创业小公司是相当重要的。

1. 将来，融合回到到一体

前端 + 后端 + 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 的先后一体化框架帮咱们迈出右脚。同时，请别再叫我前端开发工程师，我是业务应用开发工程师。

 

Q&A

Q：先后端一体化须要将先后端代码发布到同一个地方吗？
A：不须要，分开发布，经过统一的工具负责先后端发布任务，前端能够发到 CDN，后端能够发布到 Serverless 平台，如：阿里云函数计算。

Q：将来是否是没有后端工程师？
A：有的。前端工程师只是把前端和后端的业务逻辑代码给作了，后端工程师去作真正的后端，那时候的后端工程师将会更加专业，前端工程师可能会变成应用开发工程师（暂且这么称呼）。对于中小型企业，可能大部分是应用开发工程，有少许甚至没有专业的后端工程师。

Q：为何不作一个相似 expressjs 这样的 web 应用框架？
A：expressjs 框架是在没有 Serverless 背景下设计的，没有考虑 Serverless 给咱们带来的技术架构变革，若是须要相似 expressjs 的这样的框架，咱们彻底能够将 expressjs 框架迁移到 Serverless 上运行，没有必要再造一套。

Q：为何是 nodejs 框架？
A：nodejs 和 前端 js 使用的同一种语言，能够将先后端一体化作到更加极致，webassembly 也可让任何语言在前端运行，也能作到先后端语言一致，可是 js 是为前端而生的，更有亲和力。可是其余语言能够经过 webassembly 编译成中间语言，nodejs 经过 vm 来调用其余语言提供的功能。也不排除将来会有一种新的运行环境来取代 nodejs，更加适配多语言和 Serverless 这种场景。

Q：先后端一体化的极致是一种什么感受？
A：先后端代码都在一个项目中用同一种语言来写，在本地定义一个后端接口方法，前端就像调用本地方法同样调用后端方法（不是在本地定义的后端接口也是同样，好比跨组件、外部服务），先后端能够抽象更多的公共逻辑，好比工具类等等，一个开发人员就能维护好整个项目，没有了多项目多语言的切换痛苦。

原文连接 本文为云栖社区原创内容，未经容许不得转载。