承接上一篇《微前端架构研究与方案探讨》，本篇我们将继续探索和思考前端整体系统架构如何设计、基础开发框架需要具备哪些核心能力、如何保障大规模微应用的开发效率和质量以及后期运维治理等。
一、架构体系化建设思路
如果确定了在项目中引入微前端架构，那么接下来需要思考的是，如何规范有序地推进微前端应用架构建设。在思考解决方案之前，可以先看看下面这张图：
图1传统应用微前端系统概要设计示意
上图概要设计描述了企业级微前端架构系统的建设目标，即系统整体上被划分为了主应用和多个子应用的组合，它们基于统一的UI设计风格（设计系统）及工具链进行开发和构建，分别由不同的职能团队负责交付。其实，它不仅仅阐述了目标要求，同时还指引出了微前端架构实现的关键影响因素，包括有技术实现、主应用、子应用、团队协作、工程化及资源共享。
明确了目标和关键因素，接下来重点要考虑的是如何应用。微前端是借鉴了微服务的设计思想，目的都是通过分治的手段解决单体应用复杂且臃肿的问题，那么是否可以从后端微服务架构的成功实施当中获取启发？
表1微前端和微服务核心功能对比分析
从上面的表格可以看出，除了应对的上下文环境会有些差异外，它们要解决的主要问题都是相似的。如果进一步分析的话，那么会发现核心功能涉及到了研发、运维、治理等方方面面的内容，同时，也让我们认识到它是一种体系化解决问题的思路。下面就顺着这个思路、结合着前端上下文环境梳理出针对微前端系统架构的体系化设计想法。
图微前端系统架构体系化设计思路
二、核心能力实现思考与实践
上面提到的大多数规划过程对大家来说可能并不陌生，因为它们本身都来自于软件领域长期的经验总结和沉淀。不可否认，要成功的实现微前端体系架构会面临不小的挑战。但任何复杂事物的解决思路都是相通的，首先要做的是任务分解，其次要对每个任务逐个分析解决，明确各部分的职责范围和核心能力要求。
1、微应用定义与拆分
在系统设计和拆分方面，强烈推荐一种新的架构设计方法，它就是领域驱动设计（DDD）。目前很多采用了微服务化架构的团队已经开始使用它了，原因在于应用拆分粒度的把控出现问题。前期觉得拆的越小越好，到了项目后期由于拆分过渡导致系统复杂度过高，上线和运维碰到了极大的困难。
在应用拆分治理上，微前端和微服务思路应该是相通的，都是为了解决大型复杂系统的可扩展性、可维护性等难题。对于单独业务域的应用而言，微前端和微服务同时对一个应用的前端和后端负责，然后一起为业务域整体的交付目标负责。
所以，非常建议微前端能向微服务一样采用DDD方法论来设计和拆分应用，一方面能充分享受它带来的优势，另一方面可以吸取经验教训，避免再次出现同类型的问题出现。当然，还是要以具体的需求和实践为主。
、整体技术架构（企业级应用）
目前来说，通过现代化前端技术构建企业级应用已经是非常成熟的方案了，经过长期大量实践经验总结，形成了一套基础的技术架构体系。
图3前端系统基础技术框架
前面提到过微前端系统整体是由主应用及若干个子应用构成的，那么在运行时我们以某种方式将它们组合在一起，之后要让系统运转起来完成预期的业务流程。比如，主应用作为系统的统一入口，它要负责将对应的请求路由指向对应的子应用、共享身份认证、授权信息、提供跨应用之间的视图交互通信机制。实现这些需求，就需要依赖微前端技术方案来解决。
在微前端技术框架为系统的主应用中，子应用提供运行时生命周期管理，保障系统整体运行的稳定可靠。
图4微前端系统运行时技术框架
3、主应用（通用能力支撑）
前面简单介绍过微前端主应用存在的目的，它提供了子应用业务逻辑实现的通用支撑功能。之前在单体前端系统的时候，我们更愿意将它定义为后台管理系统及桌面框架，没有将这部分通用能力独立出来。
如果按照DDD设计方法规划的话，那么主应用可以划分为通用域，承担包括身份认证、权限管理、工作台等这样的职责。现在定义为主应用，一方面是技术方案的原因需要强调主次之分，另一方面它是系统的入口。下面是主应用最基本需要承担的一些能力：
图5微前端系统企业级应用通用能力支撑
需要注意的是，在微前端时代，每个微型前端应用可以是大型应用系统被集成的一部分，也可以是完成自包含业务逻辑的独立应用。
4、应用工程规划（代码管理）
组织项目结构与如何管理拆分的代码库同样是必不可少的，代码库管理通常指存储库分为单个代码库（mono-repo）和多个代码库（multi-repo）两种风格组织代码的形式。
传统开发即是multi-repo的，即一个module一个仓库，比如公司内部提炼的常用工具、常用组件都是分开存放，开发的时候install在同一个项目里。而mono-repo则是一个仓库包含整个项目的所有，分成多个package目录分开管理，统一处理相互依赖。表现形式见下图：
图6多个代码库（MultipleRepos）
引用出处：GitHubboltpkg/bolt——超大型前端项目管理
图7单个代码库（MonoRepos）
引用出处：GitHubboltpkg/bolt——超大型前端项目管理
这两种方案都有各自的优缺点，本文不做详述。在具体应用到微前端架构系统的源代码管理时，更倾向于将两种风格进行结合，如下说明：
图8微前端系统源代码管理
5、资源共享（公共组件）
当系统规模大到一定程度，都会考虑进行资源抽象提取，对于是否采用微前端方案关系并不大。重要区别在于两方面的影响，一方面是微前端下的公共组件的使用方式，另一方面是公共资源规范化的管理。
使用方式代表的情况是跨技术组件之间的调用问题，以及组件是否可以没有依赖关系，完全独立且一直迭代下去。公共资源规范化的管理则指的是希望做成共享平台化支撑，建立公有、私有共享机制、按照公司、子公司，或者某一个业务领域团队范围来共享。当然，这个并不是一朝一夕就能做好的。
6、本地开发工作台
不同于传统的单体单页应用项目，微前端系统是分布式团队协作同步建设的，传统的工程化管理和自动化流水线作业是不能适应的。工程化系统需要进行功能升级，对子应用单独设计构建工具、工具链需要具备单独构建、单独发布、热升级等必备的工程能力。
传统项目管理工具通常是命令行工具，包括构建、发布、测试，现在的开发流程需要升级为开发工作台的方式，实现一体化作业。将工程化工具链、代码托管Git、DevopsCI/CD分散的能力进行聚合，综合提升研发能力。
通过开发工作台，将日常的前端研发链路上的操作都聚合起来，从组件开发、模板开发到应用开发，从包更新到发布。
图9微前端系统开发工作台
7、中心化治理（配置中心）
一个大型项目的前端单体单页应用被拆分成了很多个微应用，我们希望通过Web界面以中心化的方式将项目管理起来，可以很直观的看到一个项目包含了哪些微应用、微应用的版本管理、依赖关系、发布策略以及系统参数等配置信息。
图10微前端系统应用集中注册管理（图片内数据皆为编纂仅供示例）图11微前端系统子应用配置
8、运维能力（全局可观测性）
微前端吸收了很多微服务优秀的设计思想，但同时也将面临系统规模化拆分应用带来的复杂性问题。应用之间会变得相对独立且分散，发布上线后编排在一起运行在浏览器上。为了保障整体运行的稳定可靠，需要有一套可观察性机制来了解各应用之间的运行状况，包括异常信息、操作日志、性能指标、安全状况等方面的信息提供参考。通过这些告警信息，开发人员可以及时定位到是哪个应用出现的问题，并快速响应故障修复，从而增加系统的可控性和可靠性。
三、体系化建设实现阶段总结
针对上述体系化建设思路和具体核心能力实现的描述，我们可以将系统建设总体概括为“架构基础”、“研发支撑”、“运维治理”几个阶段进行。
1、架构基础
良好的用户体验是企业级应用系统最基础的交付目标，为了确保为用户提供一致的外观和感觉，需要建立通用的设计体系，在确定了系统整体UI主题风格之后，通过设计语义和规范约束提升交付质量。
微前端系统的目标，是将物理分割的应用在运行时集成在一起，同时，为了适应复杂的业务流程，需要编排不同的视图保证系统整体交互上很自然。
针对上面的目标需求，我们需要进行整体架构设计并提供相应的技术解决方案：
设计系统：确保系统整体风格的一致性；
技术架构：明确基础技术架构、微前端框架的能力范围边界及各自的职责；
主应用：提供企业级应用系统通用支撑能力；
服务集成：从软件整体架构上考虑微前端和微服务（端到端）集成的模式。
、研发支撑
思考如何定义微前端，即是如何合理的拆分微型应用。面对微应用急剧膨胀和复杂性的增加，常规的工程化方案已经不能完全适应，需要设计专门针对微前端应用的自动化流水线构建工具，并合理运用CI/CD持续不断改善团队交付应用速度，提升工程效率，改善开发人员的体验和项目质量。
拆分解耦：根据团队职能和业务领域做好子应用的定义和拆分；
代码管理：应用工程规划设计及源代码管理方法；
资源共享：公共组件资源的抽象和复用，努力实现平台化发展；
基础设施：代码审查、编译构建、CI/CD流程自动化、版本控制、私服仓库；
开发工作台：项目脚手架、模板工程、集成测试、开发环境，数据Mock。
3、运维治理
以集中化管理方式，对微应用弹性需求管控和运行指标上的监控。
中心化配置管理：应用注册、依赖管理、发布策略、参数配置、部署策略、版本管理；
运维监控：建立分散应用的可观察性，包括性能指标、堆栈异常信息、函数调用链路，应用依赖关系。
在实施过程中，架构基础阶段完成之后，后期则面临大规模的业务开发，这个阶段，研发配套、运维治理阶段发挥的作用就是保障子应用的高质量迭代交付。下图简要示意了整体流程：
图1微前端子应用建设过程
综上所述，可以看出微前端具体应用到实践，并不完全特指一种技术或框架，而是基于最初的理论基础，不断演进吸收各个技术领域的优势，形成一种针对微前端应用的架构体系。
结语
无论是Web标准还是技术社区及业界知名大厂，都在积极的拥抱微前端架构。我们的Web应用程序从基本的HTML元素、到UI组件、模板界面，最终进化到原子化的以业务域驱动的微应用程序。它们自由扩展、组合、迭代，满足日渐复杂的业务需求。要想拥有高质量的微前端架构系统，体系化的建设过程是必须要经历的，个人认为它带来了一次巨大的机遇和挑战。对于前端从业者来讲，它是一次技术体系化的梳理和总结，覆盖的知识面非常广泛，对于开拓视野非常有帮助，同时实施的难度也不小；对于企业而言，最直观的好处是可以有效提升大型团队组织的协作效率，应用的无限扩展降低了大型系统的建设难度，与后端微服务化共享基础设施提升了交付效率。
1.