如何管理微服务上的通用前端组件答案

【问题标题】：How to manage common frontend components on microservices如何管理微服务上的通用前端组件
【发布时间】：2017-04-23 16:48:07
【问题描述】：

如何管理微服务的前端，尤其是当您拥有通用组件时？我在互联网上找到了一些解决方案，但它们都有一些缺点，没有一个适合我们。

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

我找到的第一个解决方案是让这些组件在需要时从不同组共享和维护，例如节点包和 npm install。但是在这一点上，微服务方法被打破了，因为每个人都将依赖这些组件，没有人能够在需要时立即维护，这不好。而且很难维护，因为将来不同的组可能对组件有不同的需求。

第二是根据每个项目复制组件并在微服务组内开发，但这一次变得非常科学，我们应该遵守的共同概念很难掌握。这是一个真正的企业项目，所有组件都应该在行为方面匹配，并查看项目中再次出现的其他组件。

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

我们如何才能平衡这一点？

感谢@kayess：很快如何在微服务上应用共享内核，因为团队不会相互依赖？

【问题讨论】：

对我来说，这听起来像是您从 DDD 术语中询问 shared kernel 和 this。
我寻找共享内核，它被定义为“系统的一个商定子集可能在不同团队之间共享。适用严格的协调规则。”这完全符合我们想要的。现在的问题是如何在微服务上应用共享内核，因为团队之间不相互依赖。
我认为您应该将此信息彻底编辑到您的问题中以获得简洁的答案。

【解决方案1】：

我找到的第一个解决方案是让这些组件共享和维护需要时从节点包和 npm install 等单点来自不同的群体。但此时微服务方法是坏了，因为每个人都会依赖这些组件

我认为您对微服务的理解是错误的。 Fowler 对微服务的定义：

简而言之，微服务架构风格1 是一种将单个应用程序开发为一组小型服务，每个在自己的进程中运行并与轻量级通信机制，通常是 HTTP 资源 API。

贵公司的微服务拥有通用组件是可以的。与组件相比，微服务的抽象级别要高得多。不要试图让每个组件都成为微服务。

您应该在单独的存储库中管理您的组件。使用semantic versioning 发布更新并注意兼容性问题。

而且很难维护，因为将来不同的组可能来自组件的不同需求。

我不认为这很难维护。您的配置的可维护性肯定不高于周围的任何框架，因为数百万程序员依赖这些框架并一起开发它们。这是维护者的技能问题。

您可以采用单一存储库方法（将所有组件放入一个单独但独立的存储库），但我认为这会很快搞砸。

【讨论】：

你抓住了一些要点，但我认为我们不在同一条道路上。我们不会试图让每个组件都成为微服务。正如您所说，微服务是更高的抽象。但是我们想在那些不同的微服务中使用相同的组件。就像我们有微服务“A”和“B”，并且有一个“组件A”应该在两个团队中使用。 A 和 B 有时使用相同的服务，相同的 api，我们对那些没问题的服务进行了 cdc 测试，每个微服务都有 bffs 将这些 api 转换为自己的域。
但是这里的问题是前端，componentA是一个前端组件，应该与api不同，所有微服务都可以维护。 API 由微服务负责，bff 也类似，维护它们很容易，它们绑定微服务，但前端应该由所有团队负责，我们不能像 bff 那样划分。我希望我能解释一下。
@wertigom 您的问题不是技术问题，而是组织问题。使用语义版本控制在您的微服务中维护相同（或兼容）的组件版本。复制/粘贴组件代码会给你带来噩梦。