共享库与微服务?

微服务只是建筑风格中的一种。在某些情况下,它更好,在某些情况下,它比其他风格更差。如果不使用微服务,并不意味着你的体系结构不好。

如果您仍然希望使用微服务,那么这些方法(共享库与作为新的“微服务”的库)都不好。

我建议你考虑一下。

1. 微服务方法并不意味着每个端点都应该封装到单独的微服务中。这很正常 一 微服务提供 几个 不同的终点。如果这是您的情况,那么将您的两个服务放入一个sinbgle微服务中,并使它们可以通过两个不同的端点访问。那他们两个可以一起上课。

2. 微服务通常应该 独立的 持久层。如果对公共持久层有很强的依赖性,请检查,是什么原因将它们拆分为不同的微服务。他们真的在一起工作吗 不同的 商业领域?这些服务可以开发和部署吗 独立地 互相攻击?如果没有,那么可能没有理由将它们放到不同的微服务中,最好将它们放到 单一的 微服务。如果他们一起上课就好了。

3. 一个好的微服务应该为某些领域提供功能。如果将共享代码放入单独的微服务,那么可能是您共享的“微服务”不为域提供任何功能,而只是实用工具的包装器。那就是 不 微服务。

4. 如果您有充分的理由将您的服务分成两个不同的微服务,那么 复制 密码。每个微服务应该 独立的 在其他人身上。应该可以在不影响另一个微服务的情况下替换数据库和任何类。使它们独立的一种常见方法是复制您(当前)认为是共享的类。如果服务真的与时间无关,这个复制的代码将改变,并且在每个微服务中会有所不同。如果必须同时更改这两个服务中的代码,则意味着您的拆分不正确,而您所拥有的不是微服务。