如何管理微服务的前端，特别是当你有共同的组件时？我在互联网上找到了一些解决方案，但它们都有一些缺点，而且它们都不适合我们。
让我澄清一下我的问题。我们有超过5组人在一个大型单一项目中从事不同的微服务。几乎所有这些都在前端有一些共同的共享组件。而这些组件是巨大的，因为它们已经是一个不同的项目，但完全共享。现在如何管理这些共享组件，还是应该复制它们？
我找到的第一个解决方案是在不同的组需要时，从节点包和npm install这样的单点共享和维护这些组件。但是在这一点上，微服务方法被打破了，因为每个人都将依赖于这些组件，没有人能够在他们需要的时候尽快维护，而不是很好。并且很难维护，因为将来不同的组可能会对组件有不同的需求。
其次是根据每个项目复制组件并在微服务组内开发，但这次它变得非常frankenstein，我们应该遵守的常见概念很难捕捉到。这是一个真正的企业项目，所有组件应该在行为方面匹配，并查看项目中重新处理的其他组件。
因此，我们需要一个适用于企业项目的前端解决方案，该项目需要遵循相同的规则（如字体大小，颜色，操作等），因为它是单片编写的，但可以通过不同的团体同时进行。
我们如何平衡或者我们可以平衡？
感谢@kayess：很短时间如何在微服务上应用共享内核，因为团队不会彼此依赖？
答案 0 :(得分：2)
我找到的第一个解决方案是共享和维护这些组件 从节点包和npm安装的单点开始 来自不同的群体。但在这一点上，微服务方法是 因为每个人都会依赖这些组件而被打破
我相信你对微服务的理解是错误的。福勒对微服务的定义：
简而言之，微服务架构风格1是一种方法 将单个应用程序开发为一套小型服务 在自己的进程中运行并与轻量级通信 机制，通常是HTTP资源API。
贵公司的微服务可以使用通用组件。微服务比组件具有更高的抽象级别。不要试图让每个组件都成为微服务。
您应该在每个单独的存储库中管理您的组件。使用semantic versioning发布更新并监视兼容性中断。
非常难以维护，因为将来不同的团体可能会 该组件的不同需求。
我不相信这很难维持。由于数百万程序员依赖于这些框架并将它们一起开发，因此您的配置的可维护性肯定不会高于任何框架。这是维护者技能的一个问题。
你可以采用单一的存储库方法（将所有组件放入一个单独但独立的存储库中），但我认为这会很快搞乱事情。