关于API微服务网关

背景

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

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

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

那么如何解决呢？这种情况下，我们就需要一个今天要讲的这个东西， API 网关（API Gataway）。

API 网关

下面是百度上针对于 API 网关的介绍： API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。 API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。

Chris Richardson 在他的博客中把 API 网关划分为以下两种： • 单节点 API 网关 • Backends for frontends 网关

单节点网关

单节点的 API网关为每个客户端提供不同的API，而不是提供一种万能风格的API。这个网关和微软在 eShop 项目中推荐的网关是一致的。

Backends for frontends 网关

这种模式是针对不同的客户端来实现一个不同的API网关。

落地方案

以上两种 API 网关有什么问题呢？通常情况下， API 网关要做很多工作，它作为一个系统的后端总入口，承载着所有服务的组合路由转换等工作，除此之外，我们一般也会把安全，限流，缓存，日志，监控，重试，熔断等放到 API 网关来做，那么可以试想在高并发的情况下，这里可能会出现一个性能瓶颈。另外，如果没有开源项目的支撑前提下，自己来做这样一套东西，是非常大的一个工作量，而且还要做 API 网关本身的高可用等，如果一旦做不好，有可能最先挂掉的不是你的其他服务，而就是这个API网关。这个时候，通常我们会去找一些开源的 API 网关项目，博主已经给你找好了，目前社区的关于 API Gataway 的项目有以下这些： Goku：Goku是一个可扩展的开放源码API Layer(也称为API网关或API中间件)。开箱即用，全界面配置，操作简单，通过插件扩展，它提供了超越核心平台的额外功能和服务。 Orange：基于OpenResty的一个API网关程序，同样是由国人开发的。 Netflix zuul：Zuul是一种提供动态路由、监视、弹性、安全性等功能的边缘服务。Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。 apiaxle: Nodejs 实现的一个 API 网关。 api-umbrella: Ruby 实现的一个 API 网关。