架构设计（4）--API网关

               

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

负载均衡器路由这个请求到几个相同应用实例其中的一个。单体应用接着查询多个数据库表并返回响应给客户端。

当使用微服务架构的时候:

显示在产品详细信息页面的数据来自于多个微服务。如下是一些潜在的服务，它们也有可以展示在特定产品信息页面的数据：

购物车服务、订