architecture - 如何管理微服务上的通用前端组件

Question

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

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

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

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

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

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

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

Answer 1

First solution I found is to make those components shared and maintain from a single point like node packages and npm install when needed from different groups. But at this point the microservice approach is broken since everybody will be dependent to these components

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

In short, the microservice architectural style 1 is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.

贵公司的微服务具有通用组件是可以的。微服务是比组件更高层次的抽象。不要试图让每个组件都成为微服务。

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

And very hard to maintain since in the future different groups may different needs from the component.

我不认为这很难维护。您的配置的可维护性当然不会比任何框架高，因为数百万程序员依赖这些框架并一起开发它们。维护者的技术问题。

您可以采用单体存储库方法(将所有组件放入一个独立的存储库中)，但我认为这会很快把事情搞砸。