谈谈微服务中的 API 网关(API Gateway) (2)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

谈谈微服务中的 API 网关(API Gateway)

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

OpenResty Api Gateway

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

Aggr Api Gateway

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

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

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

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

广告

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

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

GitHub:https://github.com/dotnetcore/CAP

CAP 介绍:

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

感兴趣的同学可以给CAP一个 Star 以表支持,偷偷告诉你 Ocelot的作者也Star了哦。 :)

总结

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zyypwd.html