避免微服务中的瓶颈答案

【问题标题】：Avoid bottlenecks in microservices避免微服务中的瓶颈
【发布时间】：2017-02-28 00:51:28
【问题描述】：

我将为我的 Datawarehouse 应用程序应用微服务。应用中有 4 个主要的微服务：

1) 数据服务：将外部数据源导入/导出到 DWH 并从 DWH 查询数据。

2) 分析服务：用于 UI 上的图表可视化

3) 机器学习：用于推荐系统

4) 报告：用于生成报告

如下图：

每个服务都有自己的数据库，它们通过 TCP 和 Thift 序列化直接相互通信。这里的问题是数据服务承受来自其他服务的高负载并且可能成为应用程序的SPOF。 DWH 中的数据也很大（可能多达数亿条记录）。在这种情况下如何避免Data Service的瓶颈？或者我如何定义一个适当的有界上下文以避免瓶颈？

【问题讨论】：

标签： microservices

【解决方案1】：

你可以考虑

根据一些业务逻辑将Data Service拆分成几个微服务；
修改Data Service（如果需要）以支持多个服务实例。然后使用负载平衡器在这些实例之间拆分请求。

负载平衡器是一种充当反向代理并跨多个服务器分配网络或应用程序流量的设备。负载平衡器用于增加应用程序的容量（并发用户）和可靠性。

关于“一个数据库，多个服务”：

每个微服务都需要有自己的数据存储，否则，你没有分解。如果我们谈论的是关系数据库，那么这可以使用以下模式之一来实现：

每个服务的私有表 - 每个服务都拥有一组只能由该服务访问的表
Schema perService – 每个服务都有一个专用于该服务的数据库模式
每个服务的数据库 - 每个服务都有自己的数据库。

如果您的服务使用来自Data Warehouse 数据库和Data Service 的单独表仅提供对数据库的访问层而没有任何额外的处理逻辑，那么是的，您可以删除Data Service 并将数据访问逻辑移动到相应的服务。但换个角度想 - 现在你只有一个地方 (Data Service)，知道如何使用 Data Warehouse 进行访问和操作，这就是微服务的意义所在。

【讨论】：

能否让其他微服务（如 Analytics、Reports、ML）直接访问 DWH 数据库？所以在这种情况下，它将成为“一个数据库，多个服务”。因为 DWH 中的数据很大，而且数据会定期更新。
DataService (DS) 只向其他服务提供数据访问逻辑（基本 CRUD），不提供其他处理逻辑。其他处理逻辑（如导入、导出等）用于客户端调用。我之所以想让其他服务与 DS 通信，是因为我想将如何访问、查询和更新 DWH 的逻辑隐藏到其他服务。其他服务只是调用 DS 来获取或更新数据。
回答这个问题，因为这是微服务设计中一个非常常见的问题：总是需要在负载和处理速度之间进行权衡。如果数据服务的目标是简单地处理数据而不考虑数据的最新程度，您可以考虑在 DS 和其他服务之间添加一个消息队列。然后 DS 将从队列中拉出消息并尽快处理它们。这将有助于解决请求激增的问题。