站务联系
为什么你的代码是一个单体？ 除了早已实现了微后端的应用此外，所有后端应用本质上都是单一的应用。原因是假如您正在使用 React 库进行开发，并且假如您有两个团队，则两个团队都应当使用相似的React 库，并且两个团队应当在布署时保持同步，并且在代码合并其间仍然会发生冲突。它们没有完全分离，很或许他们维护着相似的库房并具备相似的建构系统。单体应用的退出被标识为微服务的出现。但是它适用于前端！ 什么是微服务？ 对于微服务，一般而言最简略的解释是，它是一种开发技术，允许开发人员为平台的不同部份进行独立布署，而不会损害其他部份。独立布署的能力容许它们建立孤立或松散耦合的服务。为了让这个机制结构更稳定，有一些规则要遵守，可以小结如下：每个服务应当只有一个任务，它应当太小。所以负责这项服务的团队应当太小。关于团队跟项目的规模，James Lewis 和 Martin Fowler 在互联网上作出的最酷解释之一如下： 在我们与微服务从业者的对话中，我们听到了一系列服务规模。报道的最大规模依照京东关于Two Pizza Team的概念（即整个团队可以由两个比萨饼供给），意味着不少于十几个人。在规模较小的规模上，我们早已听到了一个由六人组成的团队支持六项服务的设置。
我画了一个简略的草图，为整体跟微服务提供了直观的解释： 从上图可以理解，微服务中的每位服务都是一个独立的应用，除了UI。UI一直是一体的！当一个团队处理所有服务使得公司正在扩充时，前端团队将开始苦苦挣扎甚至难以跟上它，这是这些构架的难题。 不仅难题此外，这种构架也会导致一些组织问题。假设公司正在发展并将选用还要 跨职能 小团队的敏捷开发方式。在这个常见的实例中，产品所有者自然会开始将故事定义为后端跟前端任务，而 跨职能 团队将永远不会成为真正的 跨职能 部门。这将是一个狭隘的泡沫，看起来象一个敏捷的团队，但它将在内部分开。关于管理这些团队的更多信息将是一项十分重要的工作。在每位计划中，如果有足够的后端任务或则sprint中有足够的前端任务，则会有一个问题。为了解决这儿描述的所有问题跟许多其他问题，几年前出现了微后端的看法甚至开始快速普及。 解决微服务中的难题问题：Micro Frontends 解决方案实际上十分显著，采用了多年来为前端服务工作的相似原则：将后端整体界定为小的UI片断。但UI与服务并不非常相像，它是最终用户与产品之间的插口，应该是一致且无缝的。更重要的是，在单页面应用时代，整个应用在客户端的浏览器上运行。
它们不再是简略的HTML文件，相反，它们是复杂的硬件，达到了极其复杂的水平。现在我认为微型后端的定义是必要的： Micro Frontends背后的看法是将网站或Web应用视为独立团队拥有的功能组合。每个团队都有一个奇特的业务或任务领域，做她们关注跟专注的事情。团队是跨职能的，从数据库至用户界面开发端到端的功能。（） 根据我迄今为止的经验，对于许多公司来说，直接选用前面提出的构架真的很难。许多其他人都有很大的遗留负担，这让她们难以迁移至新的构架。出于这个缘由，更厚实的后边解决方案愈发灵活，易于选用跟安全迁移至关重要。在更具体地绪论了体系结构后，我将尝试提供一些机制结构的洞察，该体系结构确认了上述提议并容许更灵活的形式。在深入了解细节之前，我需要推行一些术语。 整体结构跟一些术语 让我们假定我们通过业务功能平行界定整体应用结构。我们最终会得到几个较小的应用，它们与单体应用具备相似的结构。但是假如我们在所有这种大型单体应用之上添加一个特殊应用，用户将与这个新应用进行通讯，它将把每位小应用的旧单体UI组合成一个。这个新遮罩可以命名为条纹遮罩，因为它从每位微服务中获取生成的UI部件，并为最终用户组合成一个无缝 UI，这将是微后端的最直接实现 为了更好地理解，我将每位大型单体应用称为微应用，因为他们都是独立的应用，而不仅仅是微服务，它们都有UI部件，每个都代表端到端的业务功能。
