微服务概念澄清和良好实践

Question

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

因此，当我们谈论使用微服务公开的业务时，这并不完全正确。如果您有一个规范化的数据库和一个用户表，另一个用于用户地址，因为一个用户可能有一个或多个地址（住宅，商业......），另一个表用于电话，原因相同，微服务操作系统客户端会使用更多比一张桌子。 1 - 在那种情况下我们仍然可以将其归类为微服务吗？ （也许我对微服务的理解可能不正确或不完整） 2 - 如果我不能将它归类为微服务，那么如何正确地为它开发微服务？ 3 - 如果每个微服务必须仅使用一个表来解耦的假设比大多数微服务情况可以恢复到 CRUD 展示？

Answer 1

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

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

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

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