大公司为什么都有API网关?没你想的那么简单!

2024-09-02 09:58
文章标签 简单 api 网关 公司

本文主要是介绍大公司为什么都有API网关?没你想的那么简单!,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

点击上方“朱小厮的博客”,选择“设为星标”

后台回复”加群“获取公众号专属群聊入口

来源:rrd.me/g6eyJ

在这篇文章中将我们一起来探讨当前的API网关的作用。

一、API网关的用处

API网关我的分析中会用到以下三种场景。

1. Open API

企业需要将自身数据、能力等作为开发平台向外开放,通常会以rest的方式向外提供,最好的例子就是淘宝开放平台、腾讯公司的QQ开发平台、微信开放平台。

Open API开放平台必然涉及到客户应用的接入、API权限的管理、调用次数管理等,必然会有一个统一的入口进行管理,这正是API网关可以发挥作用的时候。

2. 微服务网关

微服务的概念最早在2012年提出,在Martin Fowler的大力推广下,微服务在2014年后得到了大力发展。

在微服务架构中,有一个组件可以说是必不可少的,那就是微服务网关,微服务网关处理了负载均衡,缓存,路由,访问控制,服务代理,监控,日志等。API网关在微服务架构中正是以微服务网关的身份存在。

3. API服务管理平台

上述的微服务架构对企业来说有可能实施上是困难的,企业有很多遗留系统,要全部抽取为微服务器改动太大,对企业来说成本太高。

但是由于不同系统间存在大量的API服务互相调用,因此需要对系统间服务调用进行管理,清晰地看到各系统调用关系,对系统间调用进行监控等。

API网关可以解决这些问题,我们可以认为如果没有大规模的实施微服务架构,那么对企业来说微服务网关就是企业的API服务管理平台。

二、API网关在企业整体架构中的地位

一个企业随着信息系统复杂度的提高,必然出现外部合作伙伴应用、企业自身的公网应用、企业内网应用等,在架构上应该将这三种应用区别开,三种应用的安排级别、访问方式也不一样。

因此在我的设计中将这三种应用分别用不同的网关进行API管理,分别是:API网关(OpenAPI合伙伙伴应用)、API网关(内部应用)、API网关(内部公网应用)。

三、企业中在如何应用API网关

1、对于OpenAPI使用的API网关来说,一般合作伙伴要以应用的形式接入到OpenAPI平台,合作伙伴需要到 OpenAPI平台申请应用。

因此在OpenAPI网关之外,需要有一个面向合作伙伴的使用的平台用于合作伙伴,这就要求OpenAPI网关需要提供API给这个用户平台进行访问。

如下架构:

当然如果是在简单的场景下,可能并不需要提供一个面向合作伙伴的门户,只需要由公司的运营人员直接添加合作伙伴应用id/密钥等,这种情况下也就不需要合作伙伴门户子系统。

2、对于内网的API网关,在起到的作用上来说可以认为是微服务网关,也可以认为是内网的API服务治理平台。

当企业将所有的应用使用微服务的架构管理起来,那么API网关就起到了微服务网关的作用。

而当企业只是将系统与系统之间的调用使用rest api的方式进行访问时使用API网关对调用进行管理,那么API网关起到的就是API服务治理的作用。

架构参考如下:

3、对于公司内部公网应用(如APP、公司的网站),如果管理上比较细致,在架构上是可能由独立的API网关来处理这部分内部公网应用,如果想比较简单的处理,也可以是使用面向合作伙伴的API网关。

如果使用独立的API网关,有以下的好处:

  • 面向合作伙伴和面向公司主体业务的优先级不一样,不同的API网关可以做到业务影响的隔离。

  • 内部API使用的管理流程和面向合作伙伴的管理流程可能不一样。

  • 内部的API在功能扩展等方面的需求一般会大于OpenAPI对于功能的要求。

基于以上的分析,如果公司有能力,那么还是建议分开使用合作伙伴OPEN API网关和内部公网应用网关。

四、API网关有哪些竞争方案

1、对于Open API平台的API网关,我分析只能选择API网关作为解决方案,业界没有发现比较好的可以用来作为Open API平台的入口的其他方案。

2、对于作为微服务网关的API网关,业界的选择可以选择的解决方案比较多,也取决于微服务器的实现方案,有一些微服务架构的实现方案是不需要微服务网关的。

  • Service Mesh,这是新兴的基于无API网关的架构,通过在客户端上的代理完成屏蔽网络层的访问,这样达到对应用层最小的改动,当前Service Mesh的产品还正在开发中,并没有非常成熟可直接应用的产品。发展最迅速的产品是Istio。建议大家密切关注相关产品的研发、业务使用进展。

  • 基于duboo架构,在这个架构中通常是不需要网关的,是由客户端直接访问服务提供方,由注册中心向客户端返回服务方的地址。

五、API网关解决方案

