乾坤调研(qiankun)

项目参考地址: 搭建 umi + qiankun + antd 的微前端平台

目前项目逐渐变的臃肿，项目启动(3分钟)、热更新速度(10~30s)、打包时长(4分钟以上)也越来越长，所以想采用微服务来实现独立运行和开发。

所以有了qiankun(乾坤)调研，在调研过程中发现了一些优缺点也发现了自己可能并不适合采用微服务，为何这样说呢？稍后会介绍到。

Why Not Iframe？，为什么明明可以使用 iframe 来且套但为什么还要费劲的去调研其它方式？

采用这篇文章中的最后一句话 【其中有的问题比较好解决(问题1)，有的问题我们可以睁一只眼闭一只眼(问题4)，但有的问题我们则很难解决(问题3)甚至无法解决(问题2)，而这些无法解决的问题恰恰又会给产品带来非常严重的体验问题， 最终导致我们舍弃了 iframe 方案。】

满足以下几点，你可能就不需要微前端

存在以下场景时，你可能就不需要微前端：

1. 你/你的团队 具备系统内所有架构组件的话语权简单来说就是，系统里的所有组件都是由一个小的团队开发的。
2. 你/你的团队 有足够动力去治理、改造这个系统中的所有组件直接改造存量系统的收益大于新老系统混杂带来的问题。
3. 系统及组织架构上，各部件之间本身就是强耦合、自洽、不可分离的系统本身就是一个最小单元的「架构量子」，拆分的成本高于治理的成本。
4. 极高的产品体验要求，对任何产品交互上的不一致零容忍不允许交互上不一致的情况出现，这基本上从产品上否决了渐进式升级的技术策略

满足以下几点，你才确实可能需要微前端

1. 系统本身是需要集成和被集成的 一般有两种情况：

• 1. 旧的系统不能下，新的需求还在来。没有一家商业公司会同意工程师以单纯的技术升级的理由，直接下线一个有着一定用户的存量系统的。而你大概又不能简单通过 iframe 这种「靠谱的」手段完成新功能的接入，因为产品说需要「弹个框弹到中间」
  2. 你的系统需要有一套支持动态插拔的机制。这个机制可以是一套精心设计的插件体系，但一旦出现接入应用或被接入应用年代够久远、改造成本过高的场景，可能后面还是会过渡到各种微前端的玩法。

1. 系统中的部件具备足够清晰的服务边界通过微前端手段划分服务边界，将复杂度隔离在不同的系统单元中，从而避免因熵增速度不一致带来的代码腐化的传染，以及研发节奏差异带来的工程协同上的问题。

结合以上调研结果，还有本人搭建案例【demo】，发现并不是所有项目都适合使用微服务。

乾坤微服务，只能作为导航引入，不能作为模块化项目引入，这样就带了一个问题，如果【耦合性】不能作为子项目开发，

结合自己公司项目，发现个别功能能够独立开发，作为子项目引入，比如本公司的【着陆页】没有在其他地方耦合，这样的项目可以拆分独立开发。

结论

微服务可以进行开发，但需要考虑真实情况，是否不存在耦合性，是否有必要做微服务，如果可以做优化，或者重构，建议优先考虑。