（给前端大全加星标，提升前端技能）
译文：Vincnt.W/蛋壳公寓前端工程师
作为前端开发人员，这些年来你一直在开发单体应用，即使你已经知道这是一个不好的做法。您将代码划分为组件，使用rquir或import并将packag.json中定义的npm包或已安装的子git仓库添加到项目中，但最终构建了一个整体。是时候改变它了。
为什么你的代码是一个单体？除了已经实现了微前端的应用之外，所有前端应用本质上都是单一的应用。原因是如果您正在使用Ract库进行开发，并且如果您有两个团队，则两个团队都应该使用相同的Ract库，并且两个团队应该在部署时保持同步，并且在代码合并期间始终会发生冲突。它们没有完全分离，很可能它们维护着相同的仓库并具有相同的构建系统。单体应用的退出被标志为微服务的出现。但是它适用于后端！??
什么是微服务？对于微服务，一般而言最简单的解释是，它是一种开发技术，允许开发人员为平台的不同部分进行独立部署，而不会损害其他部分。独立部署的能力允许他们构建孤立或松散耦合的服务。为了使这个体系结构更稳定，有一些规则要遵循，可以总结如下：每个服务应该只有一个任务，它应该很小。所以负责这项服务的团队应该很小。关于团队和项目的规模，JamsLwis和MartinFowlr在互联网上做出的最酷解释之一如下：
在我们与微服务从业者的对话中，我们看到了一系列服务规模。报道的最大规模遵循亚马逊关于TwoPizzaTam的概念（即整个团队可以由两个比萨饼供给），意味着不超过十几个人。在规模较小的规模上，我们已经看到了一个由六人组成的团队支持六项服务的设置。
我画了一个简单的草图，为整体和微服务提供了直观的解释：
从上图可以理解，微服务中的每个服务都是一个独立的应用，除了UI。UI仍然是一体的！当一个团队处理所有服务并且公司正在扩展时，前端团队将开始苦苦挣扎并且无法跟上它，这是这种架构的瓶颈。
除了瓶颈之外，这种架构也会导致一些组织问题。假设公司正在发展并将采用需要跨职能小团队的敏捷开发方法。在这个常见的例子中，产品所有者自然会开始将故事定义为前端和后端任务，而跨职能团队将永远不会成为真正的跨职能部门。这将是一个浅薄的泡沫，看起来像一个敏捷的团队，但它将在内部分开。关于管理这种团队的更多信息将是一项非常重要的工作。在每个计划中，如果有足够的前端任务或者sprint中有足够的后端任务，则会有一个问题。为了解决这里描述的所有问题和许多其他问题，几年前出现了微前端的想法并且开始迅速普及。
解决微服务中的瓶颈问题：MicroFrontnds??解决方案实际上非常明显，采用了多年来为后端服务工作的相同原则：将前端整体划分为小的UI片段。但UI与服务并不十分相似，它是最终用户与产品之间的接口，应该是一致且无缝的。更重要的是，在单页面应用时代，整个应用在客户端的浏览器上运行。它们不再是简单的HTML文件，相反，它们是复杂的软件，达到了非常复杂的水平。现在我觉得微型前端的定义是必要的：
MicroFrontnds背后的想法是将网站或Wb应用视为独立团队拥有的功能组合。每个团队都有一个独特的业务或任务领域，做他们