微服务技术解决方案下的，网关，至少需要具备图示基本功能。
- 网关作为单点入口，完成统一的请求管理
- 免去客户端直接对接众多微服务的复杂性，采用单点入口，实现路由转发，从而实现服务调用
- 服务对于整个系统来讲，是不稳定的，那么网关，需要进行限流熔断，保持系统的稳定与分区容错性
- 对于服务调用的链路，网关有职责进行记录，日志监控，保证整个系统，在监控下工作
- 系统可能不仅仅是由自有客户端调用，很多时候，系统开放能力API给外部，因此网关需要安全认证，来保证安全
这些年来，API网关正在经历一些身份危机。
- 它们是否是集中的、共享的资源，从而促进了API对外部实体的暴露与治理？
- 它们是集群入口（ingress）哨兵，从而可以严格控制哪些用户流量进入或离开集群吗？
- 或者它们根据自己拥有的客户端类型，使用某种API结合胶水来更简洁地表达API？
- 当然，房间里的大象和我经常听到的一个问题：“服务网格会使API网关过时吗？
一些背景房间里的大象：英语习语，指的是一些虽然显而易见，但却由于可能造成尴尬、争执、触及敏感或禁忌等原因被人刻意忽视的事情。
随着技术发展日新月异，整个行业通过技术和架构模式进行快速洗牌，如果你说“所有这些都使我头大”，也可以理解。在本文中，我希望总结出“ API网关”的不同身份，阐明公司中的哪些群体可以使用API网关（他们正在尝试解决的问题），并重新关注这些首要原则。理想情况下，在本文结束时，您将更好地了解API基础架构在不同层级、对不同团队的作用，同时明白如何从每个层级获得最大价值。
在深入探讨之前，让我们先明确API一词的含义。
我对API的定义：一个明确定义和目的型接口，通过网络调用，使软件开发人员能够以受控且方便的方式，对组织内的数据和功能进行编程访问。
这些接口抽象了实现它们的技术架构细节。对于这些设计的网络端点，我们希望获得一定程度的文档、使用指南、稳定性和向后兼容性。
相反，仅仅因为我们可以通过网络与另一软件进行通信，并不一定意味着远程端点就是符合此定义的API。许多系统相互通信，但是通信发生更加随意，并在与耦合和其他因素之间进行权衡。
我们创建API来为业务的各个部分提供周全的抽象，以实现新的业务功能以及偶然的创新。
在谈论API网关时，首先要提到的是API管理。
API管理许多人从API管理的角度考虑API网关。这是公平的。但是，让我们快速看一下此类网关的功能。
通过API Management，我们试图解决“何时公开现有的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的应用程序网络功能？
集群入口为了构建和实现API，我们将重点放在代码、数据、生产力框架等方面。但是，要想使这些事情中的任何一个产生价值，就必须对其进行测试，部署到生产中并进行监控。当我们开始部署到云原生平台时，我们开始考虑部署、容器、服务、主机、端口等，并构建可在此环境中运行的应用程序。我们可能正在设计工作流（CI）和管道（CD），以利用云平台快速迁移、更改、将其展示在客户面前等等。
在这种环境中，我们可能会构建和维护多个集群来承载我们的应用程序，并且需要某种方式来访问这些群集中的应用程序和服务。以Kubernetes为例思考。我们可能会通过Kubernetes Ingress来访问Kubernetes集群（集群中的其它所有内容都无法从外部访问）。这样，我们就可以通过定义明确的入口点（例如域/虚拟主机、端口、协议等），严格控制哪些流量可以进入（甚至离开）我们的集群。
在这个级别上，我们可能希望某种“ingress网关”成为允许请求和消息进入群集的流量哨兵。在这个级别上，您的思考更多是“我的集群中有此服务，我需要集群外的人能够调用它”。这可能是服务（公开API）、现有的整体组件、gRPC服务，缓存、消息队列、数据库等。有些人选择将其称为API网关，而且实际上可能会做比流量的入口/出口更多的事情，但重点是这个层级的问题是属于集群操作级别的。
