javaapigateway_微服务中的API网关（APIGateway）

背景

我们知道在微服务架构风格中&＃xff0c;一个大应用被拆分成为了多个小的服务系统提供出来&＃xff0c;这些小的系统他们可以自成体系&＃xff0c;也就是说这些小系统可以拥有自己的数据库&＃xff0c;框架甚至语言等&＃xff0c;这些小系统通常以提供 Rest Api 风格的接口来被 H5, Android, IOS 以及第三方应用程序调用。

但是在UI上进行展示的时候&＃xff0c;我们通常需要在一个界面上展示很多数据&＃xff0c;这些数据可能来自于不同的微服务中&＃xff0c;举个例子。

在一个电商系统中&＃xff0c;查看一个商品详情页&＃xff0c;这个商品详情页包含商品的标题&＃xff0c;价格&＃xff0c;库存&＃xff0c;评论等&＃xff0c;这些数据对于后端来说可能是位于不同的微服务系统之中&＃xff0c;可能我后台的系统是这样来拆分我的服务的&＃xff1a;

产品服务 - 负责提供商品的标题&＃xff0c;描述&＃xff0c;规格等。

价格服务 - 负责对产品进行定价&＃xff0c;价格策略计算&＃xff0c;促销价等。

库存服务 - 负责产品库存。

评价服务 - 负责用户对商品的评论&＃xff0c;回复等。

现在&＃xff0c;商品详情页需要从这些微服务中拉取相应的信息&＃xff0c;问题来了&＃xff1f;

问题

由于我们使用的服务系统架构&＃xff0c;所以没办法像传统单体应用一样依靠数据库的 join 查询来得到最终结果&＃xff0c;那么如何才能访问各个服务呢&＃xff1f;

按照微服务设计的指导原则&＃xff0c;我们的微服务可能存在下面的问题&＃xff1a;

服务使用了多种协议&＃xff0c;因为不同的协议有不同的应场景用&＃xff0c;比如可能同时使用 HTTP, AMQP, gRPC 等。

服务的划分可能随着时间而变化。

服务的实例或者Host&＃43;端口可能会动态的变化。

那么&＃xff0c;对于前端的UI需求也可能会有以下几种&＃xff1a;

粗粒度的API&＃xff0c;而微服务通常提供的细粒度的API&＃xff0c;对于UI来说如果要调用细粒度的api可能需要调用很多次&＃xff0c;这是个不小的问题。

不同的客户端设备可能需要不同的数据。Web,H5,APP

不同设备的网络性能&＃xff0c;对于多个api来说&＃xff0c;这个访问需要转移的服务端会快得多

以上&＃xff0c;就是我们构建微服务的过程中可能会遇到的问题。那么如何解决呢&＃xff1f;

这种情况下&＃xff0c;我们就需要一个今天要讲的这个东西&＃xff0c; API 网关(API Gataway)。

API 网关

下面是百度上针对于 API 网关的介绍&＃xff1a;

API网关是一个服务器&＃xff0c;是系统的唯一入口。从面向对象设计的角度看&＃xff0c;它与外观模式类似。API网关封装了系统内部架构&＃xff0c;为每个客户端提供一个定制的API。它可能还具有其它职责&＃xff0c;如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。

API网关方式的核心要点是&＃xff0c;所有的客户端和消费端都通过统一的网关接入微服务&＃xff0c;在网关层处理所有的非业务功能。通常&＃xff0c;网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。

Chris Richardson 在他的博客中把 API 网关划分为以下两种&＃xff1a;

单节点 API 网关

Backends for frontends 网关

单节点网关

单节点的 API网关为每个客户端提供不同的API&＃xff0c;而不是提供一种万能风格的API。

这个网关和微软在 eShop 项目中推荐的网关是一致的。

更多详细信息我会在下文进行说明。

Backends for frontends 网关

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

落地方案

我一直在寻思一种最佳的 API 网关的落地方案&＃xff0c;以上两种 API 网关有什么问题呢&＃xff1f;

通常情况下&＃xff0c; API 网关要做很多工作&＃xff0c;它作为一个系统的后端总入口&＃xff0c;承载着所有服务的组合路由转换等工作&＃xff0c;除此之外&＃xff0c;我们一般也会把安全&＃xff0c;限流&＃xff0c;缓存&＃xff0c;日志&＃xff0c;监控&＃xff0c;重试&＃xff0c;熔断等放到 API 网关来做&＃xff0c;那么可以试想在高并发的情况下&＃xff0c;这里可能会出现一个性能瓶颈。

另外&＃xff0c;如果没有开源项目的支撑前提下&＃xff0c;自己来做这样一套东西&＃xff0c;是非常大的一个工作量&＃xff0c;而且还要做 API 网关本身的高可用等&＃xff0c;如果一旦做不好&＃xff0c;有可能最先挂掉的不是你的其他服务&＃xff0c;而就是这个API网关。

这个时候&＃xff0c;通常我们会去找一些开源的 API 网关项目&＃xff0c;博主已经给你找好了&＃xff0c;目前社区的关于 API Gataway 的项目有以下这些&＃xff1a;

Tyk&＃xff1a;Tyk是一个开放源码的API网关&＃xff0c;它是快速、可扩展和现代的。Tyk提供了一个API管理平台&＃xff0c;其中包括API网关、API分析、开发人员门户和API管理面板。Try 是一个基于Go实现的网关服务。

Kong&＃xff1a;Kong是一个可扩展的开放源码API Layer(也称为API网关或API中间件)。Kong 在任何RESTful API的前面运行&＃xff0c;通过插件扩展&＃xff0c;它提供了超越核心平台的额外功能和服务。

