mongodb - jhipster - 如何掌握数据管理和微服务通信？

Question

我正在从事一个使用 jHipster 和微服务架构的项目，我是这项技术的新手，但我真的很关心性能和应用程序架构。

所以我的用例是有一个网关和另一个微服务，网关负责管理所有与用户相关的数据，例如最喜欢的餐厅......，另一个微服务负责餐厅数据管理，包括 crud 和搜索操作。

所以我的问题是，如果我有一个端点来添加新的最喜欢的餐厅或为特定用户选择所有最喜欢的餐厅，我将遵循什么方法

PS:我使用mongoDB来存储数据

1 - 在我的用户收藏文档中只保存餐厅的 ids :

pros : 
     - they will be no master data management if a restaurant is 
      updated.
cons : 
     - there will be a tied coupling between microservices because
      requesting favorite restaurant will depend on restaurant microservice 
     - performance impact requesting list of restaurants in every 
       favorite restaurant request

2 - 使用餐厅的嵌入文档保存最喜欢的餐厅

pros: 
     - there will be no tied coupling between microservices
     - better performance 
cons
     - we need master data management for updating data 
     - what to do if restaurant microservice is down when inserting a new favorite restaurant?

那么选择什么，有没有更好的方案或者更好的架构呢？另一个问题是如何在我的用例中利用 kafka 的优势？

Ps:请记住，我可能会遇到大量流量。

Answer 1

Ps: keep in mind that i might face a large trafic .

我将以此为基础回答。

首先，您应该将Favorite Restaurants 移动到专用的微服务，让 API 网关只进行路由和交叉关注(身份验证、授权、SSL 终止等)。

其次，您可以在 Favorite Restaurants 限界上下文中拆分 Read 和 Write concerns 中的关注点 - 使用 CQRS。

因此，添加/删除最喜欢的餐厅可以由发布 FavoriteRestaurantAdded(UserId, RestaurantId) 和 FavoriteRestaurantRemoved(UserId, RestaurantId) 域事件的微服务来处理。

另一个微服务可以负责以完全非规范化的方式为每个用户维护最喜欢的餐厅列表:该列表包含餐厅的 ID 和标题(以及其他需要的属性)- CQRS 中的读取模型。微服务订阅餐厅相关领域事件，如 RestaurantRenamed 或 RestaurantRemoved 并相应地更新最喜欢的餐厅(例如，当 RestaurantRemoved事件被接收)。这个微服务可以尽可能快地完成(即通过使用分片或索引而不使用任何连接)并且可以独立扩展。

重要的一点是，Read 微服务最终与其他微服务(最喜欢的餐厅添加/删除微服务和餐厅管理微服务)保持一致。在设计 UI 时应牢记这一点；或者，您可以让 API 网关等待读取模型更新。

这种架构更复杂，但它可以更好地分离关注点，并提供快速、线性可扩展的查询。