微服务架构缺陷

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}

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

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

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

GET /user/activities?location=colombia.

但是复制 table（用户）正在破坏微服务架构的主要基础

是否有任何其他方法可以做到这一点或支持这种类型的过滤条件，该过滤条件加入来自不同微服务的 tables。

Answer 1

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

看到这个implementing queries that need to retrieve data owned by multiple services。

你可以从this example (Customers and Orders example of http://eventuate.io/)中汲取很多灵感。

Answer 2

您可以通过多种方式避免速度变慢。对于第 2 步“2) 然后对于个人用户 Get /user/activity/{userId}”

您可以在一个呼叫中发送多个用户，而不是逐个发送用户。
您可以使用并行线程同时检索多个用户块。
如果你有一个网络界面，你可以使用分页，这真的很有帮助。

微服务架构缺陷

Microservice architecture Flaws

architecture

microservices

restful-architecture