随着云时代拉开帷幕，前端迎来机遇和挑战。在2016年，微前端的概念被提出，前后端架构形成了微前端+微服务的模式。微前端是云时代的前端架构体系，它不止是一个框架或者组件。阿里云智能安全前端团队负责人克军将从前端架构的演变、微前端的价值、微前端与云生态的关系、以及微前端的工作原理等几大方面为大家详细介绍云前端新物种-微前端体系。
嘉宾： 克军，阿里云智能安全前端团队负责人。长期专注于前端体系的探索，目前带领团队探索云上安全能力的交互创新。
本次分享将主要围绕以下五个方面展开：
一、前端架构背景介绍
二、微前端价值
三、微前端与云生态
四、微前端工作原理
五、总结
一、前端架构背景介绍
1.前端架构体系
云原生应用的三个特征包括容器化、动态管理和面向微服务。其中缺少对前端应用的特征描述，而本文将介绍的微前端正是代表了这个特征。前端架构需要建立一个可以满足业务当前及未来的前端技术体系，其中包含了软件库、框架、开发流程、技术栈设计、以及管理工具的建设。前端体系的建设是一个可持续的事情。在目前的云时代，微前端是目前的前端架构体系的方向。
2.架构的演变
在很久以前，前端和后端加在一起构成MVC架构，前端只是后端渲染的模版。在2010年，提出前后端分离的概念，服务端BFF作为数据的网段。到2014年，微服务概念被提出，后端的架构开始转型，面向微服务，而前端架构自2010年到目前依然没有变化。随着云时代拉开帷幕，前端或许会迎来机遇和挑战。在2016年，微前端的概念被提出，到目前完整的前后端架构是微前端+微服务。微前端和微服务的拆分是按照业务域进行拆分，每个业务域持续化的组织架构，每一个team维护单独的业务域。每一个业务域可独立开发、独立发布、可以被集成到环境当中、不限技术栈、被拆开的业务域可以自由组合。如果可以做到这些，基本上符合云时代分布式开发前后端保持一致的理念。
二、微前端体系价值
当然，大家对于新事物需要保持不吹捧的态度。在构建微前端体系过程中，需要克服微前端可能带来的问题。那么微前端与iFrame、WebComponents、NPM包、BigPepe、插件有什么区别？
1. 微前端与Widget/业务组件的区别
首先，微前端是一个架构体系，用于实现大型Web应用。Widget组件是以库、外联npm包等方式实现复用。微前端带来的是生产方式的不同，给开发方式带来了本质的变化，而Widget组件是生产工具，目的是提高复用。此外，微前端通过隔离机制实现技术栈无关，而Widget组件没有考虑这个问题，还是需要人工解决依赖和冲突问题。微前端可以单独构建、单独发布、热升级，这是微前端最大的优点。如页面中的某一个区域无需构建整个大应用，只需构建局部，这与日程业务中的场景非常契合，往往只是某个子域需要不断的迭代。而传统的Widget组件方法中，每次改动一点都需要整体发布，不够灵活。同时，微前端体制化治理性非常强，与云应用中动态化管理相似，本质上是对微服务的编排和调度机制。任何分布式特点的系统中，体制化治理都非常重要。因为当业务被拆成多个碎片化的部分后，管理的难度大大提高，体制化治理环节正是用于解决管理难度的问题。此外，微前端采用路由映射，消息机制符合主从关系，而Widget则相互之间并不有关系。微前端体系还衍生了微应用的概念，即属于整个产品的子集，变化较快，整个应用是若干个微应用的组合。Widget组件具备“外挂”属性，变化小，抽象出了整个应用的通用功能。
从2019年7月份到12月，阿里云智能安全团队代码变化如下图，代码增长的幅度达10万行。很明显，随着代码行的增加，其可维护性呈下降趋势。架构的思路是分层、分治和抽象，而微前端正是借助了分治的思路。
2. 微前端的工程价值
微前端的优点：微前端的优点包括独立开发、独立部署。对于大型的单页应用，采用微前端架构方式可无限扩展，其复杂度不会很明显的增长。此外，微前端不限技术栈，借助隔离机制保证技术栈的隔离性。第四点，可快速整合业务，如toB的产品需要符合客户的定制化需求，每个客户的业务场景都互不相同，此时需要产品具备更灵活的特点符合客户的业务定制需求。最后，微前端可以多人协作。
微前端的缺点：当然，微前端的缺点也很明显。首先，微前端会导致体验折损，微前端每一步都是异步加载，中间会出现不流畅的问题。此外，当一个单体应用被拆成若干个，其维护成本也相应增加，如如何管理多个版本，如何复用公共组件等，导致管理版本变得复杂，依赖关系也极其复杂。还有，如果应用拆分的粒度过小，对于工程师的开发体验也会不太友好，如果工程师负责的需求跨多个业务域，此时他/她需要与多个团队合作，沟通成本大大增加。
3. 微前端的业务价值
如果微前端只具备工程价值，如提高效率，则对团队内部没有多少帮助。因此，微前端还需具备三个业务价值。首先是产品“原子化”，可以根据客户的使用场景，可自由的编排组合，即扩展性、组合性和局部迭代的特点。其次是解决能力输出“最后一公里”的价值，云时代的平台与传统的平台不同，云平台更注重赋能，即能力的输出。最后，在能力输出过程中，需要将能力变得组件化，就是微前端中微应用的概念，降低用户使用的难度。
三、微前端与云生态
云平台提供基础的设施和算力，云平台可以以OpenAPI的方式被消费，此时要求企业具备研发能力较强的团队。在未来，云平台还需要提供编排工具，提供更简单组合的使用方式。再进一步，通过微应用的方式，使得企业的使用成本降低。
Idea1:云时代需要一个企业级的开发套件，包含了OpenAPI、编排工具、UI组件库以及微应用。
Idea2:在2014年，已经出现了微应用市场的概念，但当时还没有很流行。随着云时代的演进，开放的微应用市场应该是目前较为适合的方向。阿里巴巴内部很多团队已经开始探索这个方向，如single-spa是最早是微前端框架，MicroX是阿里巴巴云智能安全团队的微前端框架。
四、微前端基本工作原理
1. 微前端体系构成
微前端不是一个工具或者框架，而是一套架构体系。微前端有三部分构成，首先是基础设施，no Framework特点。其次是配置中心，用于管理版本、发布策略、以及动态构建。微前端中的若干个微应用需要通过观察工具充当运维职能，可观察工具具备可见性和可控性。如下图，微前端包括配置中心、观察工具、微应用市场、微应用容器。但这远远不够，还需要配套设施即本地开发工作台，因为微前端是在传统的工程化体系之上发展而来。最下层是数据网关的对接口。
2. 微前端工作原理
微前端的结构是主从结构，主应用中通过微应用容器组件将微应用异步加载进来。其次本地开发工作台具备测试、接口编排、构建、发布等等能力。之后在微前端配置中心做统一的版本管理、发布策略的制定。
3. 微前端10大问题
微服务中有10要素的概念，那么微前端大体上也有10个主要的问题需要得到重视。
具体而言，微应用的加载和运行机制如下图，首先是配置好应用信息，其次是依赖环境的运行时配置“安装”过程。拿到应用对象后，开始沙盒部分的操作，初始化、渲染。然后进行监控和映射路由。其中沙盒部分的能力提升是阿里云智能团队目前的难点。如果有较好的沙盒工具，也希望可以集成进来。
微应用容器需要不断提高几个方面的能力，如安全性、隔离性、回弹性、可见性和通讯能力。其中，安全能力可以分级处理，对于一/二级的可信平台，安全级别要求相应降低。对于不可信的第三方应用或者ISV开发的应用需要制定安全等级较高的方案。而在目前的安全方案中，iFrame方案是相对最安全的。再在此基础上，做静态检查，以及安全的DSL。隔离样式可以用ShadowDOM，但隔离JavaScript和DOM的侵入性还需要自己实现。回弹性指的是当加载失败时内部需要有FallBack的机制，在容错上上报错误信息。可见性指买点监控，对每个子应用做性能和健康度调试，通过Inspector在浏览器中查看出现问题的应用。
目前，阿里云智能团队的微前端框架使用路由管理的方式，在主应用中配置路由，映射子应用。
消费机制中微应用与微应用之间不允许用通讯的方式。而且微应用注册，主应用下发，将触发的事件下发下来，再订阅。
4. 微前端的望楼系统
微前端的望楼系统是一个可观察性工具。微前端的望楼系统除了监控系统健康度指标、告警和阀值等，还需要观察系统运行状态和可控性，如观察工具、跟踪、调试等。可观察性工具包括配置、代码质量、观察、数据服务、度量等等功能。
在未来，前端不只是开发，而是充当开发运维一体化的角色。当一个微应用发布后，如果出错，需要具备运维的能力。运维系统的设计原则中包括可控性、可观察、分析性和自动化。任何具备运维能力的系统都需要遵循这个设计原则，不断的完善系统。
5.微前端配置中心方案
微前端的配置中心需要具备可灰度、可回滚的中心化管理的能力。下图是阿里云智能团队微前端框架的配置台界面，右侧是每个子应用的子应用的信息。
每个子应用包含基本信息、异常监控情况、代码的健康状态、代码可维护性、代码复杂度变化、版本控制、发布的策略、依赖的资源、以及演示部分。通过视频演示的方式看到子应用的使用方法。
五、总结
微前端是云时代的前端架构体系，不止是一个框架或者组件。微前端的一个使命是构建体系，其中包括基础设施、全链路机制、以及每个环节核心能力的定位。微前端的治理包括配置中心的治理，和运维能力的治理。希望在未来，能够对微前端的涉及的一些概念，如微应用、公共依赖、微应用容器、引导（Bootstrap）、配置中心、微前端治理等等概念构建标准。
