项目遇到的难点、印象深刻点总结

一、概念serverless、为什么(前端)要推动建设 Serverless?
应用的运行演变为更细粒度函数的运行,用户开发特定业务的处理函数,托管给函数平台,按需使用相关的后端服务,通过特定条件的触发完成开发者业务逻辑函数的计算。用户无需为应用持续付费,只需支付函数运行时产生的资源消耗费用,而这,就是 Serverless 服务的模型。
1、更快地创建一个服务且
免运维
:大量的 Node.js 服务,创建服务,需要申请节点、申请机器,对接构建、部署、日志、监控,还要持续运维。我们希望能更快创建一个服务并且免运维。
2、大量低峰期时间cpu/内存利用率很低,服务不再使用了,资源却仍然占用
3、业务同学可以更专注于业务编码,简单、高效完成这么一个日常开发迭代的流程
cli 设计包含核心模块、默认命令、webpack相关、配置规范、以及基于cli 框架上层打造的插件生态
因为是应用级Severless方案,服务部署过程还是需要经历构建代码、编译镜像、以及整个应用级的部署。故我们基于Runtime的设计,结合Nodejs热更新能力,来支持页面级发布能力,轻量微应用类型工程。它支持静态页面、接口、动态页面、接口、页面模板、中间件等抽象,打造该工程类型的物料生态
不同场景下一致的开发体验,包括创建、构建、开发、部署等执行dev 时会一件启动前端资源webpack服务,同时启动服务端runtime服务,打开导航页面。另外部署,可以执行 sls deploy, 通过 cli 将服务、按场景先后,按流量分组部署到 Severless 平台。也可以通过 Vscode 插件可视化方式进行操作,进行部署、回滚。
是一个面向运营,集合了多个业务线后台系统。这里的菜单栏是配置集成起来的,每个菜单项是一个独立的页面,目前我们还没有采用微前端的一些轻量的隔离方案,使用的是简单、有效的iframe来进行隔离的。每个页面即服务,由每个业务线团队里的每个同学,用他们熟悉的技术栈,通过的前面介绍的微应用解决方案,独立运维。

二、滥用promise.all
用户信息页面挂掉了, 整个页面的是空白的(无数据)。打开浏览器调试了一下,发现只是一个获取用户的接口挂掉了。那么一个接口挂掉了为什么会导致整个页面无数据呢?
传递一个promise的数组,当所有的promise都完成(resolved),回调所有成功的结果, 或者有一个失败, 回调第一个失败的结果。
promise.all将多个promise放在一起处理,能简化回调的处理,一个then回调拿到所有数据进行处理,也能一个catch回调捕获所有的异常。
那么就意味着以下两点:

  • 如果有一个回调执行失败,then是不会执行的,或者说,所有的promise也都失败了
  • 即使有几个promise已经进入resolved状态,也会阻塞在那里直到所有的promise完成。

第一点会使得项目的容错大大降低,也许可能只是一个不关键的数据加载失败,其他所有的数据也不会显示。
第二点有违JavaScript非阻塞的理念,如果一个回调迟迟不能拿到结果,大家就都干等着了。

什么情况下才使用promise.all
几个异步操作是强相关的,后续步骤必须依赖这几个步骤全部成功才能进行。比如假设一个支付操作需要用户账户有余额,并且商品有库存,才能进行下一步操作,那么我们也许需要Promise.all来处理。

你可能感兴趣的:(javascript)