过去十多年，提前开发大幅提前。近期我们所开发的网页应用程序，必须能够快速加载、在不同的装置上运行，还得迅速响应用户的交互。可想而知，提前开发需要投入很多时间构思、并极其细靡遗地处理网站细节。

当专案规模还很小、只需跟少数几个开发人员合作时，要打造一个好的网页应用程序就非常困难了。但如果你的公司拥有一个大型网站，而且想要持续改进或增加新功能，单单一个团队马上就会应付不过来了。这就是微架构架构能够发挥优势的地方：在微架构架构下，网页应用程序被拆分成多个块，使多个团队进行独立作业。

微前端不是一个实际技术，而是一种新的组织及架构方法，自然也不是指某种特定的框架。传统开发方式时常采用水平架构，例如整个专案有一个前端团队，搭配一个以上的头部团队或者UI设计团队。如果专案不大，每个任务都有专人负责，整个案子没几个人，这样兼容起来会很 以上，但如果专案规模较大，复杂度增加，任何系统规模的更动可能会出其不意地影响到其他部分，加上团队人员队伍，内部的讨论日益增加麻烦，动不动就跨团队、跨部门沟通。

微前端架构互连的另一种做法：将应用程序垂直拆解，每个区块定位一个专责团队负责，一条龙地包含从数据库连接到用户介面的开发。不同团队的前端模块会在客户端的浏览器内部集成，构成最终的页面。

常见的微架构架构

微前端的一个好处是，每个团队都可以自由采用符合其需求的技术，前提是所有团队都得在高层架构上达成一致。比如说，我们的目标是开发静态网页、只通过超链接整合，还是要打造一个高度动态、整合较稀疏的单页面应用程序？在这种时候，你应该找来所有团队一起做决定。下图列出6种不同的架构。

我们将由上往下逐一介绍。

使用超链接串起页面

这是最简单的架构。各个团队的页面都是完全利用服务器渲染的html文件，点击网站的超链接就会重新加载新内容。无论你是在同一个团队内部切换网页，还是跨团队进行浏览页面，均属于硬导览。

架构的优点在于它简单：蒸发中央体验这种基础设施或消耗的方案代码，侦错非常直觉，而新的开发人员接手时也能马上进入状况。但从用户来说，超链接有经过改进的空间。

服务器路由

这个方法和超链接很相似，不同之处在于所有请求都会经过共享的网路服务器或反向代理服务器。这个服务器会在前面各个团队的应用程序中摆位，并由一组路由决定来规范传入的请求该交由哪一组团队处理。路由规则会跟团队相关的网址通常作为参考。

链接的SPA

为了提升用户体验，视觉用户的输入更快地做出响应，团队可以考虑放弃服务器端生成的静态网页，改而将自己的页面实际制作在客户端渲染的单页应用程序（SPA ）。这么一来，只要点击的链接就是导向该团队的页面，都会变成速度快的软导览，但跨团队的页面切换依然是硬导览。

技术上来说，如果一个团队内部采用 SPA 架构，可以忽略不计算是实作细节。只要外部链接到该团队的特定页面互作用，团队都可以自行决定如何改变自家的内部架构。但等我们之后面谈更进阶的架构与更合适的整合技巧时，互相链接的页面跟互相链接的SPA有何差异，就会变成一大关键了。

链接的通用 SPA

所有团队也可以考虑采用通用渲染──用户第一次请求的 HTML 会在服务器端产生，使得第一个页面加载体验相当快。应用程序在这之后就会表现得像 SPA，需要逐步更新用户介面。

从团队的角度来看，这个设定起来比较复杂，需要额外的开发技巧。但就架构角度来看，这个做法就和其他『相互链接』的架构无异。团队间的契约仍然是一组共享的 URL 格式，跨团队转页时又重新加载页面。但如果这个架构实作得宜，页面重新加载的程度应该会超过『链接的 SPA』架构，因为今晚重载页面时得在浏览器支持许多 JavaScript，可以让内容在用户眼前呈现。本书第 8 章专题讨论了通用渲染及其优点、挑战。

统一SPA

统一SPA是指由多个SPA集结成一个单页面应用程序，本书第7章介绍了这个概念。参与专案的所有都团队必须以SPA形式来开发应用程序，而最上层有一个父程序（又称为app shell）来系统整这些SPA。app shell通常不渲染任何用户界面，其职责是监听浏览器网址列是否有变更，然后视需要将控制权从现有的SPA转给另一个SPA。这个架构底层，所有转页都会是软导览的形式，用户界面会变得更加灵敏、更加真正的应用程序。然而，app shell 不属于任何团队的核心程序代码，其存在会带来不低的连接及复杂度。

统一通用SPA

如果你采用统一SPA模式，再给它加上通用渲染的话，就解锁了所谓的『统一通用SPA』。在这个模式下，每组团队开发的SPA都具备通用渲染能力，而核心应用模式（ app shell）同样如此，并能同时在服务器端与客户端兼容。该架构集优点在于一，但非常有满足，复杂度也是最高的。

复杂度比较

你选择的架构和集成程度都会影响你的专案复杂度。复杂度可以反映在不同的方面：

●让专案启动所需的初步基础设施。

●需要维护的可动组件数量，比如服务或工件（专案资产文件）。

●关联数量：那些变更需要动用超过一个团队？

●开发人员技能等级：新的开发人员需要掌握那些概念？

● 错侦：有臭虫发生时，能否很容易找到负责的团队？

下图将各个架构简单的复杂度分群。由左到右，从非常到非常复杂做排序，共分为四个分组。这当然只是大方向指引，挑选架构的关键，依靠团队的经验以及使用案例。根据经验原则，应该始终选择您的能力范围内、简单的架构。采用一个系统的单页面应用程序，没有生硬的页面切换确实很好，但需要额外的努力进行这样的开发，以及后续维护作业，是否符合成效？

也可采用非同质架构

通常我们习惯让所有团队都使用相同的架构，但你其实也可以混用不同的东西，来打造一套非同质的架构。对于开发登陆页面的团队来说，加载速度要快，所以用超链接串起页面可能已经足够了。但如果要打造无缝的浏览体验，你则需要打造一个统一的SPA，负责把产品清单的团队、以及管理产品页的团队整合起来。这些架构可以并行兼容，有的团队而已利用超链接，其他团队则共享一个app shell来实作统一SPA。这样，你就只是在有必要的地方增加复杂度。

但使用非同质架构也有一些缺点：

●新团队没有直接采用某种架构。各团队必须事先就各自的使用案例分析和讨论（但有时不一定是缺点）。
● 整合不同团队的页面分块，可能会变得更加困难。团队必须把他们的微支架个体包装成目标页面可嵌入的形式。

链接: https://www.fly63.com/article/detial/12615