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