微服务设计模式（下）

正文

请到「今天看啥」查看全文

b、每个服务共享数据库

问题

我们已经讨论过，每个服务有一个数据库对于微服务来说是理想的，但是当应用程序是greenfield并且可以用DDD开发时，这是可能的。但如果应用程序是一个整体，并试图进入微服务，反规范化不是那么容易。在这种情况下，什么是合适的体系结构？

解决方案

每个服务共享数据库并不理想，但这是上述场景的有效解决方案。大多数人认为这是一种针对微服务的反模式，但对于棕地应用程序来说，这是将应用程序分解为更小的逻辑部分的良好开端。这不应该应用于绿地应用。在这种模式中，一个数据库可以与多个微服务对齐，但必须限制在2-3个最大值，否则，伸缩性、自主性和独立性将难以执行。

c、命令查询责任隔离(CQRS)

问题

一旦我们实现了每个服务的数据库，就需要进行查询，这需要来自多个服务的联合数据——这是不可能的。那么，我们如何在微服务体系结构中实现查询呢？

解决方案

CQRS建议将应用程序分为两部分——命令端和查询端。命令端处理创建、更新和删除请求。查询端通过使用物化视图来处理查询部分。事件源模式通常用于为任何数据更改创建事件。物化视图通过订阅事件流来保持更新。

d、Saga 模式

问题

当每个服务都有自己的数据库和跨越多个服务的业务事务时，我们如何确保服务之间的数据一致性?例如，对于客户有信用限额的电子商务应用程序，应用程序必须确保新订单不会超过客户的信用限额。由于订单和客户位于不同的数据库中，应用程序不能简单地使用本地ACID事务。

解决方案

Saga代表由几个子请求组成的高级业务流程，每个子请求在一个服务中更新数据。当请求失败时，每个请求都有一个补偿请求执行。它可以通过两种方式实现：

1. 编排——当没有中央协调时，每个服务产生并监听另一个服务的事件，并决定是否应该采取行动。

2. 编配——编配者(对象)负责传奇的决策制定和业务逻辑的排序。

4

请到「今天看啥」查看全文