Orange&＃xff1a;和Kong类似也是基于OpenResty的一个API网关程序&＃xff0c;是由国人开发的&＃xff0c;学姐也是贡献者之一。

Netflix zuul&＃xff1a;Zuul是一种提供动态路由、监视、弹性、安全性等功能的边缘服务。Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。

apiaxle: Nodejs 实现的一个 API 网关。

api-umbrella: Ruby 实现的一个 API 网关。

我们来说说上面的这些开源项目适不适合作为 API 网关来供我们使用。

拿单节点网关来说&＃xff0c;这种网关相当于是处于 Web 层和 Service 之间&＃xff0c;用来聚合服务的&＃xff1f;注意&＃xff0c;我们需要的是聚合服务&＃xff0c;而以上这些开源项目都不具备这个功能&＃xff0c;我说的聚合具体指的是开箱即用。我们要想使用这些服务需要来自己对API网关过一些扩展或者是开发一些插件&＃xff0c;这个时候问题就来了。扩展Tyk我需要会Go语言&＃xff0c;扩展Kong我需要会写lua脚本&＃xff0c;使用 zuul 还得会Java&＃xff0c;这对于开发人员来说是不太现实的&＃xff0c;那么这个时候怎么办&＃xff1f;

有些同学可能会说 ASP.NET Core 可以使用 Ocelot&＃xff0c;说得没错&＃xff0c;我们可以通过引入Ocelot来处理API聚合服务这一块的业务&＃xff0c;但是&＃xff0c;这中间有一个问题&＃xff0c;就像我在上面说的一样&＃xff0c;这很容易造成性能问题&＃xff0c;另外一方面&＃xff0c;Ocelot的功能相比上面的那些开源项目来说功能要弱很多&＃xff0c;具体体现在哪些方面呢&＃xff1f;

除了最重要的高性能的IO模型和集群方案外&＃xff0c; 比如会经常使用的 Dashboard 功能&＃xff0c;这个对于运维来说是非常重要的&＃xff0c;另外还有日志&＃xff0c;监控&＃xff0c;安全&＃xff0c;服务发现&＃xff0c;版本控制等。

但是上面的这些 API 网关缺少什么功能呢&＃xff1f; 比如超时&＃xff0c;熔断&＃xff0c;重试&＃xff0c;聚合查询等。

注意&＃xff1a;以下内容的这些想法全是我个人对于 API 网关的理解而诞生的&＃xff0c;如有错误还请指正。

聪明的同学可能想出来了&＃xff0c;怎么办呢&＃xff1f; 我们可以充分来结合两者的优势来在我们的 ASP.NET Core 应用程序中实现一个“双重网关”。

下面是我画的一个 API 网关在微服务架构中的一个作用图&＃xff1a;

应该大部分同学都可以看懂&＃xff0c;我就简单解释一下。

OpenResty Api Gateway

从左至右 HTTP 请求先由DNS在拿到第一手流量后负载均衡到基于 OpenResty 的 API Gataway 网关集群&＃xff0c;在这个流程我们可以使用像 Kong,Orage,Tyk 这些开源的支持高并发高访问量 API 网关程序在做第一层流量的防护&＃xff0c;在这一级我们可以做一些像身份认证&＃xff0c;安全&＃xff0c;监控&＃xff0c;日志&＃xff0c;流控等策略。除了这些我们还可以做一些服务的发现和注册(这个要看不同网关的支持程度)&＃xff0c;接口的版本控制&＃xff0c;路由重写等。

Aggr Api Gateway

然后再由这些 API 网关把请求再负载到不同的 Aggr Api Gateway&＃xff0c;在这里我们做聚合服务这个操作&＃xff0c;具体体现也就是图中的黄色区域是需要由各个语言的开发人员来需要写代码实现的。具体流程也就是我们可以引入像 Ocelot 这种和语言相关的 API 网关开源项目&＃xff0c;然后通过 NuGet 包引入之后通过 Json配置&＃43;聚合代码的方式来整合后端的各个微服务提供聚合查询等操作。这期间对于有需求的接口&＃xff0c;我们可以应用超时&＃xff0c;缓存&＃xff0c;熔断&＃xff0c;重试等策略。

从 Aggr Api Gateway 到后端微服务集群这中间就属于内部的通讯了&＃xff0c;我们可以使用对内部友好的通讯协议比如 gRPC 或者 AMQP 等&＃xff0c;然后进行 RPC调用提高通讯性能。

注意&＃xff1a;Aggr Api Gateway 这个网关对于一些接口来说的话并不是必须的&＃xff0c;也可以由后端微服务直接提供REST API给第一层网关使用。

以上&＃xff0c;就是我理解的 API 网关在整个微服务架构中的一个地位&＃xff0c;承上启下&＃xff0c;还是非常的重要。

我们知道&＃xff0c;在 API 网关的后端是微服务的集群&＃xff0c;那么除了聚合查询之外有时候我们有时候需要做一些跨不同服务的操作&＃xff0c;比如一次电商系统的下单操作&＃xff0c;可以会设计到产品、价格、库存等一系列跨微服务操作&＃xff0c;在中间我们一般会采用集成事件(EventBus)来进行通讯这种解决方案&＃xff0c;在这个过程中我们不仅仅的是需要通讯&＃xff0c;那么这些操作还需要保证事务一致性&＃xff0c;而一般分布式系统中的事务我们追求的是最终一致性。

如果是在 .NET Core 中&＃xff0c;我们可以使用博主开源的 EventBus &＃43; 分布式事务 解决方案 CAP。

有关分布式事务可以查看这篇文章。