前端微服务化(一)：初探
微前端产生的原因
一个团队负责的项目（不管前后端还是全栈），随着时间的推移，会极大的可能发生下面的变化。为了这些变化，各种繁琐的组合，开分支，打tag等造成后期的维护成本增加，代价随之越来越大。随着互联网的发展，一种将多个不同的服务集中在一个大平台上统一对外开放的概念逐渐为人熟知，越来越多与云相关或不相关的中后台管理系统或企业级信息系统曾经或开始采用了这种「统一平台」的形式。同时，前端领域保持着高速发展，早期的 jQuery+Backbone+Bootstrap 的 MVC 解决方案支撑起了业务相当长的一段时间；后来，Angular、Ember 等 MVVM 框架开始崭露头角，前后端分离和前端组件化的思想在此时达到了鼎盛期。而在国内，Vue 框架凭着其简洁易懂的 API 和出色的周边生态支持独领鳌头，越来越多的中小型企业和开发者们开始转向 Vue 阵营；与此同时，在设计上独树一帜的纯 View 层框架 React 开始兴起，其充满技术感的 Diff DOM 思想吸引了大批开发者，成为各大技术社区最火爆的话题，其周边生态也随之快速发展，成为了各大公司搭建技术栈时的首选框架。
目前的前端领域，单页面应用（
SPA）大行其道。而随着时间的推移以及应用功能的丰富，这些应用变得越来越庞大也越来越难以维护。于是“微前端”这一概念应运而生。
“
微前端”出自2016 年的ThoughtWorks技术雷达，指 将项目拆分成一个个可独立运行、独立开发、独立部署的前端微应用，这些微应用可以并行开发、共享组件 。
什么是微前端
微前端背后的理念是将一个网站或者Web App当成特性的组合体，每个特性都由一个独立的团队负责。每个团队都有擅长的特定业务领域或是它关心的任务。这里，一个团队是跨职能的，它可以端到端，从数据库到用户界面完整的开发它所负责的功能。然而，这个概念并不新鲜，过去它叫针对垂直系统的前端一体化或独立系统。不过微前端显然是一个更加友好并且不那么笨重的术语。
微前端是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用还可以独立运行、独立开发、独立部署。
什么要用微前端
任何一种技术或者概念都有其适用场景，微前端也不例外。 针对中小型的项目，使用微前端反而会将事情复杂化 ，因为微前端对项目的开发并不友好。
项目技术栈过于老旧,相关技能的开发人员少,功能扩展吃力,重构成本高,维护成本高.
项目过于庞大,代码编译慢,开发体差,需要一种更高维度的解耦方案.
单一技术栈无法满足你的业务需求
微服务化后端前后端对比
后端微服务化的优势复杂度可控:
1).体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。
2).独立部署: 由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。
3).技术选型灵活: 微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。
4).容错: 当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。
5).扩展: 单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。
前端微服务化后的优势
1)复杂度可控: 每一个UI业务模块由独立的前端团队开发,避免代码巨无霸,保持开发时的高速编译,保持较低的复杂度,便于维护与开发效率。
2)独立部署: 每一个模块可单独部署,颗粒度可小到单个组件的UI独立部署,不对其他模块有任何影响。
3)技术选型灵活: 也是最具吸引力的,在同一项目下可以使用如今市面上所有前端技术栈,也包括未来的前端技术栈。
4)容错: 单个模块发生错误,不影响全局。
5)扩展: 每一个服务可以独立横向扩展以满足业务伸缩性，与资源的不必要消耗；
前端微服务给我们带来什么
最小程度独立开发
细粒度开发，不论是一个大项目还是小项目，均可以拆分多个大小不一的小模块（app）
模块根据具体的业务场景，可进行打散和重新组合
模块与项目的关系可以是一对多（公用模块）或一对一 （单业务）
最小程度独立部署
一个单体的前端应用最大的问题是构建出来的前端资源文件（js,css)太大，若使用独立开发，则这些文件可以拆分成多个文件
可以按照不同的环境部署（如 CDN)
轻耦合
独立开发中，
SPA的应用开发中DOM即API
前后端数据彻底分离
数据与业务分离
技术无关
我们必须组合app模块，若技术无关，那app可能是
angular,react,vue等构成.
使用后端模板引擎插入 HTML（渐进式从后端进行加载
使用IFrame隔离运行时（PostMessage)
客户端JavaScript异步加载
WebComponents整合所有功能模块
Single-SPA/Micro Frontends/Mosaic/Mooa/single-spa-angular-cli【推荐】
数据交互使用CustomEvent交互
不同模块的数据使用共享事件总线
使用不同的服务器缓存（squid,varnish,nginx），整合不同的模块
提高开发效率，减少开发时间
微前端背后的核心理念
1.技术无关
每一个团队在选择和升级他们的技术栈时应该能够做到不需要和其他团队进行对接。Custom Elements 是一个隐藏实现细节的非常好的方法，同时能够对外提供一个统一接口。
2.隔离团队代码
即使所有的团队都使用同样的框架，也不要共享一个运行时。构建独立的应用，不要依赖于共享状态或全局变量。
3.建立各团队的前缀
当隔离已经不可能时要商定一个命名规范。对 CSS、Events、Local Storage 和 Cookie 建立命名空间来避免碰撞并声明所有权。
4.本地浏览器特性优先于自定义 API
采用浏览器事件进行数据沟通而不是构建一个全局的发布者-订阅者系统。如果你确实需要构建一个跨团队的 API，那就确保它越简单越好。
5.构建自适应网站
即使 JavaScript 执行失败或是根本没有执行，你的特性也应该是能够使用的。采用通用渲染或渐进式增强来提高可感知的性能。
面临的问题与挑战
我们如何实现在一个页面里渲染多种技术栈?针对于老系统，如何实现从 Backbone 技术栈到 React 技术栈或 Vue 技术栈的平滑
不同技术栈的独立模块之间如何通讯?
如何通过路由渲染到正确的模块?
在不同技术栈之间的路由该如何正确触发?
项目代码别切割之后,通过何种方式合并到一起?
我们的每一个模块项目如何打包?
前端微服务化后我们该如何编写我们的代码?
独立团队之间该如何协作?
怎样将不同业务子系统集中到一个大平台上，统一对外开放？
如何给不同用户赋予权限让其能够访问平台的特定业务模块同时禁止其访问无权限的业务模块？
如何快速接入新的子系统，并对子系统进行版本管理，保证功能同步？## 前端微服务化(一)：初探
微前端产生的原因
一个团队负责的项目（不管前后端还是全栈），随着时间的推移，会极大的可能发生下面的变化。为了这些变化，各种繁琐的组合，开分支，打tag等造成后期的维护成本增加，代价随之越来越大。随着互联网的发展，一种将多个不同的服务集中在一个大平台上统一对外开放的概念逐渐为人熟知，越来越多与云相关或不相关的中后台管理系统或企业级信息系统曾经或开始采用了这种「统一平台」的形式。同时，前端领域保持着高速发展，早期的 jQuery+Backbone+Bootstrap 的 MVC 解决方案支撑起了业务相当长的一段时间；后来，Angular、Ember 等 MVVM 框架开始崭露头角，前后端分离和前端组件化的思想在此时达到了鼎盛期。而在国内，Vue 框架凭着其简洁易懂的 API 和出色的周边生态支持独领鳌头，越来越多的中小型企业和开发者们开始转向 Vue 阵营；与此同时，在设计上独树一帜的纯 View 层框架 React 开始兴起，其充满技术感的 Diff DOM 思想吸引了大批开发者，成为各大技术社区最火爆的话题，其周边生态也随之快速发展，成为了各大公司搭建技术栈时的首选框架。
目前的前端领域，单页面应用（
SPA）大行其道。而随着时间的推移以及应用功能的丰富，这些应用变得越来越庞大也越来越难以维护。于是“微前端”这一概念应运而生。
“
微前端”出自2016 年的ThoughtWorks技术雷达，指 将项目拆分成一个个可独立运行、独立开发、独立部署的前端微应用，这些微应用可以并行开发、共享组件 。
什么是微前端
微前端是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用还可以独立运行、独立开发、独立部署。
什么要用微前端
任何一种技术或者概念都有其适用场景，微前端也不例外。 针对中小型的项目，使用微前端反而会将事情复杂化 ，因为微前端对项目的开发并不友好。
项目技术栈过于老旧,相关技能的开发人员少,功能扩展吃力,重构成本高,维护成本高.
项目过于庞大,代码编译慢,开发体差,需要一种更高维度的解耦方案.
单一技术栈无法满足你的业务需求
微服务化后端前后端对比
后端微服务化的优势复杂度可控:
1).体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。
2).独立部署: 由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。
3).技术选型灵活: 微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。
4).容错: 当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。
5).扩展: 单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。
前端微服务化后的优势
1)复杂度可控: 每一个UI业务模块由独立的前端团队开发,避免代码巨无霸,保持开发时的高速编译,保持较低的复杂度,便于维护与开发效率。
2)独立部署: 每一个模块可单独部署,颗粒度可小到单个组件的UI独立部署,不对其他模块有任何影响。
3)技术选型灵活: 也是最具吸引力的,在同一项目下可以使用如今市面上所有前端技术栈,也包括未来的前端技术栈。
4)容错: 单个模块发生错误,不影响全局。
5)扩展: 每一个服务可以独立横向扩展以满足业务伸缩性，与资源的不必要消耗；
前端微服务给我们带来什么
最小程度独立开发
细粒度开发，不论是一个大项目还是小项目，均可以拆分多个大小不一的小模块（app）
模块根据具体的业务场景，可进行打散和重新组合
模块与项目的关系可以是一对多（公用模块）或一对一 （单业务）
最小程度独立部署
一个单体的前端应用最大的问题是构建出来的前端资源文件（js,css)太大，若使用独立开发，则这些文件可以拆分成多个文件
可以按照不同的环境部署（如 CDN)
轻耦合
独立开发中，
SPA的应用开发中DOM即API
前后端数据彻底分离
数据与业务分离
技术无关
我们必须组合app模块，若技术无关，那app可能是
angular,react,vue等构成.
使用后端模板引擎插入 HTML（渐进式从后端进行加载
使用IFrame隔离运行时（PostMessage)
客户端JavaScript异步加载
WebComponents整合所有功能模块
Single-SPA/Micro Frontends/Mosaic/Mooa/single-spa-angular-cli【推荐】
数据交互使用CustomEvent交互
不同模块的数据使用共享事件总线
使用不同的服务器缓存（squid,varnish,nginx），整合不同的模块
提高开发效率，减少开发时间
面临的问题与挑战
我们如何实现在一个页面里渲染多种技术栈?针对于老系统，如何实现从 Backbone 技术栈到 React 技术栈或 Vue 技术栈的平滑
不同技术栈的独立模块之间如何通讯?
如何通过路由渲染到正确的模块?
在不同技术栈之间的路由该如何正确触发?
项目代码别切割之后,通过何种方式合并到一起?
我们的每一个模块项目如何打包?
前端微服务化后我们该如何编写我们的代码?
独立团队之间该如何协作?
怎样将不同业务子系统集中到一个大平台上，统一对外开放？
如何给不同用户赋予权限让其能够访问平台的特定业务模块同时禁止其访问无权限的业务模块？
如何快速接入新的子系统，并对子系统进行版本管理，保证功能同步？