背景
我们都知道,在微服务架构风格里,一个应用会被拆分成多个小的服务系统,并且这些小系统都可以自成体系,可以拥有自己的数据库、框架语言等。它们通常都可以提供接口来被各种应用程序调用。 但是在UI上进行展示的时候,我们通常需要在一个界面上展示很多数据,这些数据可能来自于不同的微服务中。 打个比方:要查看一个电商平台的商品详情页,这个商品详情页包括标题、价格、库存、评价等等,这些数据可能在不同的微服务系统之中,如下所示: • 产品 - 负责提供商品的标题,描述,规格等。 • 价格 - 负责对产品进行定价,价格策略计算,促销价等。 • 库存 - 负责产品库存。 • 评价 - 负责用户对商品的评论,回复等。 现在,商品详情页需要从这些微服务中拉取相应的信息,问题来了?
由于用的是多个服务系统的架构,所以依靠单个数据库的 join 查询结果不可行,那么该怎么访问各个服务呢?
按照微服务设计的指导原则,我们的微服务可能存在下面的问题: • 服务使用了多种协议,因为不同的协议有不同的应场景用,比如可能同时使用 HTTP, AMQP, gRPC 等。 • 服务的划分可能随着时间而变化。 • 服务的实例或者Host+端口可能会动态的变化。 那么,对于前端的UI需求也可能会有以下几种: • 粗粒度的API,而微服务通常提供的细粒度的API,对于UI来说如果要调用细粒度的api可能需要调用很多次,这是个不小的问题。 • 不同的客户端设备可能需要不同的数据。Web,H5,APP • 不同设备的网络性能,对于多个api来说,这个访问需要转移的服务端会快得多
那么如何解决呢? 这种情况下,我们就需要一个今天要讲的这个