我的英语不好。所以如果你不明白，请告诉我。
我设计了微服务架构。每个服务都有相同的库，这是队友制作的。
（这些库已经是分布式maven系统，我们使用了版本控制。）
我想知道如何管理这些常见的库依赖（版本）。有时如果库版本发生变化，我们必须检查所有服务并升级依赖项。
所以有人对我说。
Try to make common library which has all library dependency, than other services use that common library.
但我不喜欢这些想法。 这是否最适合微服务架构？
如何管理微服务架构使用的库依赖？
谢谢！
【问题讨论】：
标签： microservices system-design
答案很简单：包装。有多种工具可以帮助您将库打包成可在项目之间重用的某种格式。
你可以在 javascript 世界中使用 npm
您可以主要在 .net 世界中使用 nuget
您可以主要在 java 世界中使用 maven/artifactory
名单还在继续。概念和想法是一样的。
但请记住以下几点。微服务的优势之一是各个团队可以使用他们喜欢的任何技术和任何框架来开发自己的微服务。大多数公司都放弃了这种思维方式，因为随着时间的推移，他们负担不起让这么多人知道这么多框架。但是，如果团队足够大并且领域足够大以保证微服务，它需要一些思考。
第二件事是为什么要使用通用库？除了简单的实用程序之外，微服务甚至不应该调用相同的数据库。检查除了调用相同 api 等的外部 sdk 之外，您是否共享资源。
如果即使在最小化依赖之后你仍然需要一些包，那么语义版本控制是关键。您必须在以下之间做出选择
向后兼容性和影响。
在语义版本控制中，我们一直在维护同一软件的版本，直到我们不这样做。通过在您的包中使用 x.y.z 版本并维护每个专业至少四个分支，您可以以最小的影响支持多个使用者。这样做的缺点是您必须支持多个版本。
x（主要版本）中的更新，意味着破坏兼容性。
更新y，意味着扩展库但保持兼容性。
在 a 中更新，意味着只是错误修复，以及性能改进。
【讨论】：
我认为最好有一个公共库并将其维护在一个地方。它应该是向后兼容的，以便在发生更改时不会影响依赖服务。
https://blog.scottlogic.com/2016/06/13/code-reuse-in-microservices-architecture.html 是一篇很好的博文，解释了微服务中的代码重用
【讨论】：