微服务和复制数据库表

Question

我一直致力于将单体系统 (.NET) 拆分为更小的有界上下文，从而拆分为多个类库。地址记录是系统的核心，因此对于不相关的实体返回 MASTER 地址记录很重要。每个微服务都有自己的数据库，其中包含与该有界上下文相关的表。我遇到了关于地址记录或地址实体的挑战。这两个有界上下文或库都需要使用地址表和相关查找表，例如州、国家/地区等。我是否应该在每个数据库中复制地址相关表并复制地址相关域类？如果我重复，我将在两个数据库中都有大量重复的地址记录，这让我陷入困境。如果我将地址表放在“位置服务”之类的地方，则很难在搜索结果中显示地址字段。也许这不是微服务的正确场景？

例子:
Microservice-1(产品A)
事件 -> 一对一 -> 地址

微服务 2(产品 B)
消火栓 -> 一对一 -> 地址

Microservice-3(产品 C)
检查 -> 多对一 -> 地址

Answer 1

为了更好地说明，我假设每个微服务都有 REST API。

在我看来，你有一个 IncidentService , 一个 FireHydrantService和 InspectionService这一切都依赖于LocationService .

通过遵循微服务方法，您必须了解要实现的两个目标:

松散耦合

内聚行为

这意味着不允许您的服务共享数据库(它可以在物理上相同，但在逻辑上不一样)，因此服务无法修改不同服务的数据或绕过负责的服务直接访问其数据。这必须由负责的服务通过其 API 专门完成。否则，内聚行为将面临风险。

RESTful API 很棒，因为我们也想松散耦合。

资源可能如下所示:

"incident": {
    "time": "...",
    "location" : {
        "name": "an arbitrary address"
        "href": "apis.yourdomain.com/locationservice/address/1"
        "type": "application/json"
    },
    "nearestHydrant": {
        "name": "hydrant 42"
        "href": "apis.yourdomain.com/firehydrantservice/hydrant/42"
        "type": "application/json"
    }
}

如您所见，这些实体(更好地表示)仅表示为链接引用(其中的实体)负责的服务。这种耦合是松散的，因为在您的应用程序的整个生命周期中，链接作为实体的表示不太可能发生变化。通过命名字段，您还可以获得 FireHydrant 之间关系的语义。和 Incident .

但是事情很容易变得复杂。假设像“域对象只能由负责的服务发出”这样的规则，以保持内聚行为。这意味着只有 FireHydrantService允许服务 FireHydrant .
现在想象一个请求，如“ Incident 地址 1”。应该查询最近的 FireHydrant的服务?按照上面的规则，应该是 FireHydrantService .但是 FireHydrantService知道，它不知道最近是什么意思？

在这种情况下，有一种叫做非权威缓存的东西(也可以保存在数据库中)。这只是意味着 LocationService允许存储 FireHydrant在缓存或数据库中，但不允许与他人共享。这样，仍然遵循上述规则，并且内聚行为仍然存在。非权威缓存不需要反射(reflect)完整的域对象 FireHydrant ，但完成用例所需的一切。
所以 IncidentService问 FireHydrantService对于最近的 FireHydrant(s) , 什么被委托(delegate)给 LocationService ，查询其非权威缓存以查找最近的位置，类型为 FireHydrant ，响应是对 FireHydrantService 的引用(链接)本身，它会检查 FireHydrant有它的 Inspection因此根据业务规则是有效的(如果不是，它将检查下一个)并将引用(链接)返回到 IncidentService .

我的经验法则是，每个服务都可以在每个域对象上进行查询，但只能服务于它负责的域对象。 “查询域对象”可以存在于上述非权威缓存中。这当然会导致重复，有趣的部分是让它们保持同步。立即想到的一件事是使用事件溯源。服务发出事件“Hydrant 42 out of order”，LocationService 将从其缓存中删除 Hydrant 42。