微服务的原则之一是它们是独立开发和部署的，有些人甚至说微服务必须使用不同的表才能真正解耦和独立。
因此，当我们谈论使用微服务暴露的业务时，并不完全正确。如果您有一个规范化的数据库和一个用户表，另一个用户地址，因为一个用户可能有一个或多个地址（住宅，商业......）和另一个用于电话的表，出于同样的原因，微服务os客户端将使用更多比一张桌子。 1 - 在这种情况下，我们仍然可以将其归类为微服务？ （也许我对微服务的理解可能不正确或不完整） 2 - 如果我不能将其归类为微服务，而不是如何正确地为其开发微服务？ 3 - 如果假设每个微服务必须使用一个表来解耦而不是大多数微服务案例，那么可以恢复到CRUD博览会吗？
答案 0 :(得分：0)
你是对的。在许多情况下，您的数据模型具有非常互连的结构。它没有任何问题，因为你的问题要求事情具有这样的结构。这是与NoSQL相关的旧讨论。显然，你不能抛弃关系数据库来解决关系问题。
在您的情况下，您需要问自己为什么要使用微服务。您的代码是否太复杂而无法维护？您是否想要尝试以一种不能简单地作为整体注入模块的方式独立地发展您的系统的一部分？您是否有独立的开发团队，应该独立工作以提高工作效率？你有可扩展性问题吗？
当把东西分解成微服务时，你可以使用的一条经验法则，至少在最初，是试图避免让多个微服务访问同一个数据库中的相同表。如果每个微服务都有自己的数据库的常见模式。
因此，在您的示例中，您的系统会保留有关人员的关系数据。然后，您可以将此系统描述为另一个需要读取和写入有关人员数据的系统的微服务。请注意，这与访问同一数据库的两个系统不同，因为第二个系统会通过REST接口间接访问它。