微服务架构缺陷

Question

我们正面临与微服务架构有关的性能问题。

假设有用于用户和帐户管理的微服务。其中有 api 之类的

GET /users/{id} 
GET /users       (arrount 6 million users)

GET /accounts/{accountId}
GET /accounts 
and Other Operations on user and account

我们还有其他微服务，用于跟踪用户活动并列出用户在上次登录时所做的所有活动。

GET /user/activity/{userId}  (on an average 1000 to 10000 records)

我们为销售和营销团队提供基于搜索条件的个人用户活动和用户信息和帐户信息的保护，

let's say search criteria is like : get all user activies who are located in colombia
Algorithm : 

1)Get /users ? location = colombia
2)then for individual user Get /user/activity/{userId}

这就像连接来自不同数据库的两个表。

它非常慢并且会产生很多性能问题。

我所想到的是通过一项工作复制其他微服务中的用户表，以确保它是最新的并且只使用一个 api

GET /user/activities?location=colombia.

但是复制表（用户）打破了微服务架构的主要基础

有没有其他方法可以做到或支持这种类型的过滤条件，这些条件连接来自不同微服务的表。

Answer 1

您可能有兴趣使用 Command Query Responsibility Segregation

请参阅此实现需要检索多个服务拥有的数据的查询。

您可以从这个示例（http://eventuate.io/ 的客户和订单示例）中获得很多灵感。