各位客爷大家好啊，过年了不知道各位是否又胖了一些，反正老菜鸟是没少长肉。
光吃不练肯定是不行，所以趁着过年这两天写写博文，动动脑子，多少也能消耗一点热量吧...
今天咱们华山论剑的主题是monorepo跟模块联邦这种基础操作性强的微前端方案，像是业内已经成型的qiankun、飞冰这种成熟的微前端类库不做讨论~
先来说说为什么要自己搭架构，不去用现成的框架或类库呢？在下愚见，这个也是要根据场景具体分析的，现有框架的优点是前面的人把这个方向的坑都趟过了，并搭建出了一套可行性方案，我们拿过来用即可，快速、可靠。
但事物都有两面性，我们降低了自己的认知成本，不需要清楚底层运转逻辑也可以快速玩转起来，如果是个小微企业快速起步阶段，用框架是最合理的选择，我不需要多精通的技术功底，拿来直接能用能出活就行。但如果是个业务能力成熟，追求效率与底层安全性的中大厂，完全依赖框架就不合适了。👇🏻
要产出最适合自己公司业务的组合型方案，打破重度依赖框架导致的底层数据流盲区，弃置完全不需要用到的功能模块，重新拆解并合理组合技术栈，达到解决问题的最优架构方案。
—— 前端装逼架构师 Yubble
简单地说毕竟是自己写的，哪出的问题我一下就能找得到。
扯远了，咱们再回到正轨~
想要聊明白 monorepo 跟 模块联邦 在微前端多应用架构下区别的话，就要对他俩有个基本的认识。
先说他们的作用吧，都能将庞大的单体项目拆分成独立维护的子模块，将风险及工作量分散。毕竟都是微前端时代的产物，一个‘拆’字就能将他们体现到淋漓尽致。
但是但从拆上来说也是有所区别的：
Monorepo（单仓库）:
将以前分为多仓库存储，却又在业务联系上紧凑的个体项目整体放在同一个仓库中管理起来。
用这种技术方案去实现微前端，那么各个子应用都能放在一个仓库之内，要分离的是他们的业务逻辑，工程化以及工具方法都是可以通用的，所以它的结构大概是这样的：
可以看到这种方式的微前端架构方案还是偏传统的基座方式，工程化及通用的工具方法是基座提供的，子应用被单独的物理隔离起来，只有在工程构建及使用通用方法时，才需要用到基座提供的能力。其他子应用的文件夹中只包含子应用业务逻辑，至于怎么开发，怎么维护就是各个业务团队自己的事啦。
优点：抽象部分明显，新应用创建无需考虑任何非业务能力成本。换句话说就是我的架构搭建好了，再新增业务线也就只是做业务增量的事，工程化部分完全不需要考虑，都是基座中集成的。
缺点：子应用需要依赖基座才能运行，且基座身负着所有子应用的共同打包及公共方法，所以需要额外的人力成本去做基座的安全性维护。
module federation（模块联邦）:
基于webpack5，将某一功能赋予外化能力，既能在自己的项目中运行，也可以被其他项目所引用。
而使用这种方式实现的微前端，对于仓储格式没有特别的要求，开发编译打包全部自顾自，只对外暴露一个出口，供外部加载，架构图来表示的话就是这样：
模块联邦不光将子应用拆分开，连带每个子应用的工程化一同隔离开，这也就使得各个子应用完全不用去关心对方使用什么技术栈，什么安全策略，只要知道我能从对方那里拿到什么组件或方法即可。
这样的隔离方式子业务团队不光需要维护自己的应用项目，还需要维护自己子应用的工程底座。不过一整套代码全部抓在自己手里，掌控感和开发自由度都是很满的。
优点：各个子应用的团队都有一整套完整的工程代码，无需依赖基座进行工程构建等编译时工作。所以就算每个团队的技术栈，编码规范及构建流程都不一样，只要支持模块联邦，那么就都能加入到这个去中心化的微前端项目中。
缺点：对于各个团队要求整体提高，前端工程化需要每个团队自行维护。且没有基座，如果需要进行编译时的统一工作，需要逐个团队进行推动及改造，对于工具类的统一收口不太好做限制。
对比汇总
两种方案虽然都是把业务拆分的有效方式，但如果从规范普及、交付风险把控上来看的话，两类方案的适用性还是有所差别的。
打个比方：
monorepo更像是加盟商模式，总部把各个加盟商召集在一起，提供店面装修，食材功能等帮助，门店由加盟商自己经营，有靠山有保障，但是也要遵守总部的规则，否则无法进行加盟。
module federation像是部落的联盟，签署了协议之后各个部落可以进行某些资源的共享，比方说我把护卫战士借给联盟其他部落，又或者我把炊具整个分享出去。但是我的部落还是我的部落，它怎么发展，是畜牧还是耕地我们自己决定。
这么看来~
集中仓库（monorepo）规范对子应用有保障，有助力。但是也剥夺子应用一部分独立性。模块联邦拒绝中心控制，可以将代码共享给其他应用，缺不允许任何人来对我进行内部干扰。
—— 前端装逼架构师 Yubble
中心化与去中心化
都聊到这了，那我就结合我之前的架构经验给各位献个丑吧。
保留中心化的方案适用于业务紧密度较高的大型项目，比方说对司的SASS管理系统，或是有明显场景化分的C端项目（售前、售中、售后）。基本上大部分司级项目都可以用它来规整。
去中心化这种方案可以尝试在集团分散型项目中，比方说多个子公司的业务现在要做整合，需要各个业务线你中有我，我中有你，但是各个子公司用到的技术栈又各不相同。这个时候可以将自己一部分能力分享出去。
各位客爷，您勒觉着呢~
尾记
其实聊了这么久大家也会觉得我较真儿吧，用哪个不是用，哪个不都能把业务拆开嘛。没毛病，但我觉得做技术的人多多少少要有点较真儿的劲头吧，不然怎么让人觉得你这个人可靠呢~
说起这个我想起来四年前在某滴，考公司讲师的时候，当着CTO的面大聊自己不擅长的运维知识，结果直接让CTO怼下来，说我不严谨，现在想想人大哥说的也没毛病，不是什么人都能随随便便上台给大家讲东西的，所以我后来写博客的时候都要准备起码一个月，毕竟各位客爷可不是外行，没那么好糊弄的。
最后再聊聊当下吧，自从进了新公司，压力是一点没小，本来要戒的烟也没戒成。但是好在学会与自己和解，没那么大精神内耗，能睡得着觉了。大家晚安~
网友评论