我所在的公司正在考虑迁移到微服务/ kubernetes架构,但在研究中遇到了几个障碍,所以我想我会把它们放在这里。
对于典型的单片数据库,许多查询从其他源/表加入,这通常被认为是不同的微服务责任(例如,客户 - >订单)。
我现在的问题是,通过微服务,什么是最佳实践?
我找到了一些建议的方法:
1)加入代码。基本上运行多个查询。例如:
const user = UserService.getUserById(1);
const order = OrderService.getForUser(user);
我喜欢这种方法,可以清楚地看到数据来自何处,以及需要什么等等。但是这会引发额外延迟的问题。像以前一样,我可以加入此查询,只有一次数据库之旅。我现在有2个(或更多,具体取决于所需数据)对数据库的请求。
2)加入外部服务。构建一个处理查询的单独服务。 - 这就像拥有一个内部api一样,每个服务都依赖于它,并且作为单点故障似乎是一种不好的做法。也许我看错了。
3)加入mysql。将所有数据放在同一数据库和查询中。这样可以单程访问mysql,但是会破坏微服务方法,并且无法为每个服务提供数据库/模式。
我个人觉得选项1是最通用的选项,但我很好奇多次往返的额外延迟,以及你们如何处理它。或许还有另一种我没有看到的解决方案。
答案 0 :(得分:1)
我不会太担心延迟,因为所有的调用都是异步的。
微服务都是关于选项的,有选择性的:可扩展性,健壮性/抗碎片性,部署等等。你不能使整个系统健壮但你可以做一些(重要的位)。 / p>
我将专注于域模型/边界上下文的建模,尝试获得单一 责任原则权利,希望能帮助您避免功能复制,死星依赖。
Very basic µService Architecture
读:
Domain-Driven Design: Tackling Complexity in the Heart of Software