当前位置:首页 > Windows程序 > 正文

具体流程也就是我们可以引入像 Ocelot 这种和语言相关的 API 网关开源项目

2024-03-31 Windows程序

我们知道在微处事架构气势派头中,一个大应用被拆分成为了多个小的处事系统供给出来,这些小的系统他们可以自成体系,也就是说这些小系统可以拥有本身的数据库,框架甚至语言等,这些小系统凡是以供给 Rest Api 气势派头的接口来被 H5, Android, IOS 以及第三方应用措施挪用。

但是在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 网关项目,博主已经给你找好了,目前社区的关于 API Gataway 的项目有以下这些:

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 网关来供我们使用。

温馨提示: 本文由Jm博客推荐,转载请保留链接: https://www.jmwww.net/file/35830.html

Jm-杰米博客Jamie
草根站长的技术交流乐园!IT不会不要紧快来好好学习吧!
  • 20786文章总数
  • 7494590访问次数
  • 建站天数
  • 友情链接