微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增加，从一个普通应用演变成一个巨石应用(Frontend Monolith)，随之而来的应用不可维护问题。这类问题在企业级 Web 应用中尤为常见。今天，我们就来聊聊拥抱云时代的前端开发架构：微前端。
微前端的价值
目前提供的很多商业化产品和服务，本质上是对外提供「能力」，普惠中小企业。目前，能力输出主要是通过 OpenAPI，用以集成到企业自己的业务场景中，这里主要解决的还是企业底层的能力问题——无需雇佣算法工程师，就可以拥有语音、图像识别等能力。安全也是一样，不需要找安全专家，普通的工程师就可以通过控制台高效地处理各种安全事件。
但是，随着云技术不断的下沉，与产业结合的越来越紧密，OpenAPI 唯有把粒度做得越来越细，才能满足各种各样的业务场景，但同时企业侧的学习成本和开发复杂度自然就上去了。控制台做为管（理）控（制）这些能力的工具，目前也只能算是「标品」，必须为了满足不同体量、不同业务特点的需求，灵活地组合和部署，就像是用户自己开发的一样。
综上所述，微前端的价值有 3 点：
1、技术栈无关 主框架不限制接入应用的技术栈，子应用具备完全自主权。
2、独立开发、独立部署 子应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新。
3、独立运行时 每个子应用之间状态隔离，运行时状态不共享。
微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用(Frontend Monolith)后，随之而来的应用不可维护的问题，这类问题在企业级 Web 应用中尤其常见。
微前端的问题域
简单地说，搞微前端目的就是要将产品原子化（跟原子化的 OpenAPI 一个道理），再根据客户业务场景组合。每个功能模块能单独迭代，自由集成当然好，但维护成本怎么控制。怎么调试、公共组件版本控制、众多同窗微应用之间怎么“和谐相处”等等。微前端并非只是解决在页面上异步加载一个模块就完事了，更多的是将改造引发的一系列问题需要通过体系化的方案解决，否则就变成反生产力工具。
首先必须明确微前端不是框架、不是工具/库，而是一套架构体系，它包括若干库、工具、中心化治理平台以及相关配套设施。
微前端包括 3 部分：
微前端的基础设施。这是目前讨论得最多的，一个微应用如何通过一个组件基座加载进来、脚手架工具、怎么单独构建和部署、怎么联调。
微前端配置中心：标准化的配置文件格式，支持灰度、回滚、红蓝、A/B 等发布策略。
微前端的可观察性工具：对于任何分布式特点的架构，线上/线下治理都很重要。
微前端具体要解决好的 10 个问题：
1、微应用的注册、异步加载和生命周期管理；
2、微应用之间、主从之间的消息机制；
3、微应用之间的安全隔离措施；
4、微应用的框架无关、版本无关；
5、微应用之间、主从之间的公共依赖的库、业务逻辑(utils)以及版本怎么管理；
6、微应用独立调试、和主应用联调的方式，快速定位报错（发射问题）；
7、微应用的发布流程；
8、微应用打包优化问题；
9、微应用专有云场景的出包方案；
10、渐进式升级：用微应用方案平滑重构老项目。
相信大家能够通过微前端三大组成部分和要解决的 10 个问题，能够有一个大概的理解。
针对中后台的应用解决方案
中后台应用由于其应用生命周期长(动辄 3+ 年)等特点，最后演变成一个巨石应用的概率往往高于其他类型的 web 应用。而从技术实现角度，微前端架构解决方案大概分为两类场景：
单实例：即同一时刻，只有一个子应用被展示，子应用具备一个完整的应用生命周期。通常基于 url 的变化来做子应用的切换。
多实例：同一时刻可展示多个子应用。通常使用 Web Components 方案来做子应用封装，子应用更像是一个业务组件而不是应用。
行业现状
传统的云控制台应用，几乎都会面临业务快速发展之后，单体应用进化成巨石应用的问题。为了解决产品研发之间各种耦合的问题，大部分企业也都会有自己的解决方案。针对国内外几个著名的云产品控制台，做过这样一个技术调研：
MPA 方案的优点在于 部署简单、各应用之间硬隔离，天生具备技术栈无关、独立开发、独立部署的特性。缺点则也很明显，应用之间切换会造成浏览器重刷，由于产品域名之间相互跳转，流程体验上会存在断点。
SPA 则天生具备体验上的优势，应用直接无刷新切换，能极大的保证多产品之间流程操作串联时的流程性。缺点则在于各应用技术栈之间是强耦合的。
那我们有没有可能将 MPA 和 SPA 两者的优势结合起来，构建出一个相对完善的微前端架构方案呢？
jsconf china 大会上，ucloud 的同学分享了他们的基于 angularjs 的方案（单页应用“联邦制”实践），里面提到的 "联邦制" 概念很贴切，可以认为是早期的基于耦合技术栈的微前端架构实践。
微前端架构实践中的问题
可以发现，微前端架构的优势，正是 MPA 与 SPA 架构优势的合集。即保证应用具备独立开发权的同时，又有将它们整合到一起保证产品完整的流程体验的能力。
这样一套模式下，应用的架构就会变成：
Stitching layer 作为主框架的核心成员，充当调度者的角色，由它来决定在不同的条件下激活不同的子应用。因此主框架的定位则仅仅是：导航路由 + 资源加载框架。
云时代的前端开发模式
前端开发从 PC 时代到移动时代，从刀耕火种的原始运维到云计算时代，回顾起来，我们会发现——开发模式跟时代背景真是密不可分。前端奋斗 20 年才把页面写好，而现在又变成「切页面」了，只是此「切」非彼「切」。云时代的开发模式注定是「碎片化」的，开发是面向模块的，而页面只是一种组合场景，一种运行时容器。
我想，未来的产品开发主要时间是在「编排」——编排服务、编排逻辑、编排组件、编排访问策略、编排流程。到了云时代，一家企业只要招几个前端工程师就可以了，兼顾开发和运维、资产全部上云，运维任务通过控制台就能完成。开发借助 Serverless 和编排工具就能实现无服务端。在未来，无论是前端工程师还是全栈工程师，都将不复存在，应该叫端到端(F2E -> E2E)工程师了。
我目前是在职前端开发，如果你现在也想学习前端开发技术， 在入门学习前端的过程当中有遇见任何关于学习方法，学习路线，学习效率等方面的问题， 你都可以申请加入我的前端学习交流裙：前面：603 中间：985 最后：993。里面聚集了一些正在自学前端的初学者， 裙文件里面也有我做前端技术这段时间整理的一些前端学习手册，前端面试题， 前端开发工具，PDF文档书籍教程，需要的话都可以自行来获取下载。
网友评论