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

Question

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

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

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

PS：我正在使用 mongoDB 来存储数据

1 - 仅将餐厅的 ID 保存在我的用户最喜欢的文档中：

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：请记住，我可能会面临大量流量。

我会根据这个来回答。

首先，您应该将Favorite Restaurants 移至专用微服务，并让 API 网关仅进行路由和交叉关注（身份验证、授权、SSL 终止等）。

其次，您可以在最喜欢的餐厅有界上下文中拆分读取和写入问题中的问题 - 使用 CQRS。

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

另一个微服务可能负责以完全非规范化的方式维护每个用户最喜欢的餐厅列表：该列表包含餐厅的 ID 和标题（以及其他需要的属性） - CQRS 中的读取模型。微服务订阅了与餐厅相关的域事件，如RestaurantRenamed 或RestaurantRemoved，并相应地更新收藏餐厅（例如，当收到RestaurantRemoved 事件时，它会删除收藏餐厅）。此微服务可以尽可能快地制作（即通过使用分片或索引，并且不使用任何 joins）并且可以独立扩展。

重要的是，Read 微服务最终与其他微服务（Favorite restaurant 添加/删除微服务和 Restaurant management 微服务）保持一致。设计 UI 时应牢记这一点；或者，您可以让 API 网关等待读取模型更新。

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