私有云开源解决方案如下:

  • Kong kong是基于Nginx+Lua进行二次开发的方案, https://konghq.com/

  • Netflix Zuul,zuul是spring cloud的一个推荐组件, https://github.com/Netflix/zuul

  • orange,这个开源程序是国人开发的, http://orange.sumory.com/

公有云解决方案:

  • Amazon API Gateway, https://aws.amazon.com/cn/api-gateway/

  • 阿里云API网关, https://www.aliyun.com/product/apigateway/

  • 腾讯云API网关, https://cloud.tencent.com/product/apigateway

自开发解决方案:

  • 基于Nginx+Lua+ OpenResty的方案,可以看到Kong,orange都是基于这个方案

  • 基于Netty、非阻塞IO模型。通过网上搜索可以看到国内的宜人贷等一些公司是基于这种方案,是一种成熟的方案。

  • 基于Node.js的方案。这种方案是应用了Node.js天生的非阻塞的特性。

  • 基于java Servlet的方案。zuul基于的就是这种方案,这种方案的效率不高,这也是zuul总是被诟病的原因。

六、企业怎么选择API网关

如果是要选择一款已有的API网关,那么需要从以下几个方面去考虑。

1、性能与可用性

如果一旦采用了API网关,那么API网关就会作为企业应用核心,因此性能和可用性是必须要求的。

从性能上来说,需要让网关增加的时间消耗越短越好,个人觉得需要10ms以下。系统需要采用非阻塞的IO,如epoll,NIO等。

网关和各种依赖的交互也需要是非阻塞的,这样才能保证整体系统的高可用性,如:Node.js的响应式编程和基于java体现的RxJava和Future。网关必须支持集群部署,任务一台服务器的crash都应该不影响整体系统的可用性。多套网关应该支持同一管理平台和同一监控中心。如:一个企业的OpenAPI网关和内部应用的多个系统群的不同的微服务网关可以在同一监控中心进行监控。

2、可扩展性、可维护性

一款产品总有不能满足生产需求的地方,因此需求思考产品在如何进行二次开发和维护,是否方便公司团队接手维护产品。

3、需求匹配度

需要评估各API网关在需求上是否能满足,如:如果是OpenAPI平台需要使用API网关,那么需要看API网关在合作伙伴应用接入、合作伙伴门户集成、访问次数限额等OpenAPI核心需求上去思考产品是否能满足要求。

如果是微服务网关,那么要从微服务的运维、监控、管理等方面去思考产品是否足够强大。

4、是否开源?公司是否有自开发的能力?

现有的开源产品如kong,zuul,orange都有基础的API网关的核心功能,这些开源产品大多离很好的使用有一定的距离。

如:没有提供管理功能的UI界面、监控功能弱小,不支持OpenAPI平台,没有公司运营与运维的功能等。

当然开源产品能获取源代码,如果公司有比较强的研发能力,能hold住这些开源产品,经过二次开发kong、zuul应该还是适应一些公司,不过需求注意以下一些点:

  • kong是基于ngnix+lua的,从公司的角度比较难于找到能去维护这种架构产品的人。需求评估当前公司是否有这个能力去维护这个产品。

  • zuul因为架构的原因在高并发的情况下性能不高,同时需要去基于研究整合开源的适配zuul的监控和管理系统。

  • orange由于没有被大量使用,同时是国内个人在开源,在可持续性和社区资源上不够丰富,出了问题后可能不容易找到人问。

另外kong提供企业版本的API网关,当然也是基于ngnix+lua的,企业版本可以购买他们的技术支持、培训等服务、以及拥有界面的管理、监控等功能。

5、公有云还是私有云

现在的亚马逊、阿里、腾讯云都在提供基础公有云的API网关,当然这些网关的基础功能肯定是没有问题,但是二次开发,扩展功能、监控功能可能就不能满足部分用户的定制需求了。

另外很多企业因为自身信息安全的原因,不能使用外网公有网的API网关服务,这样就只有选择私有云的方案了。

在需求上如果基于公有云的API网关只能做到由内部人员为外网人员申请应用,无法做到定制的合作伙伴门户,这也不适合于部分企业的需求。

如果作为微服务网关,大多数情况下是希望网关服务器和服务提供方服务器是要在内网的,在这里情况下也只有私有云的API网关才能满足需求。

综合上面的分析,基础公有云的API网关只有满足一部分简单客户的需求,对于很多企业来说私有云的API网关才是正确的选择。

想知道更多?描下面的二维码关注我

后台回复”加群“获取公众号专属群聊入口

【精彩推荐】

  • 咱们从头到尾说一次Java垃圾回收

  • Netty、Kafka中的零拷贝技术到底有多牛?

  • go为什么这么快?

  • 面试前,我们要复习多少Redis知识?

  • 《深入理解Java虚拟机》第2版挖的坑终于在第3版中被R大填平了

  • Redis性能问题分析

  • 浅谈CAP和Paxos共识算法

  • 聊一聊Java中的文件锁

  • Kafka为什么这么快?

  • Paxos、Raft不是一致性算法嘛?

  • 聊聊Java的几把JVM级锁

  • 越说越迷糊的CAP

  • 聊一聊Java服务端中的乱象

