淘宝客网站免费建站,建筑工程网络设计,深圳思弘装饰设计,公司网站建设应注意事项概述
Serverless 是一种“无服务器架构”模式#xff0c;它无需关心程序运行环境、资源及数量#xff0c;只需要将精力聚焦到业务逻辑上的技术。基于 Serverless 开发 web 应用#xff0c;架构师总是试图把传统的解决方案移植到 Serverless 上#xff0c;虽然可以做到既拥…概述
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 的前后一体化框架帮我们迈出右脚。同时请别再叫我前端开发工程师我是业务应用开发工程师。 QA
Q前后端一体化需要将前后端代码发布到同一个地方吗 A不需要分开发布通过统一的工具负责前后端发布任务前端可以发到 CDN后端可以发布到 Serverless 平台如阿里云函数计算。
Q未来是不是没有后端工程师 A有的。前端工程师只是把前端和后端的业务逻辑代码给做了后端工程师去做真正的后端那时候的后端工程师将会更加专业前端工程师可能会变成应用开发工程师暂且这么称呼。对于中小型企业可能大部分是应用开发工程有少量甚至没有专业的后端工程师。
Q为什么不做一个类似 expressjs 这样的 web 应用框架 Aexpressjs 框架是在没有 Serverless 背景下设计的没有考虑 Serverless 给我们带来的技术架构变革如果需要类似 expressjs 的这样的框架我们完全可以将 expressjs 框架迁移到 Serverless 上运行没有必要再造一套。
Q为什么是 nodejs 框架 Anodejs 和 前端 js 使用的同一种语言可以将前后端一体化做到更加极致webassembly 也可以让任何语言在前端运行也能做到前后端语言一致但是 js 是为前端而生的更有亲和力。但是其他语言可以通过 webassembly 编译成中间语言nodejs 通过 vm 来调用其他语言提供的功能。也不排除未来会有一种新的运行环境来取代 nodejs更加适配多语言和 Serverless 这种场景。
Q前后端一体化的极致是一种什么感觉 A前后端代码都在一个项目中用同一种语言来写在本地定义一个后端接口方法前端就像调用本地方法一样调用后端方法不是在本地定义的后端接口也是一样比如跨组件、外部服务前后端可以抽象更多的公共逻辑比如工具类等等一个开发人员就能维护好整个项目没有了多项目多语言的切换痛苦。
原文链接 本文为云栖社区原创内容未经允许不得转载。
