如何管理微服务上的常见前端组件

Question

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

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

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

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

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

我们如何平衡这一点，或者我们能做到吗？

感谢@kayess:简而言之，如何将共享内核应用于微服务，因为团队将不会相互依赖？

Answer 1

我发现的第一个解决方案是让这些组件共享并从单点进行维护，比如在需要时从不同的组安装节点包和

。

简而言之，微服务体系结构风格的1是一种将单个应用程序开发为一套小服务的方法，每个应用程序都在其自己的进程中运行，并与轻量级机制进行通信。

您应该在每个单独的存储库中管理您的组件。使用semantic versioning发布更新并监视兼容性中断。

很难维护，因为在未来，不同的组可能会对组件有不同的需求。

你的配置的可维护性肯定不会比周围的任何框架都高，因为数百万的程序员依赖于这些框架并一起开发它们。

您可以使用单一存储库方法(将所有组件放入一个单独的存储库中)，但我认为这将很快使事情变得混乱。