>>> 字节跳动社招内推入口 <<<

>>> 字节跳动校招内推入口 <<<

朕已阅 

这篇关于大公司为什么都有API网关?没你想的那么简单!的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1129650

相关文章

csu 1446 Problem J Modified LCS (扩展欧几里得算法的简单应用)

这是一道扩展欧几里得算法的简单应用题,这题是在湖南多校训练赛中队友ac的一道题,在比赛之后请教了队友,然后自己把它a掉 这也是自己独自做扩展欧几里得算法的题目 题意:把题意转变下就变成了:求d1*x - d2*y = f2 - f1的解,很明显用exgcd来解 下面介绍一下exgcd的一些知识点:求ax + by = c的解 一、首先求ax + by = gcd(a,b)的解 这个

hdu2289(简单二分)

虽说是简单二分,但是我还是wa死了  题意:已知圆台的体积,求高度 首先要知道圆台体积怎么求:设上下底的半径分别为r1,r2,高为h,V = PI*(r1*r1+r1*r2+r2*r2)*h/3 然后以h进行二分 代码如下: #include<iostream>#include<algorithm>#include<cstring>#include<stack>#includ

usaco 1.3 Prime Cryptarithm(简单哈希表暴搜剪枝)

思路: 1. 用一个 hash[ ] 数组存放输入的数字,令 hash[ tmp ]=1 。 2. 一个自定义函数 check( ) ,检查各位是否为输入的数字。 3. 暴搜。第一行数从 100到999,第二行数从 10到99。 4. 剪枝。 代码: /*ID: who jayLANG: C++TASK: crypt1*/#include<stdio.h>bool h

uva 10387 Billiard(简单几何)

题意是一个球从矩形的中点出发,告诉你小球与矩形两条边的碰撞次数与小球回到原点的时间,求小球出发时的角度和小球的速度。 简单的几何问题,小球每与竖边碰撞一次,向右扩展一个相同的矩形;每与横边碰撞一次,向上扩展一个相同的矩形。 可以发现,扩展矩形的路径和在当前矩形中的每一段路径相同,当小球回到出发点时,一条直线的路径刚好经过最后一个扩展矩形的中心点。 最后扩展的路径和横边竖边恰好组成一个直

poj 1113 凸包+简单几何计算

题意: 给N个平面上的点,现在要在离点外L米处建城墙,使得城墙把所有点都包含进去且城墙的长度最短。 解析: 韬哥出的某次训练赛上A出的第一道计算几何,算是大水题吧。 用convexhull算法把凸包求出来,然后加加减减就A了。 计算见下图: 好久没玩画图了啊好开心。 代码: #include <iostream>#include <cstdio>#inclu

uva 10130 简单背包

题意: 背包和 代码: #include <iostream>#include <cstdio>#include <cstdlib>#include <algorithm>#include <cstring>#include <cmath>#include <stack>#include <vector>#include <queue>#include <map>

【LabVIEW学习篇 - 21】:DLL与API的调用

文章目录 DLL与API调用DLLAPIDLL的调用 DLL与API调用 LabVIEW虽然已经足够强大,但不同的语言在不同领域都有着自己的优势,为了强强联合,LabVIEW提供了强大的外部程序接口能力,包括DLL、CIN(C语言接口)、ActiveX、.NET、MATLAB等等。通过DLL可以使用户很方便地调用C、C++、C#、VB等编程语言写的程序以及windows自带的大

如何更优雅地对接第三方API

如何更优雅地对接第三方API 本文所有示例完整代码地址:https://github.com/yu-linfeng/BlogRepositories/tree/master/repositories/third 我们在日常开发过程中,有不少场景会对接第三方的API,例如第三方账号登录,第三方服务等等。第三方服务会提供API或者SDK,我依稀记得早些年Maven还没那么广泛使用,通常要对接第三方

JAVA用最简单的方法来构建一个高可用的服务端,提升系统可用性

一、什么是提升系统的高可用性 JAVA服务端,顾名思义就是23体验网为用户提供服务的。停工时间,就是不能向用户提供服务的时间。高可用,就是系统具有高度可用性,尽量减少停工时间。如何用最简单的方法来搭建一个高效率可用的服务端JAVA呢? 停工的原因一般有: 服务器故障。例如服务器宕机,服务器网络出现问题,机房或者机架出现问题等;访问量急剧上升,导致服务器压力过大导致访问量急剧上升的原因;时间和

简单的角色响应鼠标而移动

actor类 //处理移动距离,核心是找到角色坐标在世界坐标的向量的投影(x,y,z),然后在世界坐标中合成,此CC是在地面行走,所以Y轴投影始终置为0; using UnityEngine; using System.Collections; public class actor : MonoBehaviour { public float speed=0.1f; CharacterCo