迁移到Microservices - mysql

Question

我所在的公司正在考虑迁移到一个微服务/kubernetes体系结构，但在研究中遇到了一些障碍，所以我想在这里介绍一下。

对于典型的单块数据库，许多查询都来自其他源/表，这通常被认为是一种不同的微服务责任(例如。客户->订单)。

我现在的问题是，对于微服务来说，什么是最佳实践？

我发现了一些建议的方法：

1)加入代码。本质上运行多个查询。例：const user = UserService.getUserById(1); const order = OrderService.getForUser(user);

我喜欢这种方法，可以清楚地看到数据来自哪里，需要什么等等。然而，这就带来了额外的延迟问题。和以前一样，我可以加入这个查询，并且只能访问一个数据库。现在我有两个(或更多的请求取决于所需的数据)对数据库的请求。

2)加入外部服务。构建一个独立的服务来处理查询。-这感觉就像拥有一个每个服务都依赖的内部api，并且作为一个单一的失败点似乎是一个糟糕的实践。也许我看错了。

3)加入mysql。将所有数据保存在相同的数据库和查询中。这样做的好处是单次访问mysql，但是破坏了微服务方法，并消除了每个服务拥有数据库/模式的能力。

我个人认为选项1是最通用的选择，但我好奇的是，增加了多次往返的延迟，以及你们是如何处理的。或许还有另一种我看不到的解决办法。

Answer 1

我不会太担心延迟，因为所有的调用都是异步的。

Microservices的所有选项都是选择性的:可伸缩性、健壮性/抗脆弱性、部署等。您不能使整个系统健壮，但您可以使其中的一些(重要的位元)变得健壮。

我将把重点放在域模型/边界上下文的建模上，试图使单一责任原则正确，这将有望帮助您避免功能复制、死星依赖。

非常基本的服务架构

阅读：

建筑微型服务

领域驱动设计:解决软件核心的复杂性