前端微服务的基本构思

前言

一个团队负责的项目（不管前后端还是全栈），随着时间的推移，会极大的可能发生下面的变化：

1.  单一项目，随着功能的增多，会变得越来庞大
2.  项目会越来越多，现有的人力，不足以维护当前众多的项目
3.  随着上述两个问题不断的加大，人力堆叠不可避免的产生
4. 人力堆叠必然会产生另外两个问题：1）人的能力不同  2）人的技术栈不同
5. 另外一个很重要的问题，当人员流失产生的技术债务

在后端，解决上述问题比较流行的解决方案之一 ---- 微服务架构；
如果我们将微服务的概念扩展到前端，那么需要满足哪些需求？
在这里我们且将前端微服务架构叫做微前端；

微前端

微前端我们希望

1. 最小程度独立开发
2. 最小程度独立部署
3. 轻耦合
4. 技术无关
5. 提高开发效率，减少开发时间

独立开发

细粒度开发，不论是一个大项目还是小项目，均可以拆分多个大小不一的小模块（app）
模块根据具体的业务场景，可进行打散和重新组合
模块与项目的关系可以是一对多（公用模块）或一对一 （单业务）

独立部署

一个单体的前端应用最大的问题是构建出来的前端资源文件（js,css)太大，若使用独立开发，则这些文件可以拆分成多个文件
可以按照不同的环境部署（如 CDN)

轻耦合

独立开发中，SPA的应用开发中DOM即API
前后端数据彻底分离
数据与业务分离

技术无关

我们必须组合app模块，若技术无关，那app可能是 angular, react, vue 等构成

那我们可以使用以下技术：

1. 使用后端模板引擎插入 HTML（渐进式从后端进行加载）
2. 使用 IFrame 隔离运行时（PostMessage)
3. 客户端 JavaScript 异步加载
4. WebComponents 整合所有功能模块
5. Single-SPA/Micro Frontends/Mosaic/Mooa/single-spa-angular-cli 【推荐】
6. 数据交互使用CustomEvent交互
7. 不同模块的数据使用共享事件总线
8. 使用不同的服务器缓存（squid, varnish, nginx），整合不同的模块

以上种种，只能更深刻说明一个观念
微服务属于分布式系统的概念之一，程式码并不会因此变得简单、短少，反而有可能为了处理外来的事件而变得更多
这似乎与我们期望的第五点相互矛盾，其实不然；
我们期望使用微前端架构提高个体的开发效率来相对的提高团队效率；
所以我们期望：

1. 技术有关（React），尽可能的约束团队使用的技术栈；
2. 代码规范以及最佳实践
3. 每个子模块必须有自己的命名空间
4. 相关API以及工具的说明文档