2020给个免费网站好人有好报,做购物微信网站,企业信息系统的功能和特点,模板包下载网站简介#xff1a;极客时间《Serverless 入门课》作者秦粤最新文章: 再次讨论正当时的 Serverless。文章分为三个部分#xff0c;分别是 复杂化for 云开发商; 简化 for 开发者#xff0c;以及团队使用 Serverless 的最佳场景。 作者说
在开始本篇内容前我想与各位开发者达成几…简介极客时间《Serverless 入门课》作者秦粤最新文章: 再次讨论正当时的 Serverless。文章分为三个部分分别是 复杂化for 云开发商; 简化 for 开发者以及团队使用 Serverless 的最佳场景。 作者说
在开始本篇内容前我想与各位开发者达成几个共识。
第一个共识软件工程没有银弹 Serverless 也不是银弹它并不是解决所有问题的万能公式。
第二个共识Serverless 能够解决的是运维域的问题它是解决特定领域问题的一个技术并不是无限延伸的与低代码没有关系。
第三个共识是复杂度守恒定律-泰斯勒定律Tesler’s law。典型例子就是苹果苹果的产品很容易上手操作。但本质上它整体的复杂度是守恒的它其实是把复杂的事情留给了系统开发工程师和软件开发的工程师让用户可以顺滑体验。同理 Serverless 也是如此把部署 or 运维应用、网站的烦复转交给了云服务商但整体的复杂度是不变的。
第四个共识是邓宁-克鲁格效应The Dunning-Kruger Effect大家在认知学习过程中都会出现这样的发展曲线从刚开始一无所知到对新知识的幻想再到失望的低谷缓慢爬坡。我们学习任何一个新事物都会经历这样一个曲线过程。Gartner采用邓宁-克鲁格曲线来解释新技术的发展周期。 个人认知曲线 Gartern 技术发展曲线
作为开发工程师经常会有这种体感新的技术层出不穷学的很累。Serverless 刚推出来时也一样大家对这个技术充满了无限的想象当想象到了一个巅峰以后会慢慢认识到想象与现实的差距切身去体会在产品中使用时就会掉到技术的低谷然后再缓慢的爬坡。
Serverless 正当时
本文将会通过三个部分为各位介绍 Serverless
第一个部分是“复杂化 for 云开发商”
第二个部分是“简化 for 开发者”
第三个部分会介绍一些我自己和我们团队使用 Serverless 时的最佳场景。
1、复杂化 for 云开发商
(1) Serverless 架构 Serverless 是一个集大成者它的整发展历史是站在巨人的肩膀上的。现在很多云服务商去跑一个函数底层都是这样架构。首先 Serverless 的运行底层会有一个 CaaS 层。它是一个Serverless化的容器服务大部分的应用服务都会跑在这一层上面容器调度现在开源的比较好的解决方案就是 K8s用 K8s 来调度容器底层 laaS 就是虚拟机最底层则是物理机。
CaaS 的实现的方式有很多Serverless 应用底层必须有CaaS服务的支撑。除了Docker以外vm 也可以是 CaaS 例如 Node.js 的 vm 也可以做 CaaS webassembly 也可以做 CaaS 等等。另外在做整体架构设计的时候还需要一个 Component 层去解决网络东西流量和南北流量的问题例如service Mesh和ingress的方案总体来说 Serverless 背后的架构设计基本都是如此。 (2) 云开发商不可变基础设施
CNCF对云开发商来说会有vendor-unlock的危机当所有云服务作为不可变基础建设复杂度下沉到K8s层架构变得通用。因为CNCF的架构整套框架是根据配置文件去迁移的可以部署在阿里云、也可以腾讯云、亚马逊的云上甚至自己搭建的私有云。
另外对云服务商来说他们以前积累的传统的优势(虚拟机 laas 层的运维优势和 Caas 层的平台级的优势就会渐渐失去。所以如果是 vendor-unlock 云服务商之间就会白热化地打价格战看谁能提供更好更便宜的服务。 广义的 Serverless 是整个云服务商运维体系的 Serverless 化。如传统提供一个MySQL 或 Redis必须让开发者意识到这是跑在服务器上的需要提供出来个 ip 但 Serverless 化Baas 化后开发者不需要再去关心这个服务到底是运行在哪里只需要申明我需要一个DB应用就可以自动去链接并消费DB。
狭义的 Serverless 不仅仅是 Severless Computing还指一个 FaaS 的应用是由 trigger也可以归并为BaaS FaaS BaaS 的架构组成的。现在云开发商在 Serverless FaaS 的这一层的核心竞争力是不断推出新的 BaaS 能力而 BaaS 主要是跟 FaaS 配套去使用的。
上面讲到的云服务商的不可变基础建设如下图所示开发者在最上面这层去部署应用根本不用关心底层的这些基础建设。现在云服务商提供的 Baas SDK实际上已经包含在你的这个 FaaS 的runtime里面开发者只需要把它当成一个函数接口去直接调用不用关心数据库部署在什么地方、要不要保持长链接等等。 2、简化 for 开发者 此图是 Gartner 在 2017 年推出的新兴技术发展状态当时Gartner觉得 Serverless 还是一个比较新的概念大家对它的认知还处于爬坡阶段但实际上到今天2021年Serverless 已经进入了平缓爬升期了大家对Serverless 可以解决运维域的问题有哪些边界的限制等等这些问题已经有了清晰的认知。
为什么最近这几年没有什么特别新的东西推出了原因在于 Serverless 这层没有特别新的概念诞生大家更多是在做FaaS应用基础建设。现有的各种Web应用场景场景是否可以Serverless化比如近期已经支持了的数据库 BaaS 化 websocket 支持 FaaS另外还有很多Web应用场景都是通过诸位的努力慢慢爬坡实现使其能够接近理想中的 Serverless 。 2021 年 Gartner 技术采纳建议图
图中画框的位置就是 Serverless绿色代表已经成熟可以看出现在的 Serverless 已经是一个比较成熟的技术了支持大部分Web应用的场景了所以各位开发者大家可以放心大胆地去尝试Serverless。
(1) 运维领域的 Serverless 国内很多人把 Serverless 翻译成无服务器或者叫无服务这都不太准确Severless的反义词是 ServerfulSeverful 的意思是需要特别关注服务器Serverless 的本质是为了降低心智负担不需要十分关心服务器只专注部署函数就行至于它怎么运行、底层有多少容器、底层有多少服务器来支撑它开发者都不需要关心。
传统的模式的前后端开发模式是由后端提供数据服务以前叫 SOA 是面向服务的编程现在比较流行的是领域驱动微服务前端消费组装数据。后端数据接口传统的方式是提供 HTTP API到现在的流行的 BFF (Backend For Frontend) 胶水层函数编排。配合微服务提供全量数据是目前业界比较流行的做法。那么未来的趋势将会全部 BaaS 化理想的状态是前后端一体化模型驱动不再需要再写接口。
结合 Serverless 做技术变革 Serverless ...
当下 Serverless 所处的阶段的优势是跟其他领域的技术结合 Serverless 结合其他领域来引爆许多技术变革。例如传统的微服务 Serverless 结合起来后可以做成 BaaS 化微服务。以前提供一个微服务是需要开发者去关心这个微服务部署在哪里但是加上 Serverless 后便不用管部署在哪里只需要关心怎么去调用即可。LowCode 加上 Serverless 可以让搭建出来的页面快速部署并上线之前的接口函数编排如传统的 BFF在未来都可以 Serverless 化变成SFFServerless for frontend很适合做前后端一体化方案。
2开发角色的转变前后端一体化
Serverless 出现后未来还会出现前后端一体化的局面。现在已经出现逻辑编排可视化的工具例如狼叔的 iMove 目前已经可以做到后端接口的可视化编排前端工程师去做一个后端的接口编排变得非常简单。由此可以预见前端工程师未来的职责可以往后端去延伸。 而原来的后端工程师会从传统的应用部署逐渐转化去做 BaaS 化服务级别的开发而未来运维工程师也会更偏向于向云端迁移。这个就是 Serverless 对研发生产链路带来的一系列变革。
3、Serverless 的最佳场景实践
对于 Serverless 使用最近场景的判定最便捷的方式就是去看云开发商支持哪些 Trigger 事件触发。 所以目前这个阶段各个云开发商都在不停的增加新的 Trigger。如图所示开发人员在写 FaaS 时是将HTTP request 包装成了 Trigger可以把FaaS函数想象成在封闭的一个包裹里面要如何唤醒这个包裹怎么打开这个包裹呢其实就是通过 Trigger 来唤醒。
另外Serverless的现阶段开发语言的重要性没那么高了语言只是去实现功能所需要的工具。CNCF 推出来以后 FaaS 就已经是与语言无关的了那么其实到底是Node.jsPHPPython 亦或是其他主流语言的代码FaaS都可以你甚至可以自建一个镜像自定义语言和执行环境。因此在Serverless后多语言的优势我们都可以借用比如用Python去处理AI数据Node.js去处理高并发网络I/O等等。
1SFF 数据编排
最佳实践就是 BFF Serverless这在阿里集团内部是十分常见的。由于阿里内部的大多场景后端都是 Java 工程师前端团队需要跟工程师去对接而后端工程师提供的就是HSF微服务可以把它理解为一堆 RPC 接口。以前就是部署一个 Node.js 应用去调接口拿到数据后对这些数据进行是清洗、处理放到前端页面去渲染。但是采用 Serverless 部署BFF的Node.js应用后基本不需要考虑跟进流量扩缩容、节省成本等问题。 2GitOps 模型
GitOps 对于小企业来说是非常适用的场景相当于可以自建一套自动发布上线的管道不再需要像以前一样修改一个版本便要测试一遍目前整个方案已经十分成熟了。Git 本身支持大量的 hook 函数所以打造这样一个流程也是非常容易的。需要关注的是要结合云开发商的能力比如阿里云发布流程便十分自动化在云下平台发布上线后可以支持线上的流量录制、回放。 3小而美的技术团队
最后一点是打造小而美的团队。在我的认知中技术架构有个强大制约就是组织架构会决定我们的技术架构。
就像前后端分离大多是因为组织架构定义了前端有前端的领导后端有后端的领导所以就会产生前端由前端的开发后端由后端的开发需要中间去联调基于API沟通。那我们如果要想打造一个小而美的团队怎样打破这个隔阂呢
Serverless 一个比较适合的场景就是通过前端的服务编排 SFF 将解决掉中间API沟通的问题后端去提供全量的服务即可。这种变革会迫使后端去做微服务化甚至后端研发采用Serverless 去做 BaaS 化这是反向的导推过程。如果我们的前端团队掌握了 Serverless 有三个优势前端的数据编排便不再需要再找后端工程师了GitOps 解决部署运维可以降低前端心智负担前端同学能够专心抽象业务模型。
作者简介
蒲松洋花名秦粤。极客时间《Serverless 入门课》作者。Serverless 和 Node.js 布道者目前负责阿里巴巴前端委员会标准化小组低代码小组--中后台搭建Node.js 应用微服务架构。在微服务、Serverless 以及中台项目中有着丰富经验。
原文链接
本文为阿里云原创内容未经允许不得转载。
