vlambda博客
学习文章列表

你正在用的API网关,真的起到了它该有的作用?

回复”666“获取面试宝典

最近看到一篇翻译一篇API网关的文章,介绍了其三种角色:API管理、集群入口控制、API网关模式,最后还讲了与服务网格的关系,通过此文可以更全面的理解API网关的作用。

原文 API Gateways are going through an identity crisis

这些年来,API网关正在经历一些有关他们是否真的起到作用的质疑。

  • 它们是否集中、共享了资源,从而促进了API对于外部调用的管理?
  • 它们是否集群入口(ingress)的控制器,从而可以严格管理用户进入或离开集群吗?
  • 或者它们是否某种API的链接器,从而让API在指定的客户端上更方便使用?
  • 当然,房间里的大象和最常见的问题是:“服务网格会使API网关过时吗?

房间里的大象:英语习语,指的是一些虽然显而易见,但却由于可能造成尴尬、争执、触及敏感或禁忌等原因被人刻意忽视的事情。

一些背景

随着技术发展日新月异,整个行业通过技术和架构模式的推陈出新进行快速洗牌,如果你说“所有这些都使我头大”,也可以理解。在本文中,我希望总结出“ API网关”的不同身份,阐明日常使用中,哪些群体可以使用API网关(或许一部人正碰到并在尝试解决这个问题),并再次强调那些基本原则。理想情况下,在本文结束时,您将更好地了解API基础架构在不同层级、对不同对象的作用,同时明白如何从每个层级获得最大价值。

在深入探讨之前,让我们先明确API一词的含义。

我对API的定义:

一个有着明确定义并且最终目的清晰的接口,通过网络调用,使软件开发人员能够方便安全的对目标数据和功能进行程序访问。

这些接口抽象了实现它们的技术架构细节。对于这些设计好了的网络节点,我们希望获得一定程度的使用指引、以及成熟的向下兼容性。

相反,如果仅仅是可以通过网络与另一软件进行交互,并不一定意味着那些远程节点就是符合此定义的API。许多系统相互交互,但是这些交互比较随意,并且因为系统之间耦合性和其他一些因素的关系,往往在即时性方面会受到影响。

我们创建API来为业务的各个部分提供完善的抽象服务,以实现新的业务功能以及偶然发现一两个创新之举。

在谈论API网关时,首先要提到的是API管理。

API管理

许多人从API管理的角度考虑API网关。这是合理的。但是,让我们先快速看一下此类网关的功能。

通过API 管理,我们尝试去解决“如何控制给其他人使用当前有的API”的问题,例如,如何跟踪谁在使用这些API、对谁能使用这些API进行权限控制、建立一套完善的管理措施进行使用授权和认证,同时创建一个服务目录,可以在设计时使用,提升对API的理解并为以后的有效治理奠定基础。

我们想解决“我们有一些优秀的API,并且我们希望别人来使用这些API,但是希望他们按照我们的规则去使用”的问题。

API管理当然也起到一些很好的用处,例如,它允许用户(潜在的API使用者)进行自助服务,签署不同的API使用计划(请考虑:在给定时间范围内,在指定价格点上,每个端点每个用户的调用次数)。有能力完成这些管理功能的基础架构就是网关(API流量所经过的)。在网关层,我们可以执行身份验证,速率限制,指标收集,其它策略执行等一系列操作。

你正在用的API网关,真的起到了它该有的作用?

API Management Gateway

