微服务架构缺陷答案

【问题标题】：Microservice architecture Flaws微服务架构缺陷
【发布时间】：2017-10-20 10:50:02
【问题描述】：

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

假设有用于用户和帐户管理的微服务。有 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.

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

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

【问题讨论】：

你为什么不增加你的第二个电话？意思是一次性传递您认为相关的所有用户 ID？你也考虑过实现分页机制吗？
@OswinNoetzelmann 感谢您指出这一点。我们已经进行了分页。但是在这些情况下，我们计划通过发送电子邮件链接进行下载，然后通过搜索条件下载诸如 csv 下载之类的操作。有没有其他方法可以处理这种需要加入来自多个数据源的数据的场景。在我的问题中，我采用了简单的场景。但是，有很多复杂的场景在分页也无济于事。
如果您最终会遇到很多迫使您加入来自多个服务的数据的用例，您应该重新考虑您的服务边界。很难找到正确的界限，但一般来说，您需要代表自包含业务用例而不与实体相关的服务（例如，您不想要“用户服务”、“产品服务”等） .请阅读：martinfowler.com/articles/microservices.html

标签： architecture microservices restful-architecture

【解决方案1】：

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

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

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

【讨论】：

graphql 不会是替代解决方案（并且更具可扩展性），因为它使 api 客户端能够获取所需的任何数据？
可能，但我不确定graphql 和CRQS 之间哪个更快。 AFAIK 在微服务方面，CRQS 和 event sourcing 被认为是连接来自不同服务的表的最佳实践。

【解决方案2】：

您可以通过多种方式避免缓慢。对于第 2 步“2）然后对于单个用户获取 /user/activity/{userId}”

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

【讨论】：

感谢您的回答！。但是你能不能把问题看一遍，然后重新检查你是否回答过？