同时使用 API 网关和服务网格使您能够有效地管理并保护外部和内部流量。API 网关可以控制和保护外部请求，而服务网格可管理微服务之间的内部通信，以提高可扩展性和可靠性。
API 网关与服务网格之间的区别
在当今的 IT 环境中，API 网关和服务网格在管理及保护 API 与微服务方面发挥着不同但互补的作用。API 网关主要负责处理外部流量并管理 API 请求和响应，而服务网格侧重于微服务之间的内部通信，以确保可靠性、安全性和监测能力。这两种技术可以共存并协同工作，共同提供用于在云原生应用程序中实现流量管理、可扩展性和安全性的强大解决方案。
对于 IT 领域的资深从业者而言，经常会遇到一种场景：一项新的技术问世，其功能却与现有方案大同小异。这不免让人心生疑问：“我需要这项技术吗？我不是已经有类似的技术了吗？既然这个新想法与现有解决方案的功能重叠，大家为何对此感到兴奋？”遗憾的是，供应商的炒作加剧了这种混乱。
当前将 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 网关通常是更广泛的 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 网关才能确保它们安全有效地工作。
可扩展性是需要同时使用 API 网关和服务网格的另一个原因。服务网格能够改善服务之间的连接，从而提高微服务的可扩展性。作为 API 和 API 客户端的中央枢纽，API 网关同样能够提升 API 的可扩展性。如果您预计微服务和 API 将出现增长，那么同时采用这两种解决方案无疑是明智的选择。
在企业中同时使用 API 网关和服务网格还可以使开发人员和架构师能够更轻松地进行创新。能够将 API 和 API 客户端与基于微服务的应用程序一起部署是取得成功的秘诀。通过将这两种技术相结合，我们便能构建出松散耦合且灵活的应用程序，从而推动数字化转型的实现。
与云原生和 DevOps 实践相集成
随着企业越来越多地采用云原生架构和 DevOps 实践，API 网关和服务网格的集成将变得更加重要。例如，在 Kubernetes 环境中，服务网格可以管理容器之间的内部通信，而 API 网关可以管理对应用程序的外部请求。此双层方法与 DevOps 实践高度契合，这些实践中的持续集成和持续部署 (CI/CD) 管道需要强大的流量管理和安全措施。从 API 网关和服务网格收集的指标还可以提供有关应用程序性能及安全性的宝贵见解，从而帮助团队优化其云原生应用程序。
常见问题
API 网关主要处理外部流量，并管理 API 客户端与 API 之间的 API 请求和响应。而服务网格负责管理微服务架构内微服务之间的内部流量，以确保实现安全可靠的通信。
API 网关通常包含内置的身份验证机制，用于对外部 API 请求进行验证和授权。服务网格能够管理微服务之间的内部身份验证，以确保只有经过身份验证的服务才能相互通信。
API 网关可管理进出 API 的流量，并处理负载均衡和速率限制等任务。服务网格可管理微服务架构内的流量，在微服务之间实现负载均衡并在发生服务故障时重新路由流量。
是的，服务网格与 Kubernetes 和其他云原生环境具有非常好的兼容性。它通过处理通信、流量管理和安全性来管理微服务在这些环境中的动态特性，从而使应用程序的扩展和管理变得更加轻松。
在 API 网关和服务网格实施中，指标对于实现监控性能、安全性和可靠性至关重要。在 API 网关中，指标可帮助跟踪 API 使用情况并检测潜在问题。在服务网格中，指标可提供有关微服务运行状况和性能的见解，从而帮助优化流量并有效管理资源。
是的，对于 API 网关和服务网格，目前有多种开源选项可供使用。例如，Hong 和 Ambassador 是热门的开源 API 网关，而 Istio 和 Linkerd 是广泛使用的开源服务网格。
客户为什么选择 Akamai
Akamai 是一家致力于支持并保护在线商业活动的网络安全和云计算公司。我们卓越的安全解决方案、出色的威胁情报和全球运营团队可提供深度防御，保护各地的企业数据和应用程序。Akamai 的全栈云计算解决方案可在海外分布广泛的平台上提供高性能且经济实惠的服务。众多全球企业信赖 Akamai，凭借我们卓越的可靠性、扩展性和专业技术，企业能够从容拓展业务。