Microservices 避免微服务中的瓶颈

我将为我的数据仓库应用程序应用微服务。应用程序中有4种主要的微服务：

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

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

3） 机器学习在推荐系统中的应用

4） 报表：用于生成报表

下图所示为：

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

您可以考虑

• 根据某些业务逻辑，将

  数据服务

  拆分为几个微服务
• 修改

  数据服务

  （如果需要）以支持多个服务实例。然后使用负载平衡器在这些实例之间拆分请求

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

---

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

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

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

---

如果您的服务使用来自

数据仓库

数据库和

数据服务

的单独表，只提供对数据库的访问层，而不提供任何额外的处理逻辑，则可以删除

数据服务

，并将数据访问逻辑移动到相应的服务。但另一方面想想——现在你只有一个地方（

数据服务

），知道如何使用

数据仓库

访问和操作，这就是微服务的意义。

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