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

一、概念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来处理。