微服务中的API编织问题
问题概述
在最近碰到了一个问题，我们目前在使用微服务的概念设计系统的架构，那么每个服务都是一个业务边界垂直的服务，打个比方，我们商城中有订单服务、商品服务、促销服务、评论服务，但是在商品的详情页面需要聚合来自商品、评论、促销等不同的服务数据之后，才能返回商品详情页所需要的数据，这么多的微服务，我们需要在商品详情服务中每次有新的请求过来时，每次都调用一遍吗？如果每次都调用一遍，那么这些服务的网络通信开销会很大，而且每次都要对数据做大量的集合遍历计算，对性能会产生很严重的影响，所以我们需要找到一种方式，在微服务的架构设计下，能够高效的提供数据给商品详情服务。
如何解决
API网关模式
如果聚合这些数据？有两个方式，其中之一就是通过利用API网关聚合多个服务之间的数据，然后再给商城的商品详情服务使用。API网关可以将数据缓存起来，提升效率。 具体的做法可以参考下图：
这种模式的缺点就是网关需要在内存中聚合大量的数据进行计算，而且有存在性能问题的可能性。
CRQS模式
另一种方法可以是采用CQRS模式，每个微服务通过事件的机制发布消息，让其他服务知道并做出相应的处理，比如这里的举出的例子，商品详细服务需要聚合，商品基础信息，商品的评论信息、商品的促销信息等等，那么这里每一个微服务之间通过发送消息的方式通知商品详情服务，商品详情服务接收到这些服务的消息之后，再进行数据的组合计算，然后返回给客户端。具体的做法如下图所示，
这种模式的缺点:
- 有可能导致相同的逻辑在多个地方被实现
- 增加了服务之间的调用关系的复杂性
- 有可能导致暂时的数据不一致
这种模式的优点如下：
- 微服务的实现者不需要关心调用方是如何组织数据提供给展示方的
- 服务之间的关系是解耦的，服务之间没有强依赖
参考资料