Question

我正在使用jHipster和微服务架构开展项目，我是这项技术的新手，但我非常关注性能和应用程序架构。

所以我的用例是有一个网关和另一个微服务，网关负责管理所有用户相关数据，如收藏餐馆......，另一个微服务负责餐馆数据管理，包括粗略和搜索操作。

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

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中的Read模型。微服务订阅餐馆相关的域事件，如RestaurantRenamed或RestaurantRemoved，并相应地更新收藏餐馆（例如，当收到RestaurantRemoved事件时，它会删除收藏餐馆）。这个微服务可以尽可能快地完成（即通过使用分片或索引，不使用任何连接），并且可以独立扩展。

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

这种架构更复杂，但它可以让您更好地分离关注点和快速轻量级线性可扩展查询。

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

1 个答案: