微服务概念澄清和良好做法

Question

微服务的宗旨之一是它们是独立开发和部署的，有些人甚至说微服务必须使用不同的表才能真正解耦和独立。

因此，当我们谈论使用微服务暴露的业务时，它并不完全正确。如果您有一个标准化的数据库和一个用户表，另一个用于用户地址，因为一个用户可能有一个或多个地址（住宅、商业...）和另一个用于电话的表，原因与微服务os客户端使用多个表的原因相同。1-在这种情况下，我们仍然可以将其归类为微服务？（也许我对微服务的理解可能不正确或不完整）2-如果我不能将其归类为微服务，那么如何正确地为其开发微服务？3-如果假设每个微服务必须只使用一个表来解耦，那么大多数微服务的情况可以恢复到CRUD博览会？

Answer 1

你是对的。在许多情况下，您的数据模型具有非常互连的结构。这没有什么错，因为你的问题要求事物有这样的结构。这是一个与NoSQL相关的古老讨论。显然，您不能为了解决关系问题而抛弃关系数据库。

在您的情况下，您需要问问自己为什么要使用微服务。您的代码是否太复杂而无法维护？您想尝试以一种不能简单地作为模块注入到整体上的方式独立地发展系统的一部分吗？您是否有独立的开发团队，他们应该独立工作以提高效率？您是否存在可伸缩性问题？

在将事物分解为微服务时，至少在最初，您可以使用的一条经验法则是尽量避免让多个微服务访问同一数据库上的相同表。如果每个微服务都有自己的数据库，这是一种常见的模式。

因此，在您的示例中，您的系统保留有关人员的关系数据。然后，您可以将您描述的这个系统作为另一个系统的微服务，该系统需要读取和写入有关人员的数据。请注意，这与两个系统访问同一数据库不同，因为第二个系统将通过REST接口间接访问数据库。