最近看到一篇关于API网关的文章，介绍了它的三个作用：API管理、集群访问控制、API网关模式，最后说到与服务网格的关系。通过这篇文章，你可以更全面的了解API网关的作用。ImageviaPexels多年来，API网关一直在质疑它们是否真的有效：它们是否集中和共享资源，从而方便对外调用的API管理？是不是集群入口控制器，从而可以严格管理用户进出集群？或者它们是某种API的链接器，以便在指定的客户端上更方便地使用API？当然，房间里的大象和最常见的问题是：“服务网格会让API网关过时吗？房间里的大象：一个英语习语，指的是一些显而易见但由于可能导致尴尬、争论的原因而被故意忽略的事物,触摸敏感,或禁忌.一些背景随着技术的快速发展,整个行业正在通过新技术和架构模型的引入进行快速洗牌.如果说“这些都让我头晕”是可以理解的.在这篇文章，我希望总结一下“API网关”的不同身份，明确哪些群体可以在日常使用中使用API??网关（也许有人正在遇到并试图解决这个问题），并再次强调那些基本原则。理想情况下，由读完本文，您将更加深入地了解API基础架构在不同级别和针对不同对象的作用，并了解如何从每个级别中获取最大价值埃尔。在深入探讨之前，让我们先澄清一下API这个词的含义。我对API的定义：Apersonwith定义明确的接口，具有明确的最终目的，使软件开发人员能够方便、安全地通过网络调用编程访问目标数据和功能。这些接口抽象了其技术架构的细节。对于这些设计好的网络节点，我们希望获得一定程度的使用指导和成熟的向后兼容。相反，如果只能通过网络与另一个软件进行交互，并不一定意味着那些远程节点就是满足这个定义的API。很多系统交互Interaction，但是这些交互是比较随意的，而且因为系统之间的耦合等因素，往往会在即时性上受到影响。我们创建API来为业务的各个部分提供完整的抽象服务，以实现新的业务功能，并偶然发现一两个创新。谈到API网关，首先要提到的是API管理。API管理许多人从API管理的角度来考虑API网关。这是有道理的。但首先，让我们快速了解一下此类网关的功能。通过API管理，我们试图解决“如何控制其他人使用当前API”的问题。例如，如何跟踪谁在使用这些API，控制谁可以使用这些API，建立一整套授权和认证的管理措施，创建一个可以在设计时使用的服务目录，以提高对API的理解和为今后有效治理奠定基础。我们要解决“我们有一些很棒的AP??I，我们希望别人使用它们，但我们希望他们按照我们的规则使用它们”的问题。API管理也有一些很好的用途，例如，它允许用户（潜在的API消费者）自助服务，注册不同的API使用计划（想想：在给定的时间范围内，在指定的价格点，调用次数每个用户每个端点）。能够执行这些管理功能的基础设施是网关（API流量通过）。在网关层，我们可以执行一系列操作，例如身份验证、速率限制、指标收集和其他策略执行。API管理网关基于API网关的API管理软件示例：GoogleCloudApigeeRedHat3ScaleMulesoftKong在这个级别，我们考虑如何最好地管理API（如上定义）并允许访问它。我们没有考虑其他角度，例如服务器、主机、端口、容器甚至服务（另一个很难定义的词）。API管理（及其对应的网关）通常受到严格控制，作为API的“平台组件”、“集成组件”等基础组件。有一点需要注意：我们必须小心不要让任何业务逻辑进入这一层。如前一段所述，API管理是共享基础设施，但由于我们的API流量通过它，它往往会重新创建“一体化”（想想企业服务总线）网关，这将导致我们必须与它改变我们的服务。从理论上讲，这听起来不错。事实上，这最终可能成为组织的瓶颈。有关详细信息，请参阅此帖子：具有ESB、API管理和现在……服务网格的应用程序网络功能？https://blog.christianposta.com/microservices/application-network-functions-with-esbs-api-management-and-now-service-mesh/clusterentry为了构建和实施API，我们专注于代码、数据、生产力框架等等。但是要使这些东西中的任何一个有价值，都必须对其进行测试、部署到生产环境并进行监控。当我们开始部署到云端时，我们开始思考部署、容器、服务、主机、端口等，并构建可以在这个环境中运行的应用程序。我们可能在设计工作流（CI）和流水线（CD），利用云平台快速迁移、变化、快速呈现在客户面前等特性，在这个环境下，我们可能会构建和维护多个集群来托管我们的应用程序，并且需要某种方式来直接访问这些集群中的应用程序和服务。以Kubernetes为例。我们可以通过Kubernetes入口控制器访问Kubernetes集群（集群中的其他所有内容都无法从外部访问）。这样，我们就可以通过定义明确的规则（例如域/虚拟主机、端口、协议等）来严格控制什么可以进入（甚至离开）我们的集群。在这个级别，我们可能希望某种“入口网关”成为允许请求和消息进入集群的流量观察器。在这个层面上，思考更多的是“我的集群中有这个服务，我需要集群外的人才能调用它”。这可能是一个服务（暴露一个API）、一个现有的整体、一个gRPC服务、一个缓存、一个消息队列、一个数据库等。有些人选择称它为API网关，它实际上可能做的不仅仅是控制进/出流量，但关键是这种关注级别是在集群操作级别。ClusterIngressGateway这些类型的入口实现示例包括：EnvoyProxy和基于它的项目包括：DatawireAmbassadorSolo.ioGlooHeptioContour构建在其他反向代理/负载均衡器之上的其他组件：HAProxyOpenShift的RouterNginxTraefik这个级别的Kong集群入口控制器由平台组件操作，然而，这部分基础设施通常与更分布式的自助服务工作流相关联（正如您对云平台的期望）。请参阅Weaveworks的优秀人员所描述的“GitOps”工作流程：https://www.weave.works/blog/gitops-operations-by-pull-requestAPI网关模式“API网关”一词的另一个扩展是当我听到这个术语时，我通常会想到什么，它是与API网关模式最相似的一个。ChrisRichardson在他的《微服务模式》一书的第8章中很好地介绍了这种用法。简而言之，API网关模式是针对不同类别的消费者优化API的使用。此优化涉及API间接寻址。您可能听到的另一个提及API网关模式的术语是“前端的后端”，其中“前端”可以是字符终端(UI)、移动客户端、IoT客户端甚至其他服务/应用程序开发人员。在API网关模式中，我们显着简化了对一组API的调用，以模拟特定用户、客户或消费者的“应用程序”内聚API。回想一下，当我们使用微服务构建系统时，“应用程序”的概念就消失了。API网关模式有助于还原这个概念。这里的关键是API网关，它一旦实现，就成为客户端和应用程序的API，负责与任何后端API和其他应用程序网络节点（不符合上述API定义的节点）进行通信。与上一节中的ingresscontroller不同，这个APIGateway更贴近开发者的视角，不太关心暴露哪些端口或服务在集群外使用。这个“API网关”也不同于我们管理现有API的API管理视角。此API网关将对后端的调用聚合在一起。这可能会公开API，但它也可能涉及API描述性较低的内容，例如对遗留系统的RPC调用、使用不符合“REST”协议的调用（例如通过HTTP而不是JSON）、gRPC、SOAP、GraphQL、WebSockets和消息队列。这种类型的网关还可用于消息级转换、复杂路由、网络弹性/回退和响应聚合。如果您熟悉RESTAPI的Richardson成熟度模型，您会发现实施API网关模式的API网关集成了比1-3级更多的0级请求（以及介于两者之间的所有请求）。这些类型的网关实现仍然需要解决速率限制、身份验证/授权、熔断、指标收集、流量路由等问题。这些类型的网关可以用作集群边缘的集群入口控制器，或集群内部的应用程序网关。API网关模式此类API网关的示例包括：SpringCloudGatewayNetflixZuulIBM-StrongloopLoopback/Microgateway还可以使用更通用的编程或集成语言/框架，例如：ApacheCamelSpringIntegrationBallerina.ioEclipseVert.xNodeJSDueThisAPIGateway的类型与应用和服务的发展密切相关，所以我们希望开发者能够参与帮助指定APIGateway暴露的API，了解涉及的任何聚合逻辑，并能够快速测试和更改此API基础结构。我们还希望运维人员或工程师对API网关的安全性、弹性和可观察性的配置有一些想法。这一级别的基础架构还必须适应不断发展的、按需的、自助服务的开发人员工作流程。您可以通过查看GitOps模型了解更多相关信息。在云基础设施上运行服务架构的部分挑战是在网络中构建适当级别的可观察性和控制。在之前解决这个问题的迭代中，我们使用了一个应用程序库和一些专业的开发人员治理来实现这一点。然而，在大规模、多语言的开发环境中，服务网格技术的出现提供了更好的解决方案。服务网格通过透明实现为平台及其组成服务带来以下功能：服务到服务（即东西向流量）弹性。安全性包括最终用户身份验证、双向TLS、服务到服务RBAC/ABAC。黑盒服务的可观察性（专注于网络通信），例如请求/秒、请求延迟、请求失败、断路器事件、分布式跟踪等。服务到服务的速率限制、配额执行等。精明的读者会认识到API网关和服务网格似乎在功能上有所重叠。服务网格的目的是在L7透明地为所有服务/应用程序解决这些问题。换句话说，服务网格想要集成到服务中（它的代码实际上并没有嵌入到服务中）。另一方面，API网关与应用程序（L8？）一起位于服务网格之上。服务网格为服务、主机、端口、协议等（东西向流量）之间的请求流带来价值。他们还可以提供基本的集群入口功能，将其中的一些功能带入南北方向。但是，这不应与API网关带来南北流量的能力相混淆。（一个南北到一个集群，一个南北到一组应用程序）ServiceMeshes和APIGateways在功能上有一些重叠，但它们在不同的层面上相互补充，各自负责解决不同的问题。理想的解决方案是将每个组件（API管理、API网关、服务网格）适当地放入您的解决方案中，并根据需要在组件之间创建良好的边界（或在不需要时将它们排除）。找到一种合适的方式将这些组件的处理分配给相应的开发人员和运营工作流也很重要。即使对这些不同组件的术语和标识存在混淆，我们也应该依靠基础知识并了解这些组件为我们的架构带来的价值，以确定它们如何独立存在并相互补充。作者：蚊子松鼠译者：陶家龙来源：jianshu.com/p/9fab0982c6bb原文：https://medium.com/solo-io/api-gateways-are-going-through-an-identity-crisis-d1d833a313d7
