关注
HarmonyOS技术社区
，回复
【鸿蒙】
送
价值
399元
的鸿蒙
开发板套件
（即将开奖，赶快参与哦！）
，还可以
免费下载
鸿蒙
入门资料
！
👇
扫码
立刻关注
👇
专注开源技术，共建鸿蒙生态
最近看到了一篇 API 网关的文章，介绍了其三种角色：API 管理、集群入口控制、API 网关模式，最后还讲了与服务网格的关系，通过此文可以更全面的理解 API 网关的作用。
图片来自 Pexels
这些年来，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 Management Gateway
基于 API 网关的 API 管理软件示例：
-
Google Cloud Apigee
-
Red Hat 3Scale
-
Mulesoft
-
Kong
在这个层级，我们考虑的是 API（如上定义）是如何最好地管理和允许对其进行访问。
我们没有考虑其他角度，例如服务器、主机、端口、容器甚至服务（这是另一个很难定义清楚的词）。
API 管理（以及它们相应的网关），通常会被严格把控，并作为一种“平台组件”、“一体化组件”和 API 的其他基础组件一起生效。
需要注意的一件事：
我们要小心千万别让任何业务逻辑进入这一层。
如前一段所述，API 管理是共享的基础架构，但是由于我们的 API 流量经过了它，因此它倾向于重新创建“大包大揽的全能型”（认为是企业服务总线）网关，这会导致我们必须与之协调来更改我们的服务。
从理论上讲，这听起来不错。实际上，这最终可能成为组织的瓶颈。
有关更多信息，请参见这篇文章：具有 ESB，API 管理和 Now…Service Mesh 的应用程序网络功能？
https://blog.christianposta.com/microservices/application-network-functions-with-esbs-api-management-and-now-service-mesh/
为了构建和实现 API，我们将重点放在代码、数据、生产力框架等方面。
但是，要想使这些事情中的任何一个产生价值，就必须对其进行测试，部署到生产中并进行监控。
当我们开始部署到云平台时，我们开始考虑部署、容器、服务、主机、端口等，并构建可在此环境中运行的应用程序。
我们可能正在设计工作流（CI）和管道（CD），以利用云平台快速迁移、更改的特点，将其快速展示在客户面前等等。
在这种环境中，我们可能会构建和维护多个集群来承载我们的应用程序，并且需要某种方式直接来访问这些集群中的应用程序和服务。
