Skip to main content

微服务中的API编织问题

Submitted by taotao on Thu, 05/16/2019 - 21:43

问题概述

在最近的工作中,碰到了一个同事反馈的问题,就是说我们目前在使用微服务的概念设计系统的架构,那么每个服务都是一个业务边界比较垂直服务,打个比方我们商城中有订单服务、商品服务、促销服务、评论服务,那么问题来了,比如我们在商品的详情页面需要聚合来自商品、评论、促销等服务的数据之后,才能返回商品详情页所需要的数据,这么多的微服务,我们需要在商品详情服务中每次有新的请求过来时,每次都调用一遍吗?如果每次都调用一遍,那么这些服务的网络通信开销会很大,而且每次都要对数据做大量的集合遍历计算,对性能会产生很严重的影响,所以我们需要找到一种方式,在微服务的架构设计下,能够高效的提供数据给商品详情服务。

如何解决

API网关模式

如果聚合这些数据?有两个方式,其中之一就是通过利用API网关聚合多个服务之间的数据,然后再给商城的商品详情服务使用。API网关可以将数据缓存起来,提升效率。 具体的做法可以参考下图:

API-Gateway-Composite

这种模式的缺点就是网关需要在内存中聚合大量的数据进行计算,而且有存在性能问题的可能性。

CRQS模式

另一种方法可以是采用CQRS模式,每个微服务通过事件的机制发布消息,让其他服务知道并做出相应的处理,比如这里的举出的例子,商品详细服务需要聚合,商品基础信息,商品的评论信息、商品的促销信息等等,那么这里每一个微服务之间通过发送消息的方式通知商品详情服务,商品详情服务接收到这些服务的消息之后,再进行数据的组合计算,然后返回给客户端。具体的做法如下图所示,这种模式的缺点

  1. 有可能导致相同的逻辑在多个地方被实现
  2. 增加了服务之间的调用关系的复杂性
  3. 有可能导致暂时的数据不一致

这种模式的优点如下:

  1. 微服务的实现者不需要关心调用方是如何组织数据提供给展示方的
  2. 服务之间的关系是解耦的,服务之间没有强依赖

cqrs

 

参考资料

https://microservices.io/patterns/data/cqrs.html

https://microservices.io/patterns/data/api-composition.html

 

Add new comment

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.