避免微服务中的瓶颈

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

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

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

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

4）报告：用于报告生成

如下图：

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

来源

2017-02-28 Barcelona

你可能想

分裂Data Service到几个微服务的基础上，一些业务逻辑;
修改Data Service（如果需要）支持多个服务实例。然后使用负载均衡器在这些实例之间分割请求。

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

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

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

每个服务专用表 - 每个服务拥有一组表，这些表必须由该服务
架构进行访问perService - 每个服务都有一个对该服务来说是私有的数据库模式
数据库每个服务 - 每个服务都有自己的数据库。

如果使用单独的表从数据库Data Warehouse您的服务和Data Service不作任何额外的处理逻辑提供接入层到数据库中，那么，你可能会删除Data Service和移动数据访问逻辑相应的服务。但另一方面想想 - 现在你只有一个地方（Data Service），知道如何访问和操作微服务所关心的Data Warehouse。

来源

2017-02-28 13:56:25 Set

我可以让其他微服务（如Analytics，Reports，ML）直接访问DWH数据库吗？所以在这种情况下，它将成为“一个数据库，多个服务”。因为DWH中的数据很大并且数据定期更新。 – Barcelona

@Barcelona我已更新答案 – Set

DataService（DS）仅向其他服务提供数据访问逻辑（基本CRUD），并且不提供其他处理逻辑。其他处理逻辑（如导入，导出...）用于客户端调用。我想让其他服务与DS通信的原因是因为我想隐藏如何访问，查询和更新DWH到其他服务的逻辑。其他服务只需调用DS即可获取或更新数据。 – Barcelona

避免微服务中的瓶颈

回答

相关问题