这是我参与 8 月更文挑战的第 7 天，活动详情查看： 8月更文挑战
前言
什么是前端微服务？我们知道，近些年，前端发展呈百家争鸣式发展，框架层出不穷，版本更是迭代不穷，难免会出现前端项目技术栈不统一、所用框架版本不统一。比如，有的项目中，还采用了angelar1.0、vue1.0等。而这些项目若没有新的功能加入，线上稳定运行，对其重构成本会很高。
技术方案
路由转发
路由分发式微前端，即通过路由将不同的业务分发到不同的、独立前端应用上。通常使用像nginx实现反向代理，也可以通过前端路由来实现。
就当前而言，通过路由分发式的微前端架构应该是采用最多、最易采用的 “微前端” 方案。但是这种方式看上去更像是多个前端应用的聚合，即我们只是将这些不同的前端应用拼凑到一起，使他们看起来像是一个完整的整体。但是它们并不是，每次用户从 A 应用到 B 应用的时候，往往需要刷新一下页面。通常可通过nginx配置反向代理，来进行路由分发，从而实现前端微服务
它的成本是很低劣的，当然它也有个致命的缺点，那就是应用之间的跳转会有短暂的白屏，毕竟是需要重新加载网页资源，并不能像SPA页面那样流畅。
iframe
这是一种古老的浏览器技术了，它很粗暴但很好用，可以在页面的任意位置再开启一个浏览器沙箱，完全是与外界隔离的。
Web Components
Web Components 组件可以拥有自己独立的 Scripts 和 Styles，以及对应的用于单独部署组件的域名。然而它并没有想象中的那么美好，要直接使用纯 Web Components 来构建前端应用的难度有：
- 重写现有的前端应用。是的，现在我们需要完成使用 Web Components 来完成整个系统的功能。
- 上下游生态系统不完善。缺乏相应的一些第三方控件支持，这也是为什么 jQuery 相当流行的原因。
- 系统架构复杂。当应用被拆分为一个又一个的组件时，组件间的通讯就成了一个特别大的麻烦。
- 浏览器兼容问题
将应用微件化
组合式集成，即通过软件工程的方式在构建前、构建时、构建后等步骤中，对应用进行一步的拆分，并重新组合。
从这种定义上来看，它可能算不上并不是一种微前端——它可以满足了微前端的三个要素，即：独立运行、独立开发、独立部署。但是，配合上前端框架的组件 Lazyload 功能——即在需要的时候，才加载对应的业务组件或应用，它看上去就是一个微前端应用。
常见的方式有：
- 独立构建组件和应用，生成 chunk 文件，构建后再归类生成的 chunk 文件。（这种方式更类似于微服务，但是成本更高）
- 开发时独立开发组件或应用，集成时合并组件和应用，最后生成单体的应用。
- 在运行时，加载应用的 Runtime，随后加载对应的应用代码和模板。
如果涉及了项目历史比较悠久，那么重构成本会比较高。
小结
微前端要解决的问题其实很明确，因为有历史包袱，前端的更新迭代速度又非常快。一个项目一段时间不维护，可能组件库都升级大版本了。微前端的确是一种可以"偷懒"的方法，新项目用新技术，老项目用老技术，互不影响。
最后打波小广告，美团校招社招内推，不限部门，不限岗位，不限投递数量，海量hc，快来快来～