基于API网关的API管理软件示例:

  • Google Cloud Apigee(https://links.jianshu.com/go?to=https%3A%2F%2Fapigee.com%2Fapi-management%2F%23%2Fhomepage)
  • Red Hat 3Scale(https://links.jianshu.com/go?to=https%3A%2F%2Fwww.3scale.net%2F)
  • Mulesoft(https://links.jianshu.com/go?to=https%3A%2F%2Fwww.mulesoft.com%2F)
  • Kong(https://links.jianshu.com/go?to=https%3A%2F%2Fkonghq.com%2F)

在这个层级,我们考虑的是API(如上定义)是如何最好地管理和允许对其进行访问。我们没有考虑其他角度,例如服务器、主机、端口、容器甚至服务(这是另一个很难定义清楚的词!)。

API管理(以及它们相应的网关),通常会被严格把控,并作为一种“平台组件”、“一体化组件”和API的其他基础组件一起生效。

需要注意的一件事:我们要小心千万别让任何业务逻辑进入这一层。如前一段所述,API管理是共享的基础架构,但是由于我们的API流量经过了它,因此它倾向于重新创建“大包大揽的全能型”(认为是企业服务总线)网关,这会导致我们必须与之协调来更改我们的服务。从理论上讲,这听起来不错。实际上,这最终可能成为组织的瓶颈。有关更多信息,请参见这篇文章:具有ESB,API管理和Now…Service Mesh的应用程序网络功能?(https://links.jianshu.com/go?to=http%3A%2F%2Fblog.christianposta.com%2Fmicroservices%2Fapplication-network-functions-with-esbs-api-management-and-now-service-mesh%2F)

集群入口

为了构建和实现API,我们将重点放在代码、数据、生产力框架等方面。但是,要想使这些事情中的任何一个产生价值,就必须对其进行测试,部署到生产中并进行监控。当我们开始部署到云平台时,我们开始考虑部署、容器、服务、主机、端口等,并构建可在此环境中运行的应用程序。我们可能正在设计工作流(CI)和管道(CD),以利用云平台快速迁移、更改的特点,将其快速展示在客户面前等等。

在这种环境中,我们可能会构建和维护多个集群来承载我们的应用程序,并且需要某种方式直接来访问这些集群中的应用程序和服务。以Kubernetes为例思考。我们可能会通过一个Kubernetes 入口控制器来访问Kubernetes集群(集群中的其它所有内容都无法从外部访问)。这样,我们就可以通过定义明确的规则(例如域/虚拟主机、端口、协议等),严格控制哪些内容可以进入(甚至离开)我们的集群。

在这个层级,我们可能希望某种“入口网关”成为允许请求和消息进入集群的流量监控人。在这个层级,思考更多的是“我的集群中有此服务,我需要集群外的人能够调用它”。这可能是服务(公开API)、现有的整体组件、gRPC服务,缓存、消息队列、数据库等。有些人选择将其称为API网关,而且实际上可能会做比控制流量进/出而言更多的事情,但重点是这个层级的问题是属于集群操作级别的。

你正在用的API网关,真的起到了它该有的作用?

Cluster Ingress Gateway

这些类型的入口实现的示例包括:Envoy Proxy 及其基础上的项目包括:

  • Datawire Ambassador(https://links.jianshu.com/go?to=https%3A%2F%2Fwww.getambassador.io%2F)
  • Solo.io Gloo(https://links.jianshu.com/go?to=https%3A%2F%2Fgloo.solo.io%2F)
  • Heptio Contour(https://links.jianshu.com/go?to=https%3A%2F%2Fgithub.com%2Fheptio%2Fcontour)

基于其他反向代理/负载均衡器构建的其它组件:

  • HAProxy(https://links.jianshu.com/go?to=http%3A%2F%2Fwww.haproxy.org%2F)
  • OpenShift’s Router (based on HAProxy)(https://links.jianshu.com/go?to=https%3A%2F%2Fdocs.openshift.com%2Fcontainer-platform%2F3.9%2Finstall_config%2Frouter%2Findex.html)
  • NGINX(https://links.jianshu.com/go?to=https%3A%2F%2Fgithub.com%2Fkubernetes%2Fingress-nginx)
  • Traefik(https://links.jianshu.com/go?to=https%3A%2F%2Ftraefik.io%2F)
  • Kong(https://links.jianshu.com/go?to=https%3A%2F%2Fgithub.com%2FKong%2Fkubernetes-ingress-controller)

此层级的集群入口控制器由平台组件操作,但是,这部分基础架构通常与更加分布式、自助服务的工作流相关联(正如您对云平台所期望的那样)。参见The “GitOps” workflow as described by the good folks at Weaveworks(https://links.jianshu.com/go?to=https%3A%2F%2Fwww.weave.works%2Fblog%2Fgitops-operations-by-pull-request)

API网关模式

关于“ API网关”一词的另一种扩展是我在听到该术语时通常想到的,它是与API网关模式最相似的。Chris Richardson在其“微服务模式”一书第8章很好地介绍了这种用法。我强烈建议您将此书用于此模式和其他微服务模式学习资料。可在他的microservices.io网站进行快速浏览,API Gatway Pattern(https://links.jianshu.com/go?to=https%3A%2F%2Fmicroservices.io%2Fpatterns%2Fapigateway.html)。简而言之,API网关模式是针对不同类别的使用者来优化API的使用。这个优化涉及一个API间接访问。您可能会听到另一个代表API网关模式的术语是“前端的后端”,其中“前端”可以是字符终端(UI)、移动客户端、IoT客户端甚至其它服务/应用程序开发人员。

在API网关模式中,我们明显简化了对一组API的调用,以模拟针对特定用户、客户端或使用者的“应用程序”内聚API。回想一下,当我们使用微服务构建系统时,“应用程序”的概念就消失了。API网关模式有助于恢复此概念。这里的关键是API网关,一旦实现,它将成为客户端和应用程序的API,并负责与任何后端API和其他应用程序网络节点(不满足上述API定义的节点)进行通信交互。

与上一节中的入口控制器不同,此API网关更接近开发人员的视角,而较少关注哪些端口或服务会公开以供集群外使用。此“ API网关”也不同于我们管理现有API的API管理视角。此API网关将对后端的调用聚合在一起,这可能会公开API,但也可能会涉及到一些API描述较少的东西,例如对旧系统的RPC调用,使用不符合“ REST”的协议的调用(如通过HTTP但不使用JSON),gRPC,SOAP,GraphQL、websockets和消息队列。这种类型的网关也可用来进行消息级转换、复杂的路由、网络弹性/回退以及响应的聚合。

如果您熟悉REST API的Richardson Maturity模型,就会发现相比Level 1–3,实现了API网关模式的API网关集成了更多的Level 0请求(及其之间的所有内容)。

你正在用的API网关,真的起到了它该有的作用?

https://martinfowler.com/articles/richardsonMaturityModel.html

这些类型的网关实现仍需要解决速率限制、身份验证/授权、电路断路、度量收集、流量路由等问题。这些类型的网关可以在集群边缘用作集群入口控制器,也可以在集群内部用作应用程序网关。

你正在用的API网关,真的起到了它该有的作用?

API Gateway Pattern

此类API网关的示例包括:

  • Spring Cloud Gateway(https://links.jianshu.com/go?to=http%3A%2F%2Fspring.io%2Fprojects%2Fspring-cloud-gateway)
  • Solo.io Gloo(https://links.jianshu.com/go?to=https%3A%2F%2Fgloo.solo.io%2F)
  • Netflix Zuul(https://links.jianshu.com/go?to=https%3A%2F%2Fgithub.com%2FNetflix%2Fzuul)
  • IBM-Strongloop Loopback/Microgateway(https://links.jianshu.com/go?to=https%3A%2F%2Fstrongloop.com%2F)

也可以使用更通用的编程或集成语言/框架(例如:

  • Apache Camel(https://links.jianshu.com/go?to=https%3A%2F%2Fgithub.com%2Fapache%2Fcamel)
  • Spring Integration(https://links.jianshu.com/go?to=https%3A%2F%2Fspring.io%2Fprojects%2Fspring-integration)
  • Ballerina.io(https://links.jianshu.com/go?to=https%3A%2F%2Fballerina.io%2F)
  • Eclipse Vert.x(https://links.jianshu.com/go?to=https%3A%2F%2Fvertx.io%2F)
  • NodeJS(https://links.jianshu.com/go?to=https%3A%2F%2Fnodejs.org%2Fen%2F)

由于这种类型的API网关与应用和服务的开发紧密相关,因此我们希望开发人员能够参与帮助指定API网关公开的API,了解所涉及的任何聚合逻辑以及能够快速测试和更改此API基础架构的能力。我们还希望运维人员或工程师对API网关的安全性、弹性和可观察性配置有一些想法。这种层级的基础架构还必须适应不断发展的、按需的、自主服务开发人员的工作流。可以通过查看GitOps模型获取更多这方面信息。

进入服务网格(Service Mesh)

在云基础架构上运行服务架构的一部分难点是,如何在网络中构建正确级别的可观察性和控制。在解决此问题的先前迭代中,我们使用了应用程序库和一些专业的开发人员治理来实现此目的。但是,在大规模和多种开发语言环境下,服务网格技术的出现提供了更好的解决方案。服务网格通过透明地实现为平台及其组成服务带来以下功能:

  • 服务到服务(即东西向流量)的弹性
  • 安全性包括最终用户身份验证、相互TLS、服务到服务RBAC / ABAC
  • 黑盒服务的可观察性(专注于网络通信),例如请求/秒、请求延迟、请求失败、熔断事件、分布式跟踪等
  • 服务到服务速率限制,配额执行等

精明的读者会认识到,API网关和服务网格在功能上似乎有所重叠。服务网格的目的是通过在L7透明地解决所有服务/应用程序的这些问题。换句话说,服务网格希望融合到服务中(实际上它的代码并没有嵌入到服务中)。另一方面,API网关位于服务网格之上,和应用程序一起(L8?)。服务网格为服务、主机、端口、协议等(东西向流量)之间的请求流带来了价值。它们还可以提供基本的集群入口功能,以将某些此功能引入南北向。但是,这不应与API网关可以带来北/南流量的功能相混淆。(一个在集群的南北向和一个是在一组应用程序的南北向)

服务网格和API网关在某些方面在功能上重叠,但是在它们在不同层面互补,分别负责解决不同的问题。理想的解决方案是将每个组件(API管理、API网关、服务网格)合适的安置到您的解决方案中,并根据需要在各组件间建立良好的边界(或在不需要时排除它们)。同样重要的是找到适合的办法去分布式的处理这些组件,给到相应的开发人员和运营工作流。即使这些不同组件的术语和标识存在混淆,我们也应该依靠基本原理,并了解这些组件在我们的体系结构中带来的价值,从而来确定它们如何独立存在和互补并存。

你正在用的API网关,真的起到了它该有的作用?

来源 | https://urlify.cn/ZfyyIv



  
    
    
  
最近面试BAT,整理一份面试资料 Java面试BAT通关手册》 ,覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。
明天见(。・ω・。)ノ♡