如何管理微服务架构使用的库依赖？

Question

我的英语不好。所以如果你不明白，请告诉我。

我设计了微服务架构。每个服务都有相同的库，该库是团队成员制作的。

（这些库已经是分布式maven系统，并且我们使用了版本控制。）

我想知道如何管理这些常见的库依赖项（版本）。有时，如果库版本发生变化，我们必须检查所有服务并升级依赖项。

于是有人对我说。 Try to make common library which has all library dependency, than other services use that common library.

但我不喜欢这些想法。这最适合微服务架构吗？

如何管理微服务架构使用的库依赖？

谢谢你！

Answer 1

使用包装

答案很简单：包装。有多种工具可以帮助您将库打包成某种可在项目之间重用的格式。

1. 你可以在 javascript 世界中使用 npm

2. 您主要可以在 .net 世界中使用 nuget

3. 您主要可以在 java 世界中使用 maven/artifactory

这样的例子还在继续。概念和想法是相同的。

谨防滥用微服务

但请记住以下几点。微服务的优势之一是各个团队可以使用他们喜欢的任何技术和任何框架来开发自己的微服务。大多数公司放弃了这种思维方式，因为随着时间的推移，他们无法让这么多人了解这么多框架。不过，如果团队足够大并且领域足够大以保证微服务，则需要一些思考。

第二件事是为什么要使用公共库？除了简单的实用程序之外，微服务甚至不应该调用相同的数据库。检查除了调用相同 api 等的外部 sdk 之外，您是否正在共享资源。

通过语义版本控制向后兼容

如果即使在最小化依赖关系之后您仍然需要一些包，那么语义版本控制就是关键。您必须在以下各项之间做出决定

向后兼容性和影响。

在语义版本控制中，我们会维护同一软件的版本，直到我们不再维护为止。通过在包中使用 xyz 版本并维护每个主要至少四个分支，您可以以最小的影响支持多个消费者。这样做的缺点是您必须支持多个版本。

x（主要版本）中的更新意味着破坏兼容性。

y 中的更新意味着扩展库但保持兼容性。

更新a，意味着只是错误修复，加上性能改进。