我有两个微服务（ms）ms1和ms2。在这两个ms中，都有重复的可重用代码（例如散列/安全相关/ orm / etc）。仅供参考 代码有时也可以在数据库中维护某些状态（如果有可能的话）
有两种方法，我可以继续进行
如果我采用方法2，则好处是在发生任何更改时，我只需要重新部署ms3。如果采用方法1，则需要重新部署两个ms。在同一时间 时间方法2将需要单独的维护/资源/监控。
在系统设计方面，考虑到硬件资源不是挑战，哪种方法更理想。我刚刚提到了两个微服务，但是在某些情况下 有超过两个毫秒的重复代码。
我不确定什么标准可以帮助我决定选择共享库还是微服务？
更新：-
下面的博客让我很清楚，但仍然有疑问。会考虑并在需要时发布新问题。
https://blog.staticvoid.co.nz/2017/library_vs_microservice/
https://dzone.com/articles/dilemma-on-utility-module-making-a-jar-or-separate-2
答案 0 :(得分：2)
微服务只是建筑风格之一。在某些情况下，它比其他样式更好，在某些情况下，它更糟。如果您不使用微服务，那并不意味着您的架构不好。
如果您仍然希望拥有微服务，那么这些方法（共享库与作为新的“微服务”的库）都不适合。
我建议考虑以下内容。
微服务方法并不意味着每个端点都应该封装到单独的微服务中。通常，一个微服务会提供几个不同的端点。如果是这种情况，则将您的两个服务放入一个单一的微服务中，并通过两个不同的端点使其可访问。那么他们两个都共享一些类就很好了。
微服务通常应具有独立持久层。如果对公共持久层有很强的依赖性，请检查将它们拆分为不同的微服务的原因是什么。他们真的在不同业务域上工作吗？可以相互独立地开发和部署这些服务吗？如果没有，那么可能没有理由将它们放入不同的微服务中，而将它们放入单个微服务中可能更好。如果他们共享一些课程，那就很好了。
一个好的微服务应该为某些领域提供功能。如果将共享代码放在单独的微服务中，则可能是共享的“微服务”不为域提供任何功能，而仅仅是实用程序的包装。那不是微服务。
如果您有充分的理由将服务分为两个不同的微服务，请复制代码。每个微服务都应与其他微服务保持独立。应该有可能替换数据库并替换一个微服务的任何类别，而不影响另一个微服务。使它们独立的一种正常方法是复制您（当前）认为是共享的类。如果服务在时间上确实是独立的，则重复的代码将更改，并且在每个微服务中都将有所不同。如果必须同时在两个服务中更改此代码，则意味着您的拆分不正确，并且您拥有的不是微服务。