谈谈大家对微前端的看法

一个项目，有首页，搜索页，购买流程，账号页面，售后流程。
总代码 40 万行。除掉单测，快照，大概 20 万行。几十个前端开发协同工作。
React 项目，有完善的懒加载机制，服务端渲染。Router + Redux 。
由于公司收购，新公司的架构变更，这个项目要迁移到新的仓库，新的云供应商，新的项目外部依赖。
有人提议使用微服务来重新按 domain （首页，搜索这些）对这个项目使用微前端的概念来重构基础框架。
虽然是不同的 domain ，但是它们有相同的基础组件依赖，有公共逻辑依赖，状态在 Redux 。传统，规规矩矩。

下面是我个人在团队内提出的看法：

* 项目虽然有不同的 domain ，但是有公共逻辑和组件，使用微服务会导致公共逻辑重复。因为微服务的概念和模块联邦不一样，微服务是一个自洽的服务，它可以独立运行，所以它必须有完整的逻辑和依赖。这意味着，拆分出的微服务需要重复很多逻辑，会带来很大的维护负担。
* 我们不像门户网站，不同的 tab 对应不同的功能，可以根据 tab 拆分服务。比如，机票 tab 是机票团队的页面。酒店 tab 是酒店页面。它们完全是不同的服务。几乎没有公共业务逻辑（日志这些不算）。我们的服务没有 tabs 的概念。
* 主应用和子应用，子应用和子应用之间的状态传递会导致逻辑和 debug 的复杂度指数级上升。加大了开发的心智负担。很多团队不止工作于一个 domain ，而是交叉的。
  * 这里我们考虑多一点。我们使用 styled-component ，所以 CSS 的隔离是一定要的。否则 id 会重复。
  * 既然拆分了，那就意味着我们需要独立部署每个微前端，每个微前端就需要照顾自己的服务端逻辑，比如预热，比如服务端数据请求。我们现在的拆包已经可以达到“浏览器只需要请求需要的 bundles”的目的了。所以独立部署带来的好处不大。
  * Redux 的状态共享，我们需要额外的机制来实现微前端的状态共享。
* 严格考虑是否提升了用户体验和浏览器端性能。没有，反而降低了性能。增加了重复的逻辑和代码量，增加了资源消耗，复杂度增加。
* 微前端本身是为了屏蔽不同技术栈，在同一页面展示和共享状态的，我们的服务本来就是一个整体服务。所有的公共逻辑都是一样的。
* 虽然微前端可以让我们渐进式的迁移，但是后期整合带来的效率低，和复杂度的问题也是需要严格审视的。

学识尚浅，有核心的东西没有考虑到吗？我不知道该用什么来作为辅助验证我说法的东西。

module federation

菜鸡求解，好奇这种情况下，会使用 mitt 这样的事件对象做一个大的管线吗

直接把微前端框架调研一遍就知道了吧？在 issue 列表里面找几个万年不改的关键性问题拿出来给大家展示展示，要是有人拍板说都能接受。那就啥也别说了，改呗。

状态共享，内存/性能管理，加载优化是三个比较大的问题，据我调研的结果来看，没有哪个微前端是真正提供了解决方案的，本身它们也并不承担这部分责任。

状态共享相对简单一点，写代码就能解决的事情不是事情。

内存/性能管理在于要根据不同的微前端框架进行调整，还会增加所有人写代码的心智负担。你测试写的很好的情况下，对测试也会带来更多成本，单测之外肯定要为性能而考虑做页面的压力测试。

加载优化我也没想到好办法。对于首页来说加载问题是必须要解决的，首页的子页面越多，加载的文件量和渲染性能都有可能线性增长。尤其如果同时启动多个框架进行初始化或者渲染，想想都会头大。不过你只有 React ，会好解决一点。但是这个也会影响首页的指标啊，这责任谁承担呢？

微前端一开始就设计架构来做还行，统一规范。
后面集成的，最后只会变成非常庞大的工程，揉在一起。
并且基座会有非常多的问题等着解决，甚至有很多问题无法解决。

不管前端后端，一个项目最初的技术架构选型基本上决定了它的上限。
可见的未来也不会改，很难改的动。

vue
模块联邦和 qiankun 都用过
建议还是模块联邦……
微前端一个是 vue 的 keep-alive 要弄的和单体应用效果一样没弄成功过，也可能实是我那项目有魔改的 vue-router 的原因

模块联邦相对的问题少点

你这种很适合用 monorepo

@JefZ 那你们为啥不试试 monorepo + micro web?的方式

在团队内折腾过，实践下来发现：

之前考虑的各个子应用独立开发优势完全没有展现。因为在实际业务中，一个需求经常会出现跨子应用开发，多个子应用经常共用一些状态、数据、依赖。

反而页面性能、数据传输、依赖共享、心智负担都会成为隐性的技术债。

在最开始得到的一点点小好处，最终都会成为架构上的大麻烦。