作为前台开发人员，这些年来你一直在开发单体应用，即便你已经知道这是一个不好的做法。 您将代码划分为组件，使用?require?或者?import?并将package.json中定义的npm包或者已安装的子git仓库增加到项目中，但最终构建了一个整体。 是时候改变它了。
假如有想学习编程的初学者，可来我们的前台直播授课群的哦：571671034里面免费送整套系统的前台教程！
为什么你的代码是一个单体？
除了已经实现了微前台的应用之外，所有前台应用本质上都是单一的应用。 起因是假如您正在使用 React 库进行开发，并且假如您有两个团队，则两个团队都应该使用相同的React 库，并且两个团队应该在部署时保持同步，并且在代码合并期间始终会发生冲突。 它们没有完全分离，很可能它们维护着相同的仓库并具备相同的构建系统。 单体应用的退出被标志为微服务的出现。 但是它适用于后台！:scream:
什么是微服务？
对于微服务，一般而言最简单的解释是，它是一种开发技术，允许开发人员为平台的不同部分进行独立部署，而不会损害其余部分。 独立部署的能力允许他们构建孤立或者松散耦合的服务。 为了使这个体系结构更稳固，有少量规则要遵循，可以总结如下：每个服务应该只有一个任务，它应该很小。 所以负责这项服务的团队应该很小。 关于团队和项目的规模，?James Lewis 和 Martin Fowler?在互联网上做出的最酷解释之一如下：
在我们与微服务从业者的对话中，我们看到了一系列服务规模。 报道的最大规模遵循亚马逊关于Two Pizza Team的概念（即整个团队可以由两个比萨饼供给），意味着不超过十几个人。 在规模较小的规模上，我们已经看到了一个由六人组成的团队支持六项服务的设置。
我画了一个简单的草图，为整体和微服务提供了直观的解释：
从上图可以了解，微服务中的每个服务都是一个独立的应用，除了UI。 UI依然是一体的！ 当一个团队解决所有服务并且公司正在扩展时，前台团队将开始苦苦挣扎并且无法跟上它，这是这种架构的瓶颈。
除了瓶颈之外，这种架构也会导致少量组织问题。 假设公司正在发展并将采用需要?跨职能?小团队的敏捷开发方法。 在这个常见的例子中，产品所有者自然会开始将故事定义为前台和后台任务，而?跨职能?团队将永远不会成为真正的?跨职能?部门。 这将是一个浅薄的泡沫，看起来像一个敏捷的团队，但它将在内部分开。 关于管理这种团队的更多信息将是一项非常重要的工作。 在每个计划中，假如有足够的前台任务或者者sprint中有足够的后台任务，则会有一个问题。 为理解决这里形容的所有问题和许多其余问题，几年前出现了?微前台?的想法并且开始迅速普及。
处理微服务中的瓶颈问题：Micro Frontends:tada:
处理方案实际上非常显著，采用了多年来为后台服务工作的相同准则：将前台整体划分为小的UI片段。 但UI与服务并不十分类似，它是最终客户与产品之间的接口，应该是一致且无缝的。 更重要的是，在单页面应用时代，整个应用在用户端的浏览器上运行。 它们不再是简单的HTML文件，相反，它们是复杂的软件，达到了非常复杂的水平。 现在我觉得微型前台的定义是必要的：
Micro Frontends背后的想法是将网站或者Web应用视为独立团队拥有的功能组合。 每个团队都有一个独特的业务或者任务领域，做他们关注和专注的事情。团队是跨职能的，从数据库到客户界面开发端到端的功能。（micro-frontends.org）
根据我迄今为止的经验，对于许多公司来说，直接采用上面提出的架构真的很难。 许多其余人都有巨大的遗留负担，这使他们无法迁移到新的架构。 出于这个起因，更柔软的中间处理方案更加灵活，易于采用和安全迁移至关重要。 在更详细地概述了体系结构后，我将尝试提供少量体系结构的洞察，该体系结构确认了上述提议并允许更灵活的方式。 在深入理解细节之前，我需要建立少量术语。
整体结构和少量术语
让我们假设我们通过业务功能垂直划分整体应用结构。 我们最终会得到几个较小的应用，它们与单体应用具备相同的结构。 但是假如我们在所有这些小型单体应用之上增加一个特殊应用，客户将与这个新应用进行通信，它将把每个小应用的旧单体UI组合成一个。 这个新图层可以命名为?拼接图层?，由于它从每个微服务中获取生成的UI部件，并为最终客户组合成一个?无缝?UI，这将是微前台的最直接实现
为了更好地了解，我将每个小型单体应用称为?微应用?，由于它们都是独立的应用，而不仅仅是微服务，它们都有UI部件，每个都代表端到端的业务功能。
众所周知，今天的前台生态系统功能多样，而且非常复杂。 因而，当实现真正的产品时，这种直接的处理方案还不够。
要处理的问题
尽管这篇文章只是一个想法，但我开始使用Reddit探讨这个想法。 感谢社区和他们的回复，我可以列出少量需要处理的问题，我将尝试逐一形容。
当我们拥有一个完全独立的独立?微应用?时，如何创立无缝且一致的UI体验？
好吧，这个问题没有灵丹妙药的答案，但其中一个想法是创立一个共享的UI库，它也是一个独立的微应用。 通过这种方式，所有其余?微应用?将依赖于共享的UI库微应用。 在这种情况下，我们刚刚创立了一个共享依赖项，我们就杀死了独立?微应用?的想法。
另一个想法是在根级共享CSS自己设置变量（CSS custom variables）。 此处理方案的优势在于应用之间的全局可配置主题。
或者者我们可以简单地在应用团队之间共享少量SASS变量和混合。 这种方法的缺点是UI元素的重复实现，并且应该对所有?微应用?始终检查和验证相似元素的设计的完整性。
我们如何确保一个团队不会覆盖另一个团队编写的CSS？
一种处理方案是通过CSS选择器名称进行CSS定义，这些名称由微应用名称精心选择。 通过将该范围任务放在?拼接层?上将减少开发开销，但会添加?拼接层?的责任。
另一种处理方案可以是强制每个微应用成为自己设置Web组件（custom web component）。 这个处理方案的优点是浏览器完成了范围设计，但需要付出代价：使用shadow DOM进行服务器端渲染几乎是不可能的。 此外，自己设置元素没有100％的浏览器支持，特别是IE。
我们应该如何在微应用之间共享全局信息？
这个问题指出了关于这个主题的最关注的问题之一，但处理方案非常简单：HTML 5具备相当强大的功能，大多数前台开发人员都不知道。 例如，?自己设置事件（custom events）?就是其中之一，它是在微应用中共享信息的处理方案。
或者者，任何共享的pub-sub实现或者T39可观察的实现都可以实现。 假如我们想要一个更复杂的全局状态解决程序，我们可以实现共享的微型Redux，通过这种方式我们可以实现更多的相应式架构。
假如所有微应用都是独立应用，我们如何进行用户端路由？
这个问题取决于设计的每个实现, 所有主要的现代框架都通过使用浏览器历史状态在用户端提供强大的路由机制, 问题在于哪个应用负责路由以及何时。
我目前的实用方法是创立一个共享用户端路由器，它只负责顶级路由，其他路由器属于相应的微应用。 假设我们有?/content/:id?路由定义。 共享路由器将解析?/content?，已解析的路由将传递到ContentMicroApp。 ContentMicroApp是一个独立的服务器，它将仅使用?/:id?进行调用。
我们必需是服务器端渲染，但是有可能使用微前台吗？
服务器端呈现是一个辣手的问题。 假如你正在考虑iframes缝合?微应用?而后不记得服务器端渲染。 同样，拼接任务的Web组件也不比iframe强大。 但是，假如每个?微应用?能够在服务器端呈现其内容，那么?拼接层?将仅负责连接服务器端的HTML片段。
与传统环境集成至关重要！ 但是怎样样？
为了整合遗留系统，我想形容我自己的策略，我称之为“?渐进式入侵?”。
首先，我们必需实现拼接层，它应该具备透明代理商的功能。 而后我们可以通过公告一个通配符路径将遗留系统定义为?微应用?：?LegacyMicroApp?。 因而，所有流量都将到达拼接层，并将透明地代理商到旧系统，由于我们还没有任何其余微应用。
下一步将是我们的?第一次逐渐入侵?：我们将从LegacyMicroApp中删除主要导航并用依赖项替换它。 这种依赖关系将是一个使用闪亮的新技术实现的?微应用?：?NavigationMicroApp?。
现在，拼接层将每个路径解析为?Legacy Micro App?，它将依赖关系解析为?Navigation MicroApp?，并通过连接这两个来为它们提供服务。
而后通过主导航遵循相同的模式来为引导下一步。
而后我们将继续从Legacy MicroApp中获取逐渐重复以上操作，直到没有任何遗漏。
如何编排用户端，这样我们每次都不需要重新加载页面？
拼接层处理了服务器端的问题，但没有处理用户端问题。 在用户端，在将已粘贴的片段作为无缝HTML加载后，我们不需要每次在URL更改时加载所有部分。 因而，我们必需有少量异步加载片段的机制。 但问题是，这些片段可能有少量依赖关系，这些依赖关系需要在用户端处理。 这意味着微前台处理方案应提供加载?微应用?的机制，以及依赖注入的少量机制。
根据上述问题和可能的处理方案，我可以总结以下主题下的所有内容：
用户端
编排
路由
隔离微应用
应用之间通信
微应用UI之间的一致性
服务端
服务端渲染
路由
依赖管理
灵活、强大而简单的架构
所以，这篇文章还是很值得期待的！ 微前台架构的基本要素和要求终于显现！
在这些要求和关注的指导下，我开始开发一种名为microfe的处理方案。 :sunglasses:在这里，我将通过笼统的方式强调其主要组件来形容该项目的架构目标。
它很容易从用户端开始，它有三个独立的主干结构：?AppsManager，?Loader，?Router?和一个额外的?MicroAppStore。
AppsManager
AppsManager 是用户端微应用编排的核心。 AppsManager的主要功能是创立依赖关系树。 当处理了微应用的所有依赖关系时，它会实例化微应用。
Loader
用户端微应用编排的另一个重要部分是Loader。 加载器的责任是从服务器端获取未解析的微应用。
Router
为理解决用户端路由问题，我将 Router 引入了?microfe?。 与常见的用户端路由器不同，?microf?的功能有限，它不解析页面而是微应用。 假设我们有一个URL?/content/detail/13?和一个ContentMicroApp。 在这种情况下，?microfe?将URL解析为?/content/?，它将调用ContentMicroApp?/detail/13?URL部分。
MicroAppStore
为理解决微应用到微应用用户端的通信，我将MicroAppStore引入了?microfe?。 它具备与Redux库相似的功能，区别在于：它对异步数据结构更改和reducer 公告更灵活。
服务器端部分在实现上可能略微复杂少量，但结构更简单。 它只包含两个主要部分?StitchingServer?和许多?MicroAppServer。
MicroAppServer
MicroAppServer?的最小功能可以概括为?init?和?serve。
尽管?MicroAppServer?首先启动它应该做的是使用?微应用公告?调用?SticthingServer?注册端点，该公告定义了?MicroAppServer?的微应用?依赖关系，?类型?和?URL架构。?我认为没有必要提及服务功能，由于没有什么特别之处。
StitchingServer
StitchingServer?为?MicroAppServers?提供注册端点。 当?MicroAppServer?将自己注册到?StichingServer?时，?StichingServer?会记录?MicroAppServer?的公告。
稍后，?StitchingServer?使用公告从请求的URL解析?MicroAppServers。
解析M?icroAppServer?及其所有依赖项后，CSS，JS和HTML中的所有相对路径都将以相关的?MicroAppServer?公共URL为前缀。 另外一步是为CSS选择器增加一个唯一的?MicroAppServer?标识符，以防止用户端的微应用之间发生冲突。
而后?StitchingServer?的主要职责就是：从所有收集的部分组成并返回一个无缝的HTML页面。
其余实现一览
甚至在2016年被称为微前台之前，许多大公司都试图通过BigPipe 来处理Facebook等相似问题。 如今这个想法正在取得验证。 不同规模的公司对该主题感兴趣并投入时间和金钱。 例如，Zalando开源了其名为Project Mosaic的处理方案。 我可以说，微型和?Project Mosaic.遵循相似的方法，但有少量重要的区别。 尽管microfe采用完全分散的路由定义来加强每个微应用的独立性，但Project Mosaic更喜欢每条路径的集中路由定义和布局定义。 通过这种方式，Project Mosaic可以实现轻松的A/B测试和动态布局生成。
对于该主题还有少量其余方法，例如使用iframe作为拼接层，这显然不是在服务器端而是在用户端。 这是一个非常简单的处理方案，不需要太多的服务器结构和DevOps参加。 这项工作只能由前台团队完成，因而可以减轻公司的组织负担，同时降低成本。
已经有一个框架叫做?single-spa?。?该项目依赖于每个应用的命名商定来解析和加载微应用。 容易掌握想法并遵循模式。 因而，在您自己的本地环境中尝试该想法可能是一个很好的初步详情。 但是项目的缺点是你必需以特定的方式构建每个微应用，以便他们可以很好地使用框架。
最后的想法
我相信微前台话题会更频繁地探讨。 假如该主题能够引起越来越多公司的关注，它将成为大型团队的事实发展方式。 在不久的将来，任何前台开发人员都可以在这个架构上掌握少量见地和经验，这真的很有用。
假如有想学习编程的初学者，可来我们的前台直播授课群的哦：571671034里面免费送整套系统的前台教程！
