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

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

因此，当我们谈论使用微服务的业务时，这并不完全正确。如果您有一个规范化的数据库和一个用户表，另一个表用于用户地址，因为一个用户可能有一个或多个地址（住宅、商业…），另一个表用于电话，原因与micro service os客户端使用多个表的原因相同。 1-在这种情况下，我们仍然可以将其归类为微服务？（可能我对微服务的理解不正确或不完整） 2-如果我不能将其归类为微服务，那么如何正确地为其开发微服务？

---

3-如果假设每个微服务必须只使用一个表来解耦，那么大多数情况下的微服务都可以恢复到CRUD exposition？

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

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

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

---

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

我将更多地从功能上拆分微服务。在您的情况下，服务可以是一个地址簿，其中包含解决分配给它的任务所需的数据存储。我从来没有听过有人提到单表限制，这没有多大意义，因为微服务并不局限于使用关系数据库甚至数据库。