前言
微服务的概念在后端开发比较成熟，借助微服务，可以更好的结偶多个单独的服务，提高彼此的性能跟稳定性。随着这两年前端的发展，微前端的概念也在前端中如火如荼的发展起来，但是我们为什么要去使用微前端呢
微服务是面向服务架构（SOA）的一种变体，把应用程序设计成一系列松耦合的细粒度服务，并通过轻量级的通信协议组织起来 具体地，将应用构建成一组小型服务。这些服务都能够独立部署、独立扩展，每个服务都具有稳固的模块边界，甚至允许使用不同的编程语言来编写不同服务，也可以由不同的团队来管理
为什么要使用微前端
微前端的优势：
- 独立技术栈：主框架不限制接入应用的技术栈，每个应用的技术栈选型可以配合业务团队选择
- 独立开发、独立部署：子应用仓库独立，前后端可独立开发，部署完成后主框架同步更新子应用
- 独立运行：每个子应用之间状态隔离，单独子应用失败不会影响到其他项目
- 数据共享：子应用可以共享主应用数据，亦可共享兄弟应用数据
上面的优势看完之后，OMG，还等什么，赶紧上啊
但现实中项目在架构上需要考虑的不仅仅是优势，更要考虑劣势。
微前端的劣势：
- 技术团队有没有能力对新架构兜底
- 独立模块应用独立部署
- 多技术栈的接入
- 解决多应用之间的样式隔离与通用、数据隔离与通信
- 多团队开发是否保持正常协作
- 业务是否高度集中、庞大到需要拆分独立业务
- 没有耦合的业务或者过小的业务，走微服务反而是一种负担
- 团队是否存在多个技术栈，并且不能够统一
- 没有统一的技术栈，项目基础样式，架构都会存在差异
- 项目管理交接会存在难度
- 整体研发成本反而增加
大部分的中小型公司，在没有很强的技术追求的情况下，其实并没有迫切的需求去引入微前端进来，造成额外的负担
毕竟没有实际业务支撑的架构就是一纸空文，没法落地推广下去
所以你到底该不该将微前端引入到你的项目中呢？
什么时候需要引入微前端
- 项目技术栈过于老旧,相关技能的开发人员少,功能扩展吃力,重构成本高,维护成本高。
通过微服务拆分将项目拆分掉，渐进式重构、重写、迭代后期功能
- 项目过于庞大，开发，部署效率底下，且出现问题，造成全局崩盘，不好维护
- 项目组存在不同技术栈，但是需要接入同一套主系统中
微前端的实现
微服务简单点来说就是将一个大综合的 Bundle 拆成多个子 Bundles，再通过父级容器加载各个子 Bundle，达到想要的拆包效果
Bundle 集成
构建时集成
- 将子应用单独发布 npm 包，以依赖包的形式，引入到主工程
- 采用 git submodule 的形式，引入主工程
构建时集成最大的问题是会在发布阶段造成耦合，每一个子版本的修改，都会导致整个工程需要重新编译构建，从能效上考虑，不是首推选项。
运行时集成
iframe 引用
优势：iframe 天生自带样式、数据隔离
劣势：原生的隔离性，意味着很难把应用的各个部分联系到一起，路由控制、历史栈管理、深度链接（deep-linking）、响应式布局等都变得异常复杂，因而限制了 iframe 方案的灵活性
老壶新酒，还是很好用的，在超级复杂的且上线时间极短的情况下，直接冲鸭，别犹豫
路由 + js bundle
- 我司使用的是 Single—Spa + SystemJS 构建的微服务，详情请看我们的微前端是如何炼成的。
- umijs + qiankun 生态圈不错的，掘金里面也有很多博文介绍，react 技术栈的可以考虑下
Web Components
每个子应用封装成自定义 HTML 元素（而不是前端路由方案中的渲染函数），以获得Shadow DOM带来的样式隔离等好处
写在最后
本文只是对于微服务在实际项目中的运用做了一些简单的探讨，文中所带观念也是自身在实际使用中的一些感悟与体会，欢迎留言探讨
最后给自己的 devops 系列加个推荐
后端模块
- DevOps - Gitlab Api使用（已完成，点击跳转）
- DevOps - 搭建 DevOps 基础平台 基础平台搭建上篇 | 基础平台搭建中篇 | 基础平台搭建下篇
- DevOps - Gitlab CI 流水线构建
- DevOps - Jenkins 流水线构建
- DevOps - Docker 使用
- DevOps - 发布任务流程设计
- DevOps - 代码审查卡点
- DevOps - Node 服务质量监控
前端模块
- DevOps - H5 基础脚手架 极速构建项目
- DevOps - React 项目开发
