阿八博客
  • 100000+

    文章

  • 23

    评论

  • 20

    友链

  • 最近新加了很多技术文章,大家多来逛逛吧~~~~
  • 喜欢这个网站的朋友可以加一下QQ群,我们一起交流技术。

写给前端工程师的 Serverless 入门

欢迎来到阿八个人博客网站。本 阿八个人博客 网站提供最新的站长新闻,各种互联网资讯。 喜欢本站的朋友可以收藏本站,或者加QQ:我们大家一起来交流技术! URL链接:https://www.abboke.com/jsh/2019/1010/116503.html
本文首发于政采云前端团队博客:写给前端工程师的 Serverless 入门

Serverless 是前端圈近两年比较火热的词汇,但其第一次被提出已经是 7 年前的事情,那么什么是 Serverless 服务,其架构由哪些部分组成,又有什么优缺点,本文将一一道来

趋势

参考《RightScale 2019 年云状态报告》,从 2018 年到 2019 年,Serverless 是公有云中使用率增长最快的服务,达到 50% 的增长速度,与 Streaming Process 并列第一

概念

我们把 Serverless 拆解为 server 和 less 两个单词,从字面上推断词意即为“少服务器的,亦或是无服务器的”
当然这并非指应用架构中是没有服务器资源的,而是通过 Serverless 这种服务形态,用户在使用对应的服务时,不需要关心或较少关心服务器的硬件资源、软件资源、稳定性等等,这些通常已经由云计算厂商提供设施、服务和 SLA 保障,完全托管给云计算厂商
而用户只需要专注自己应用代码本身,上传执行函数到相应云计算平台,按照函数运行的时长按量付费即可
当前比较成熟的 Serverless 云产品主要有 Amazon Lambda、Google Cloud Function、Azure Function、AliCloud Function Compute

演进

云计算诞生之前,大部分计算资源是处于“裸金属”状态的物理机,运维人员选择对应规格的硬件,建设机房的 IDC 网络,完成服务的提供,投入硬件基础建设和维护的成本很高

云计算诞生后,用户可以直接购买云主机(VM),把基础物理硬件和网络的管理都交由供应商管理,多用户租用一台物理机,但每台云主机对用户来说就像是单独的一台物理机,用户之间相互隔离
这种模式减少了用户硬件管理成本,站在平台的角度,我们通常称之为 IaaS(Infrastructure-as-a-Service)

随着软件的发展和容器技术的兴起,计算环境由 VM 发展到更小粒度的容器,在容器中可以运行不同的软件服务,PaaS(Platform-as-a-Service) 和 CaaS(Container-as-a-Service) 也开始映入眼帘
用户使用平台基础软件如 Database、消息等开发自己的应用,使用容器镜像构建和部署应用,最后托管给平台
此时基础设施的运维更加下沉,开发者只需关注基础软件和容器

继续向前发展,应用的运行演变为更细粒度函数的运行,用户开发特定业务的处理函数,托管给函数平台,按需使用相关的后端服务,通过特定条件的触发完成开发者业务逻辑函数的计算
用户无需为应用持续付费,只需支付函数运行时产生的资源消耗费用,而这,就是 Serverless 服务的模型

Serverless 其实是通过事件驱动的,当一个任务被触发时,比如 HTTP 请求,API Gateway 接受请求、解析和认证,传递对应参数给云函数平台,平台中执行对应回调函数,配合 DB、MQ 等 BaaS 服务在特定容器中完成计算,最终将结果返回给用户
函数执行完成后,一般会被 FaaS 平台销毁,释放对应容器,等待下一个函数运行

同样,Serverless 是一把双刃剑,它也有一些缺陷需要我们了解,以便取长补短:

云厂商强绑定 当你决定使用公有云的 Serverless 产品时,它们常常会和厂商的其他云产品相绑定,如对象存储、消息等等,这意味你需要同时开通其他的服务,将导致你的应用与平台强绑定,迁移成本剧增
不适合长时间任务 云函数平台会限制函数执行时间,如阿里云 Function Compute 最大执行时长为 10 min,如果你的任务时间超长,那么你需要拆分编排你的函数执行流程,并在一个函数执行结束时唤起另一个函数执行
这将增加编码的复杂度,而且花费上可能高于购买一个长时间运行的实例
冷启动时间 函数运行时,执行容器和环境需要一个准备的时间,尤其是第一次启动时时间可能会较长
对一个 HTTP 请求来讲,可能会带来响应时延的增加,产生性能毛刺
调试与测试 由于本地环境和平台运行环境的差异性,开发者需要不断调整代码,打印日志,并提交到函数平台运行测试,会带来一些开发成本和产生一些费用

应用场景

结合以上的优缺点,实践中我们可以发掘 Serverless 的落地场景,目前阶段 Serverless 主要适合以下的应用场景:

定时任务 通过时间触发对应的函数任务,完成开发者业务逻辑的处理
数据加工 通过事驱动件机制,在特定的条件下触发,对系统的日志进行整合,或者对多媒体文件进行加工等等
低频请求 用户可以按照频次付费,而无需构建一个应用来应对这些必要的但是量小的请求
IoT 物联网场景下,大部分是用户对设备的操控,用户对时延的容忍度较高,也是典型的事件触发且低频场景
认知计算 适用于某些 AI 场景,如聊天机器人

结语

目前,国内 Serverless 的发展还处于早期阶段,一些配套和服务处于待完善阶段,而且大型成功案例较少
但这并不妨碍我们对技术革新的热衷,站在前端工程师的角度看,Serverless 的持续发展,在将来可以使前端更加容易的使用 Node.js 等语言搭建一个完善的应用,只需关注前后端的业务逻辑本身,而较少关心底层庞大的软硬件系统和运维知识
未来也可能给前后端工作流程带来一定变革,比如更统一的技术栈、设计规范和数据结构;更高的开发效率——应用搭建、联调时间的缩短,促使 Web 前端工程师向 Web 应用工程师进化转型

参考资料

CNCF WG-Serverless Whitepaper v1.0

RightScale 2019 STATE OF THE CLOUD REPORT

函数计算

招贤纳士

招人,前端,隶属政采云前端大团队(ZooTeam),50 余个小伙伴正等你加入一起浪~ 如果你想改变一直被事折腾,希望开始能折腾事;如果你想改变一直被告诫需要多些想法,却无从破局;如果你想改变你有能力去做成那个结果,却不需要你;如果你想改变你想做成的事需要一个团队去支撑,但没你带人的位置;如果你想改变既定的节奏,将会是“5年工作时间3年工作经验”;如果你想改变本来悟性不错,但总是有那一层窗户纸的模糊… 如果你相信相信的力量,相信平凡人能成就非凡事,相信能遇到更好的自己
如果你希望参与到随着业务腾飞的过程,亲手参与一个有着深入的业务理解、完善的技术体系、技术创造价值、影响力外溢的前端团队的成长历程,我觉得我们该聊聊
任何时间,等着你写点什么,发给 ZooTeam@cai-inc.com

相关文章

暂住......别动,不想说点什么吗?
  • 全部评论(0
    还没有评论,快来抢沙发吧!