收益 or 挑战?Serverless 究竟给前端带来了什么
为了减少写后端业务逻辑时,环境、部署问题的干扰,许多团队会将业务逻辑抽象成一个个区块(Block),对应到代码片段或 Blockly,这些区块可以独立维护、发布,最后将这些代码片段注入到主程序中,或动态加载。如果习惯了这种开发方式,那也更容易接受 Serverless。 更厚的后台服务 站在后台角度,事情就变得比较复杂了。相对于提供简单的服务器和容器,现在要对用户屏蔽执行环境,将服务做得更厚。 笔者通过一些文章了解到,Serverless 的推行还面临着如下一些挑战: Serverless 各厂商实现种类很多,想让业务做到多云部署,需要抹平差异; 成熟的 PaaS 服务其实是伪 Serverless,后续该如何标准化; FaaS 冷启动需要重新加载代码、动态分配资源,导致冷启动速度很慢,除了预热,还需要经济的优化方式; 对于高并发(比如双 11 秒杀)场景的应用,无需容量评估是很危险的事情,但如果真能做到完全弹性化,就省去了烦恼的容量评估; 存量应用如何迁移。业界的 Serverless 服务厂商大部分都没有解决存量应用迁移的问题; Serverless 的特性导致了无状态,而复杂的互联网应用都是有状态的,因此挑战在不改变开发习惯的情况下支持状态。 所幸的是,这些问题都已经在积极处理中,而且不少有了已经落地的解决方案。 Serverless 给后台带来的好处远比面临的挑战多: 推进前后端一体化。进一步降低 Node 写服务端代码的门槛,免除应用运营的学习成本。笔者曾经遇到过自己申请的数据库服务被迁移到其他机房而导致的应用服务中断,以后再也不需要担心了,因为数据库作为 BaaS 服务,是不需要关心在哪部署,是否跨机房,以及如何做迁移的; 提高资源利用效率。杜绝应用独占资源,换成按需加载必然能减少不必要的资源消耗,而且将服务均摊到集群的每一台机器,拉平集群的 CPU 水位; 降低云平台使用门槛。无需运维,灵活拓展,按价值服务,高可用,这些能力在吸引更多客户的同时,完全按需计费的特性也减少了用户开销,达到双赢。 利用 Serverless 尝试服务开放 笔者在公司负责一个大型 BI 分析平台建设,BI 分析平台的底层能力之一就是可视化搭建。 那么可视化搭建能力该如何开放呢?现在比较容易做到的是组件开放,毕竟前端可以与后端设计相对解耦,利用 AMD 加载体系也比较成熟。 现在遇到的一个挑战就是后端能力开放,因为当对取数能力有定制要求时,可能需要定制后端数据处理的逻辑。目前能做到的是利用 maven3、jdk7 搭建本地开发环境测试,如果想上线,还需要后端同学的协助。 如果后端搭建一个特有的 Serverless BaaS 服务,那么就可以像前端组件一样进行线上 Coding、调试,甚至灰度发布进行预发测试。现在前端云端开发已经有了不少成熟的探索,Serverless 可以统一前后端代码在云端开发的体验,而不需要关心环境。 Serverless 应用架构设计 看了一些 Serverless 应用架构图,发现大部分业务都可以套用这样一张架构图: 将业务函数抽象成一个个 FaaS 函数,将数据库、缓存、加速等服务抽象成 BaaS 服务; 上层提供 Restful 或事件触发机制调用,对应到不同的端(PC、移动端); 想要拓展平台能力,只要在端上做开放(组件接入)与 FaaS 服务做开放(后端接入)即可。 收益与挑战 Serverless 带来的收益与挑战并存,本文站在前端角度聊一聊。 收益一:前端更 Focus 在前端体验技术,而不需要具备太多应用管理知识。 最近看了很多前端前辈写的总结文,最大的体会就是回忆 “前端在这几年到底起到了什么作用”。我们往往会夸大自己的存在感,其实前端存在的意义就是解决人机交互问题,大部分场景下,都是一种锦上添花的作用,而不是必须。 回忆你最自豪的工作经历,可能是掌握了 Node 应用的运维知识、前端工程体系建设、研发效能优化、标准规范制定等,但真正对业务起效的部分,恰恰是你觉得写得最不值得一提的业务代码。前端花了太多的时间在周边技术上,而减少了很多对业务、交互的思考。 即便是大公司,也难以招到既熟练使用 Nodejs,又具备丰富运维知识的人,同时还要求他前端技术精湛,对业务理解深刻,鱼和熊掌几乎不可兼得。 Serverless 可以有效解决这个问题,前端同学只需要会写 JS 代码而无需掌握任何运维知识,就可以快速实现自己的整套想法。 诚然,了解服务端知识是有必要的,但站在合理分工的角度,前端就应该 focus 在前端技术上。前端的核心竞争力或者带来的业务价值,并不会随着了解多一些运维知识而得到补充,相反,这会吞噬掉我们本可以带来更多业务价值的时间。 语言的进化、浏览器的进化、服务器的进化,都是从复杂到简单,底层到封装的过程,而 Serverless 是后端 + 运维作为一个整体的进一步封装的过程。 收益二:逻辑编排带来的代码高度复用、可维护,拓展 云+端 的能力。 云+端 是前端开发的下个形态,提供强大的云编码能力,或者通过插件将端打造为类似云的开发环境。其最大好处就是屏蔽前端开发环境细节,理念与 Serverless 类似。 之前有不少团队尝试过利用 GraphQL 让接口 “更有弹性”,而 Serverless 则是更彻底的方案。 我自己的团队就尝试过 GraphQL 方案,但由于业务非常复杂,难以用标准的模型描述所有场景的需求,因此不适合使用 GraphQL。恰恰是一套基于 Blockly 的可视化后端开发平台坚持了下来,而且取得了惊人的开发提效。这套 Blockly 通用化抽象后几乎可以由 Serverless 来代替。所以 Serverless 可以解决复杂场景下后端研发提效的问题。 Serverless 在融合了云端开发后,就可以通过逻辑编排进一步可视化调整函数执行顺序、依赖关系。 (编辑:应用网_阳江站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |