Architecture 如何管理MicroService上的通用前端组件

如何在微服务上管理前端，特别是当您有公共组件时？我在网上找到了一些解决方案，但都有一些缺点，没有一个适合我们

让我澄清我的问题。在一个大型项目中，我们有超过5组人员在不同的微服务上工作。几乎所有的前端都有一些公共的、共享的组件。这些组件是巨大的，因为它们已经是一个不同的项目，但完全共享。现在如何管理这些共享组件，或者我们应该复制它们

我发现的第一个解决方案是让这些组件共享，并在需要时从单个点进行维护，比如节点包和npm安装。但在这一点上，微服务方法被打破了，因为每个人都将依赖于这些组件，没有人能够在需要时立即进行维护，这并不好。而且很难维护，因为未来不同的群体可能会对组件有不同的需求

第二种方法是根据每个项目复制组件，并在微服务组内开发，但这一次它变成了一个非常弗兰肯斯坦，我们应该遵守的共同概念很难理解。这是一个真正的企业项目，所有组件都应该在行为上匹配，并关注项目中重复出现的其他组件

因此，我们需要一个适用于微服务的前端解决方案，该解决方案应适用于一个企业项目，该项目需要在不同的点上遵守相同的规则（如字体大小、颜色、操作等），因为它是完整编写的，但可由不同的组同时维护

我们如何平衡这一点，或者我们可以

感谢@kayes：很快，由于团队之间不再相互依赖，如何在微服务上应用共享内核

我找到的第一个解决方案是共享和维护这些组件 从单点开始，如需要，安装节点包和npm 来自不同的群体。但在这一点上，微服务方法是 因为每个人都将依赖于这些组件

我相信你对微服务的理解是错误的。Fowler对微服务的定义：

简言之，微服务体系结构风格是实现 将单个应用程序开发为一套小型服务，每个 在自己的进程中运行并与轻量级 机制，通常是HTTP资源API

您公司的微服务可以使用通用组件。微服务是比组件高得多的抽象级别。不要试图使每个组件都成为微服务

您应该分别在单独的存储库中管理组件。用于发布更新和监视兼容性中断

而且很难维持，因为在未来不同的群体可能会 组件的不同需求

我认为这并不难维持。您的配置的可维护性肯定不会比任何框架都高，因为数百万程序员依赖于这些框架并共同开发它们。这是对维修人员技能的要求

---

您可以使用单片存储库方法（将所有组件放在一个单独的、但独立的repo中），但我认为这会很快把事情搞砸。

对我来说，这听起来像是在询问DDD术语。我寻找共享内核，它被定义为“系统的商定子集可能在不同团队之间共享。严格的协调规则适用。”这完全符合我们的要求。现在的问题是如何在微服务上应用共享内核，因为团队之间并不相互依赖。我认为您应该将这些信息完整地编辑到您的问题中，以获得简明的答案。你抓住了一些要点，但我认为我们走的不是同一条路。我们不想让每个组件都成为微服务。正如你所说的，微服务是更高的抽象。但我们想在不同的微服务中使用相同的组件。就像我们得到了微服务“a”和“B”，还有一个“组件a”“这两个团队都应该使用。A和B有时使用相同的服务，相同的api，我们对那些没有问题的服务进行了cdc测试，每个微服务都有BFF将这些api转换到自己的域。但这里的问题是前端，组件A是前端组件，应该可以与所有微服务一起维护，而不是api。API由微服务负责，BFF也与之类似，维护它们很容易，它们是绑定微服务的，但前端应该由所有团队负责，我们不能像BFF那样划分。我希望我能解释一下。@wertigom你的问题不是技术问题，而是组织问题。使用语义版本控制在微服务中维护相同（或兼容）的组件版本。复制/粘贴组件代码会给您带来噩梦。