关于API微服务网关

本文探讨了在微服务架构中,API网关作为统一入口的重要性。介绍了单节点API网关和Backends for frontends网关两种模式,并讨论了它们在高并发下可能面临的性能瓶颈。此外,文章还分享了几个开源API网关项目,如Goku、Orange、Netflix Zuul、apiaxle和api-umbrella,以供实施参考。
摘要由CSDN通过智能技术生成

背景

我们都知道,在微服务架构风格里,一个应用会被拆分成多个小的服务系统,并且这些小系统都可以自成体系,可以拥有自己的数据库、框架语言等。它们通常都可以提供接口来被各种应用程序调用。 但是在UI上进行展示的时候,我们通常需要在一个界面上展示很多数据,这些数据可能来自于不同的微服务中。 打个比方:要查看一个电商平台的商品详情页,这个商品详情页包括标题、价格、库存、评价等等,这些数据可能在不同的微服务系统之中,如下所示: • 产品 - 负责提供商品的标题,描述,规格等。 • 价格 - 负责对产品进行定价,价格策略计算,促销价等。 • 库存 - 负责产品库存。 • 评价 - 负责用户对商品的评论,回复等。 现在,商品详情页需要从这些微服务中拉取相应的信息,问题来了?

由于用的是多个服务系统的架构,所以依靠单个数据库的 join 查询结果不可行,那么该怎么访问各个服务呢?

按照微服务设计的指导原则,我们的微服务可能存在下面的问题: • 服务使用了多种协议,因为不同的协议有不同的应场景用,比如可能同时使用 HTTP, AMQP, gRPC 等。 • 服务的划分可能随着时间而变化。 • 服务的实例或者Host+端口可能会动态的变化。 那么,对于前端的UI需求也可能会有以下几种: • 粗粒度的API,而微服务通常提供的细粒度的API,对于UI来说如果要调用细粒度的api可能需要调用很多次,这是个不小的问题。 • 不同的客户端设备可能需要不同的数据。Web,H5,APP • 不同设备的网络性能,对于多个api来说,这个访问需要转移的服务端会快得多

那么如何解决呢? 这种情况下,我们就需要一个今天要讲的这个

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值