1、前言
所在公司目前接入层是阿里云的SLB,然后经过Nginx+Lua转发到后端服务(Lua主要是限流)。 随着业务的发展,发现nginx配置越来越复杂,但又没有统一的管理,于是把Nginx这层改造成基于 OpenResty的Nginx 应用的API Gateway。于是上网总结和梳理网关相关知识。
问题:
由于我们使用的服务系统架构,所以没办法像传统单体应用一样依靠数据库的 join 查询来得到最终结果,那么如何才能访问各个服务呢?
按照微服务设计的指导原则,我们的微服务可能存在下面的问题:
服务使用了多种协议:因为不同的协议有不同的应场景用,比如可能同时使用 HTTP, AMQP, gRPC 等。
服务的划分可能随着时间而变化。
服务的实例或者Host+端口可能会动态的变化。
那么,对于前端的UI需求也可能会有以下几种:
粗粒度的API,而微服务通常提供的细粒度的API,对于UI来说如果要调用细粒度的api可能需要调用很多次,这是个不小的问题。
不同的客户端可能需要不同的数据。Web,H5,APP,OpenAPI
不同设备的网络性能,对于多个api来说,这个访问需要转移的服务端会快得多
以上,就是我们构建微服务的过程中可能会遇到的问题。
2、概念
API Gateway(API GW / API 网关),顾名思义,是企业 IT 在系统边界上提供给外部访问内部接口服务的统一入口。在微服务概念的流行之前,API网关的实体就已经诞生了,例如银行、证券等领域常见的前置机系统,它也是解决访问认证、报文转换、访问统计等问题的。
百度百科:API网关是一个服务器,是系统的唯一入口。从面向对象设计的角度看,它与外观模式类似。API网关封装了系统内部架构,为每个客户端提供一个定制的API。它可能还具有其它职责,如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。
API网关方式的核心要点是,所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。通常,网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。
3、网关使用场景
API网关的流行,源于近几年来,移动应用与企业间互联需求的兴起。移动应用、企业互联,使得后台服务支持的对象,从以前单一的Web应用,扩展到多种使用场景,且每种使用场景对后台服务的要求都不尽相同。这不仅增加了后台服务的响应量,还增加了后台服务的复杂性。
当应用架构是由一系列的微服务构建的时候,我们就应当考虑对外提供的服务如何与微服务进行交互。
我们根据使用场景分类大体如下:
1、Web App APIGateway 和 Mobile App APIGateway:
聚合作用:写简单的业务逻辑,跨多个service获取数据拼装结果。
在Mobile app产品信息页面仍然要展现很多的信息。例如,基本的产品信息,该页也会展示产品其他相关信息:
购物车;历史订单;顾客评论;低库存预警;运送选项;各种产品推荐;可替代的购买选项;
当使用单体应用架构时:
移动客户端通过给应用发送一个REST
请求来获取数据,比如:
GET api.company.com/productdetails/productId
负载均衡器路由这个请求到几个相同应用实例其中的一个。单体应用接着查询多个数据库表并返回响应给客户端。
当使用微服务架构的时候:
显示在产品详细信息页面的数据来自于多个微服务。如下是一些潜在的服务,它们也有可以展示在特定产品信息页面的数据:
购物车服务、订