本篇要搞懂的 4 件事：后端拆成微服务后单体前端为什么会变成灾难、微前端到底是什么（把"微服务"那套搬到前端）、微前端 + 微服务怎么组成"业务单元"以及它们怎么集成、保险全险种销售这个完整案例怎么落地。
⚠️ 这一讲偏"前端架构思想"，但它面向的不是写 CSS 的活，而是怎么把前端按业务边界拆开、再拼回去。哪怕你不写前端，这套"拆了再拼、各管一段"的思路对你设计任何系统都通用。
承接前文：08 讲结尾留了个钩子——企业级跨中台编排要靠 BFF（服务于前端的后端），那是站在后端视角说"怎么把多个微服务的能力组合好喂给前端"。17 讲把视角彻底翻到前端这一侧：后端都拆成微服务了、API 满天飞，前端却还是一整坨单体，谁来收拾？答案就是把微服务的拆分思想原样搬到前端——微前端（Micro Frontend）。一句话串起来：08 讲解决"后端怎么解耦 + 跨域怎么编排"，17 讲解决"前端怎么解耦 + 怎么和这些微服务拼起来"。
08：后端微服务化 + BFF 做跨中台编排（站在后端看前端）
↓ 视角翻转
17：前端也别再单体了 → 微前端，按领域/微服务边界拆前端
微前端 + 微服务 = 业务单元（一个中台团队端到端管一块）
前端主页面把一个个业务单元"拼图式"加载进来
↓ 总目标
前端融合（用户感觉是一个 App）+ 中台解耦（后端各拆各的）
单体前端的困境：前端人员变成了"维修电工"
后端拆成微服务后，前端团队要同时对接一大堆中台微服务团队，面对成百上千个 API。这时候前端人员就像维修电工：一堆电线（API）摆在面前，得正确地连接、拼装、不接错——而且某个微服务一改 API，所有受影响的前端都得被通知、被改。沟通成本和出错概率都爆炸。
🪞 辅助理解（维修电工）：把每个微服务的 API 想象成墙里拉出来的一根电线。后端拆得越细，墙上的电线越多。单体前端就是让一个电工去把这上千根线全接对、还得记住哪根线换了规格要重接——迟早接错、迟早接不过来。
为什么单体前端撑不住，作者给了几层原因：
| 压力来源 | 具体表现 |
|---|---|
| 后端拆了、前端没拆 | 前端单体越来越臃肿、越来越难维护 |
| 移动化 + 统一运营 | 用户不想装一堆 App，企业要把所有能力塞进一个 App |
| 渠道多样（传统企业尤其） | 门店端、电商/移动端、第三方 API 集成……渠道差异让前端更复杂 |
| 海量 API 集成 | 一个前端团队对接 N 个中台团队、集成上千 API，沟通+技术要求极高 |
💡 注意作者的措辞：传统企业比互联网企业渠道更杂（内部门店、外部客户、第三方都要管），所以前端复杂度反而更高——这也是为什么"微前端"在传统中台转型里特别有价值。
从单体前端到微前端：把微服务那套搬过来
解法很直接：借鉴微服务的设计思想，把它扩展到前端。
微前端的定义（作者原话拆开看）：
- 按领域模型和微服务边界把前端页面拆开；
- 拆成多个可独立部署、完全自治、松耦合的页面组合；
- 每个组合只负责一个特定业务单元的 UI 和功能——这就是一个微前端。
微前端和微服务追求的是同一件事：把单体按规则拆开，重组为能"独立开发、独立测试、独立部署、独立运维"的小块，以适应业务快变和多团队并行。
| 微服务 | 微前端 | |
|---|---|---|
| 拆什么 | 后端单体应用 | 前端单体页面 |
| 拆的依据 | 领域模型 / 限界上下文 | 领域模型 / 微服务边界 |
| 追求 | 独立开发/测试/部署/运维、松耦合 | 完全一样 |
| 额外好处 | 服务复用 | 页面复用 |
💡 微前端只包含该业务单元操作必需的页面要素，它只是"完整业务流程里的一块拼图"，不含页面导航这类全局的东西。导航、门户那一层归"前端主页面"管（后面会讲）。
业务单元：微前端 + 微服务打包成一个组件
这是本讲最关键的概念。把对应同一个领域模型的微前端和微服务绑在一起，组成一个业务单元——它能独立开发/测试/部署/运维，自包含地完成某块领域的业务功能。可以理解成"一个特定业务领域的、前后端都齐活的组件"。
看图抓什么：每个虚线框就是一个业务单元，框里上面是微前端（椭圆）、中间通过 API 连到下面的微服务（六边形，这正是 08 讲六边形架构的画法），微服务再连数据库。三种组合从左到右：
| 组合形态 | 长什么样 | 用在哪 |
|---|---|---|
| 1. 单一业务单元 | 1 个微前端 ↔ 1 个微服务 | 一个领域模型从前到后自包含 |
| 2. 组合业务单元 | 1 个微前端 ↔ 多个微服务 | 页面较复杂，要拼多个微服务的能力；⚠️ 别接太多，否则又退回单体前端 |
| 3. 通用共享业务单元 | 1 个微前端 ↔ 一/多个通用中台微服务 | 订单、支付这类公共能力，微前端以共享页面的形式被别的微前端复用 |
🪞 辅助理解（业务单元 = 带屏幕的乐高块）：一个业务单元就是一块自带显示屏的乐高积木——前端那面（屏幕）和后端那面（电路）已经在出厂前焊好了。你搭整个系统时不用关心积木内部怎么接线，只管把一块块拼到一起。这就是"自包含"。
💡 红线规则：所有业务单元都要自包含、边界清晰，业务单元之间避免功能交叉。一旦交叉，团队职责边界就乱了，独立开发/部署也就泡汤了——和 08 讲"别让领域逻辑跨层乱跑"是同一种洁癖。
微前端怎么集成：上接主页面，下接微服务
微前端夹在"前端主页面"和"微服务"中间，两头都要集成。
看图抓什么：左边是改造前——单体前端直接捅向微服务 A/B/C 的 API（就是"维修电工"那种乱接）。右边是改造后——上方蓝色是集成主页面（负责"微前端加载、页面路由、微前端注册、数据共享"），它通过动态加载把 A 业务微前端、BC 业务微前端、共享微前端挂进来；每个微前端再各自通过 API 连自己的微服务。注意 BC 业务微前端一个人连了微服务 B 和 C 两个——这正是上面说的"组合业务单元"。
两个集成方向分开看：
| 集成方向 | 怎么做 | 关键技术 |
|---|---|---|
| 微前端 ↔ 前端主页面 | 主页面用"微前端加载器"，把特定业务单元的页面动态加载进来，拼图式集成 | 页面路由、动态加载、微前端注册 |
| 微前端 ↔ 微服务 | 和传统前后端分离没区别：微服务发布到 API 网关，微前端调网关上的 API | API 网关（08 讲的老朋友） |
💡 流程上：微前端先自己和微服务集成好（业务单元内部闭环），再去前端主页面注册 + 配路由，之后主页面就能按需动态加载它了。两步是有先后的。
团队职责边界：前端管"拼"，中台管"块"
业务单元化最爽的一点是团队职责一刀切清楚，沟通成本直接降下来：
| 团队 | 负责什么 | 不用操心什么 |
|---|---|---|
| 前端项目团队 | 企业级主页面：整体风格、主流程编排、微前端的动态加载/注册/路由/数据共享 | 不用懂每个中台微服务的内部 API 细节 |
| 中台项目团队 | 一个业务单元端到端：从数据库 → 微服务 → 微前端页面，自己人完成前后端集成 | 不用管别的业务单元怎么实现 |
🪞 辅助理解（装修队 vs 全屋定制）：前端团队像装修总包，只负责把一个个做好的"成品房间"按户型图摆放、走廊打通、风格统一；中台团队像全屋定制厂商，每家厂商把自己那个房间（柜子+水电+灯）整间做好交付。总包不用懂柜子内部结构，厂商之间也互不打架——“熟悉的人干熟悉的事”，效率和质量都上来了。
💡 这一刀切下去，前端团队对"中台微服务技术"的敏感度降低了：后端团队可以更大胆地换技术、做架构演进，只要业务单元对外的接口和页面不变，前端无感。这是解耦带来的隐藏红利。
案例：保险全险种订单化销售
这个案例把前面所有概念串成一个完整系统，值得当模板记。
背景痛点：保险集团要在一个 App 里卖寿险、财险等全险种。不同险种领域模型差异大、页面要素不同。如果还用单体前端，会撞上三堵墙：
| 难点 | 说人话 |
|---|---|
| ① 前端开发设计复杂 | 一个页面适配全险种 → 要兼容所有产品差异，又乱又伤体验；每类产品做一套页面 → 工作量爆炸 |
| ② 前后端集成复杂 | 前端要摸清所有产品的 API、还要按主流程做服务路由，集成量大、易出错 |
| ③ 版本协同发布 | 某个中台微服务 API 一大改，所有关联应用得一起发版，频繁发版影响各产品正常运营 |
解法：借鉴电商订单模式，把保险做成"全险种订单化销售"——一个前端主页面把所有流程无缝串起来，后端是一堆业务单元，但用户始终感觉在同一个 App 里操作。
看图抓什么（从上往下三层）：
- 最上层 前端主页面：一条流程线——保险商品 → 选择商品 → 保单录入 → 报价核保 → 加购物车（可循环回选商品）→ 生成订单 → 订单支付 → 生成保单 → 保单管理。这就是用户看到的"一个 App"。
- 中间：一句话点题——“前端主页面根据业务流程和路由配置，动态加载微前端页面”。
- 最下层 两类中台：
- 核心中台（左）：车险投保、寿险投保、财产险投保，每个都是"出单微前端 + 投保微服务"的业务单元；
- 通用中台（右）：会员、订单、购物车、商品、支付，每个也都是"微前端 + 微服务"的业务单元。
四个设计要点对照图记：
| 要素 | 内容 |
|---|---|
| ① 微服务 | 核心中台（投保，实现核心出单逻辑）+ 通用中台（商品/订单/购物车/支付，共享逻辑） |
| ② 微前端 | 每个微服务配自己的微前端页面（如投保配"出单微前端"） |
| ③ 业务单元 | 微服务 + 微前端 = 业务单元，由一个中台团队端到端交付（如"投保微服务 + 出单微前端 = 投保业务单元"） |
| ④ 前端主页面 | 类似门户：管导航、放购物车这类常驻共享页、统一界面风格、按业务规则动态加载各业务单元的微前端 |
业务流程跑一遍（体会"动态加载"是怎么串流程的）：
1. 主页面 → 商品目录微前端，选保险产品
2. 主页面按产品，从配置里查出"出单微前端"路由 → 加载它 → 录单 → 投保微服务生成投保单
3. 加载购物车微前端 → 投保单加入购物车
4. 重复 1-3，凑多个投保单
5. 购物车里选多个投保单 → 加载订单微前端 → 生成订单
6. 加载支付微前端 → 完成支付
7. 投保微服务把订单里的投保单 → 生成保单
💡 全程后端在切换不同业务单元，但用户只在一个主页面里操作——这就是这一讲反复强调的"前端融合、中台解耦"。融合是给用户看的体验，解耦是给团队用的架构。
总结
后端微服务化之后，单体前端会变成"维修电工"式的灾难：对接 N 个中台、集成上千 API、谁改 API 都得全员协同发版。17 讲的答案是把微服务思想搬到前端——微前端：按领域模型/微服务边界拆前端，拆成可独立开发/测试/部署的页面块。
再把对应同一领域的微前端 + 微服务打包成"业务单元"（自包含的、带屏幕的乐高块），由一个中台团队端到端交付。业务单元有三种组合：单一、组合（一前端连多服务，别连太多）、通用共享。集成上两头各管一段：微前端 ↔ 微服务走 API 网关（和传统前后端分离一样）；微前端 ↔ 前端主页面靠主页面的加载器做注册+路由+动态加载。
团队边界因此一刀切清楚：前端团队管"拼"（主页面、主流程、动态加载），中台团队管"块"（业务单元端到端）。最终落到保险全险种案例：一个主页面把全流程串起来，后端一堆业务单元各司其职，用户感觉始终在一个 App——这就是"前端融合、中台解耦"。
一句话速记
后端拆了前端别再单体——按微服务边界拆成微前端，前端+后端打包成"自包含业务单元"，前端团队管主页面的"拼"、中台团队管业务单元的"块"，主页面动态加载拼成一个 App：前端融合、中台解耦。
思考题
试着站在前端工程落地的视角，重新审视微前端架构：
- 远程加载靠得住吗？ 前端主页面靠"路由配置 + 动态加载"把一个个微前端拉进来。如果某个远程包的地址挂了、CDN 超时，或者加载到的版本和主页面期望的不一致，会发生什么？你会怎么做加载失败时的降级（占位、重试、回退到上一个可用版本）和版本锁定（版本号管理、依赖共享、灰度发布）？
- 业务边界 = 运行时隔离吗？ 业务单元号称"代码、逻辑、物理边界都隔离"。但多个微前端跑在**同一个主页面（同一浏览器上下文）**里：一个微前端崩了会不会把整个页面带挂？全局变量、CSS 样式、第三方库版本会不会互相打架？业务上"边界清晰"和运行时真正隔离并不是一回事，你会用什么手段补这块（Shadow DOM 隔离样式、JS 沙箱、约定全局命名空间、错误边界兜底）？
- API 网关是咽喉也是瓶颈。 所有微前端最终都调 API 网关上的服务。如果你是设计者，会在网关这一层集中放哪些通用能力（鉴权、限流、路由、聚合），又有哪些不该只靠网关、必须下沉到每个业务单元自己做？
