前后算是有2年左右的极限拉扯，设计，落地经验,极限拉扯的是业务应用,设计是为了避免拉扯，落地经验是，我本可以轻轻松松的满足公司、业务面临的问题，结果实践了一圈，要么纯前端解决方案，要么纯后端方案，“管杀不管埋，管生不管养”，人悬在半空，另外一只脚落地要等到猴年马月。
容我正个三观先
技术的最终目的是服务于客户，只有客户满意，公司能赚到钱，业务能发展，能生存下去，我们才能生存，“皮之不存，毛将焉附”的道理都懂，近几年的论调和画风常常是, ”给多少钱做多少事儿，大不了再换一家“ ,即便近几年996,Icu的矛盾空前绝后，压力和难处也各不相同，但换种设想，主体在我，技术在我，我们只是在变强的道路上，顺手解决了生计问题，希望在我,这不是阿Q精神,对自己充满希望,人才会有希望。
直接上干货
QA应答机环节
Q：要解决什么问题？
A： 关于微前端、npm私域包、和业务偏离的矛盾问题
Q:我立论的依据是什么？
A: 一个业务，一个公司，运营好几年，看着平地楼起，仍然然并卵,我不是谈成功，我在谈失败。
Q:有具体实践和场景么？
A:传统项目的缝合、老项目的改造、npm私有包、微前端、联邦模块、分离部署的实践，之所以现在说，是之前的实践和探索，最终我选择了分离部署的实践，也将重点来讲这部分
Q:矛盾是什么？
A: 前后端没有分离之前，基本会整体权衡,处理块放那边更省力更合理即放在那边，是合作关系，现在是”两看相轻，互相甩锅“,属于抢占关系，随着端的变多，交互性的要求变强，职能变的更明确，前端认为自己用也可以整服务端，服务端就增删改查，现在时代变了”LZ不可能像开始那样被你吆五喝六了“，很多服务端还是秉持着前端就是绑我的数据，还敢跟我争话语权，这也就是很多沟通成本增加的主因素，因为技术面的局限，自以为是的否定别人，但本质上，如果独立做一些应用就发现，离了对方，啥也不是，码界爱情故事，相爱相杀
Q:结果导向？
A:合作的可能没有了，那我眼不见心不烦，自己搞自己的，不依托你总行了吧，像之前微前端的提法，感觉高大上，可始终存在争议，解决不了我的业务问题，只能说，大萝卜埋小坑，连带挖地带松土,为了解决iframe的一些问题，组件引用，前端多技术栈差异化引用等问题，附带带来了一系列的解决方案，然而，这是小公司无法承受之重，服务端老哥劳心劳力搭架子，但这两年技术变革之快，往往因为UI太丑，没了竞争力.
从公司，业务的诉求开始
♂1.项目的运作方式以满足客户需求为准则，特殊需求较多，更多考量以项目出发、技术选型实现思路种种方面存在差异化；
♂2.因项目需求的频繁变更及dead-line的要求，很多功能没法按照组件化的方式方法去约束、没法有效的剥离业务组件，同时也没有专门的内部团队去构建沉淀，造成的直接现状就是重复开发，共用效率没法得到有效控制、同一个业务百家争鸣，不同的外在相同的内里；
♂3.研发以及项目异地化，项目间的技术沟通协以及内部积累仅仅局限团队内部，往往因写法、规范、习惯的不同以及研发人员的变更交替导致出现一套系统多种风格，一个公司几种技术体系，基本无法协作的现状；
♂4.没有内部的技术沉淀，内部的推陈出新良性进化往往需要很大的研发时间成本耗费，造成的现状是业务线与技术线不在同一起跑线，却要保持步调一致，通过压缩技术实现周期对推陈出现的时间成本进行控制，往往会造成恶性结果；
以上基本上是传统小公司一直无法跨越阶层的现状，利润和成本完全卡死，一个业务做几十遍也无法提精炼髓，公司层级啥也没有，
老板想要的业务组合是这样的，拼上就行：
但是结果往往是，动一根线，我可能就挂了
老板想要的对外输出是这样的：
实际的输出是：
先整个流行私域包开胃
我们得搞基础建设，定标准，做架构，啦啦啦一堆，老板大臂一挥，我们要组件化，开整
- 私域包搞一波
- 基建搞一波
- 陡然发现，这个变更的体量，是要逼着所有人升级换代啊，以谁提出，谁完成的论调，这工作量有点儿大
- 当你费心费力搞完了基建，发现依然无法约束大家的行为习惯，好吧，支持力、约束力、执行力及员工普遍能力满足不了，平台层限制了你的发挥，换个试试
再试个微前端qiankun缝合
额，看着很高端的样子，也是缝合不同系统，不同技术架，支持老系统
微前端架构具备以下几个核心价值：
技术栈无关 主框架不限制接入应用的技术栈，微应用具备完全自主权
独立开发、独立部署 微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
增量升级
在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略
独立运行时 每个微应用之间状态隔离，运行时状态不共享
微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用后，随之而来的应用不可维护的问题。这类问题在企业级 Web 应用中尤其常见
看着挺迷茫的，不过好像能解决传统iframe嵌套带来的发布，组件交互问题，啥也不说了，我先表演个胸口碎大石
带来的配置性灾难，新的样式污染，不断的填坑，问题好像看别人反馈了一堆，带来的震撼效果，没感受到
我连数据都没统一呢，还不如我的渐进式改造来的实在，又是不合适的场景
我懵了，容我再强化矛盾
- 缝合保证的基本准则，以业务划分为轴，谁的业务归谁，即【页面+服务】是一体化的。
- 业务是可以被引用，集成，组件化的，简单理解就是，我想让iframe已有功能的基础上组件化控制，继承改造的，以及服务的可替换行。
- 缝合项目可以工程化，不会因为忘记调整某一个链接而环境混乱，因程序发布导致的问题。
- 我的所有业务都可以组合，（配置化菜单，整体风格控制，总控开关）
- 最重要的是，“4两拨千金”，毕竟做设计和架构，本质就是提供服务，让每个人都轻松，都能获利，才是事情能做成的本质
容我再实施联邦模块
看到很多人认为webpack5联邦模块的这个能力就是微前端，对此不置可否
以下是之前验证的内容，是要轻量很多，满足一些要求【组件+服务】归属，样式，继承等机制，但问题也很大，如果你具体升级过一些框架和webpack的版本，那就一定体会过那种痛苦，更不要说，你的设计要求其他应用去做升级，所以引用者必须升级webpack版本这关，很难具有普适性， （具体相关升级过程之前写过，会在文末补充目录，感兴趣的小伙伴可以去看）
换个思路，是不是可以单端升级，把影响范围降到最低，以cdn的方式进行引用,本质webpack的引用端是否可以以cdn的方式放在服务端提供出来结合npm私域包的方式，现在的问题是怎么解决工程化的配置及批量发布的问题
解决工程化发布总控问题
lerna 发布及环境的总体配置
"scripts": {
"build:prod": " lerna exec -- cross-env VUE_APP_BASE_Portal='' VUE_APP_BASE_Gaway='' npm run build:prod -- --dest=../dist/^%LERNA_PACKAGE_NAME^% ",
"build:stage": " lerna exec -- cross-env VUE_APP_BASE_Portal='' VUE_APP_BASE_Gaway='' npm run build:stage -- --dest=../dist/^%LERNA_PACKAGE_NAME^%",
"bootstrap": "lerna bootstrap ",
"rm": "lerna exec -- rimraf node_modules"
},
达成批量发布，引用全局配置的目的
编译组件，主应用编译，2选一，一起发或者只发布主应用
"scripts": {
"build:prod": "npm run lib&vue-cli-service build ",
"build:stage": "npm run lib&vue-cli-service build
"lib": "webpack --config build/webpack.lib.js ",
},
子项目动态引入环境切换,public/index.html
<script src="<%=process.env.VUE_APP_BASE_Portal%>/lib/sso.js"></script>
</script>
解决组件总线的问题
图画的不是太明了，勉强看
1.以引用链的形式进行交互，解耦部署
2.保证组件输出的集中，统一，其他项目组件以引用部署形式，提供给总控组件进行管理，提供继承，引用，扩展的标准
3.目前关于联邦模块动态调用放在一端进行调用还未验证，但原理基本上由双端约定变为单端，主要对核心Init,get输出container进行扩展，问题不大
关于当前实践
以上的问题，是我这段尝试的最终比较符合我心意的组合，如果你有多个系统，需要统一融合成菜单，样式，应用，共享机制为一套体系的需要，最后一套，我认为是我目前实践中，耗费最小，且最容易达成目标的方案，时间和篇幅关系，这次就聊到这，算是另外一个思路的探索吧
往期回顾
- 多平台博客工具推荐
- 全栈终结者-把nuxt扔进垃圾桶、Blazor与seo的化学反应
- ol与Vue室内定位模式设计
- 二十余年如一梦，此身虽在堪惊。闲登小阁看新晴。古今多少事，渔唱起三更
- Tauri操作实战（1）-环境准备
- 代码生成代码
- webpack5 针对vue vue-cli-service 升级指南（三）
- webpack5 针对vue vue-cli-service 升级指南（二）
- webpack5 针对vue vue-cli-service 升级指南（一）
感谢
如果最后看到这里，那感谢各位掘友耗费时间看我在这里絮叨，加油，继续坚持