如何为服务网格选择入口网关_如果使用服务网格，是否需要API网关？

如何为服务网格选择入口网关

这篇文章可能无法突破API网关和Service Mesh周围的噪音。 但是，这是2020年，围绕这些主题仍然存在很多困惑。 我选择编写此内容是为了帮助带来真正的具体解释，以帮助阐明差异，重叠之处以及何时使用它们。 如果您觉得我正在增加困惑，不同意或希望向我购买啤酒，请随时在Twitter（@christianposta）上与我交流（这些并非互斥的原因）。

第一次披露： 我在Solo.io公司工作 ，该公司投资了该主题。 我在“您的观点有偏见”React之前提到这一点。 每个人的看法都是有偏见的。 但是可以肯定的是，我之所以来Solo.io工作，是因为我希望看到这些想法付诸实践并推向市场，而不是相反。

第二个披露 ：我正在写一本名为《 Istio in Action》的书，这是我花费最多时间的服务网格。 从Istio的角度来看，当我讨论“服务网格”时，本文的观点是公认的，但是当我更笼统地提及服务网格时，我会尝试指出。

为什么要另外一个关于这个话题的博客？

有关此主题的信息很多。 我们已经看到“ API网关用于北/南流量，而服务网格用于东/西” 。 一些人写过“ API网关作为管理业务功能，而服务网格用于服务到服务的通信” 。 其他人指出了API网关执行服务网格的特定功能，而其中的某些功能已不再是事实。 另一方面，有些人更接近我对它们的看法 。

但是，市场上仍然存在明显的混乱。

我还希望看到有关人们如何看待不同方法之间的取舍的认真讨论。 例如，服务网格和api网关之间的职责/主张存在重叠。 人们对选择感到困惑和不知所措。

-Andrew Clay Shafer雷启理（@littleidea） 2019年6月12日

有什么困惑

大约一年前，我写了一篇关于API网关的身份危机的文章，其中评估了API管理，Kubernetes入口和API网关（具有相关定义）之间的差异。 在那篇文章的结尾，我试图解释服务网格如何适合方程式，但是没有足够的细节来说明它们之间的区别以及何时使用一种或另一种。 我强烈建议您以某种方式阅读该帖子 ，这是该帖子的“第一部分”，是“第二部分”。

我相信会因为以下原因而引起混乱：

• 使用的技术存在重叠（代理）
• 功能上存在重叠（流量控制，路由，度量收集，安全/策略执行等）
• 一种信念，即“服务网格”取代了API管理
• 对服务网格功能的误解
• 一些服务网格具有自己的网关

最后一个项目符号使讨论特别混乱。

如果服务网格仅用于东西方向的交通（在边界内），那么为什么某些服务网格（例如Istio） 具有用于北/南的入口网关 （并且是网格的一部分）？ 例如，从Istio Ingress Gateway文档中：

网关描述了一个负载均衡器，该负载均衡器在网格的边缘运行，以接收传入或传出的HTTP / TCP连接。

我们的API不是HTTP吗？ 如果我们可以使用Istio的网关（它的btw建立在令人惊叹的Envoy代理项目上）将HTTP请求发送到群集/网格中，这还不够吗？

假设条件

当我们说“服务网格”时，本文的其余部分将假定使用Istio和Istio的网关。 我选择这种情况是因为它是最能说明重叠和混乱的情况。 其他服务网格也有一个Gateway ，而有些还没有显式网关 。 YMMV。

它们重叠的地方

首先要做的是认识到API网关和服务网格的功能似乎重叠的区域。 两者都处理应用程序流量，因此重叠并不奇怪。 以下清单列举了一些重叠的功能：

• 遥测收集
• 分布式跟踪
• 服务发现
• 负载均衡
• TLS终止/原始
• JWT验证
• 请求路由
• 流量分割
• 金丝雀释放
• 交通阴影
• 限速

好的，所以它们重叠了。 那你需要一个吗？ 都？ 都不行

他们分歧的地方

服务网格的运行级别比API网关低，并且在体系结构内的所有单个服务上运行。 服务网格为服务客户端提供“更多详细信息”，包括架构拓扑（客户端负载平衡，服务发现，请求路由），应实施的弹性机制（超时，重试，电路中断），应收集的遥测信息（指标，跟踪）以及它们参与的安全流（mTLS，RBAC）。 所有这些实现细节通常都是通过一些补充流程（例如Envoy ）提供给应用程序的，尽管不必这样做。 请参阅我关于ServiceMeshCon 的服务网格数据平面演变的演讲。

从API身份危机文章中：

服务网格的目的是通过在L7透明地解决所有服务/应用程序的这些问题（上面列出的问题）。 换句话说，服务网格希望融合到服务中（实际上并没有被编码为服务的代码）。

底线 ：服务网格为服务/客户端提供了有关架构其余部分实施的更多详细信息/保真度。

另一方面，API网关扮演着不同的角色：“抽象细节”并分离实现。 API网关提供了整个应用程序体系结构中所有服务的内聚抽象，同时代表特定的API解决了一些边缘/边界问题。

API网关位于应用程序/服务之上 ，而不管服务网格是否存在并向其他组提供抽象。 它们可以执行诸如汇总API，抽象API的工作，并以与实现不同的方式公开它们，并根据用户在边缘添加更复杂的零信任安全策略。 应用程序体系结构边界上的问题与边界内的问题不同。

边缘问题与服务到服务的挑战不同

在微服务/云原生架构的边界，API网关提供了服务网格无法以相同程度解决的三个主要功能：

• 边界解耦
• 允许对数据进行严格控制
• 桥接安全信任域

让我们来看看：

边界解耦

API网关的核心功能是为边界之外的客户端提供稳定的API接口。 从克里斯·理查森（Chris Richardson）的《微服务模式手册》中 ，我们可以将“ API网关模式”解释为：

显着简化了一组API /微服务的调用

为一组特定的用户，客户端或使用者模拟“应用程序”的内聚API。

这里的关键是API网关，当实现时，将成为客户端的API，作为应用程序体系结构的单个入口点

API网关身份危机文章中的示例API网关实现：

• 格洛
• Spring Cloud Gateway
• Netflix Zuul
• IBM-Strongloop回送/微网关

从功能的角度来看，API网关需要支持什么？ 企业看到哪些实际用例需要API网关[服务网格不太适合]：

• 请求/响应转换
• 应用程序协议转换，如REST / SOAP / XSLT
• 错误/速率限制自定义响应
• 直接回应
• api / proxy流水线的精确控制
• API组成/分组

让我们来看看每个。

请求/响应转换

作为在API网关上公开API的一部分，您可能希望隐藏有关如何实现后端API的详细信息。 这可以是更改请求的形状，删除/添加标头，将标头放入正文中或相反的某种组合。 当后端服务正在更改API或客户端无法像提供程序一样快地更新时，这为客户端提供了一个很好的解耦点。

应用协议转换

许多企业已经投资了诸如HTTP上的XML，SOAP或HTTP上的JSON之类的技术。 他们可能希望使用更严格的客户端特定的API来公开这些内容，并继续具有互操作性。 此外，服务提供商可能希望利用新的RPC机制（如gRPC）或流协议（如rSocket）。

错误/速率限制自定义响应

转换来自上游服务的请求是API网关的一项至关重要的功能，因此定制来自网关本身的响应也是如此。 采用API网关的虚拟API进行请求/响应/错误处理的客户端希望网关自定义其响应以适应该模型。

直接回应

当客户端（受信任的或邪恶的）请求不可用的资源，或由于某种原因而阻止其向上游移动时，最好能够终止代理并以预先罐装的响应进行响应。

精确控制代理管道

没有一种适合所有代理期望的尺寸。 API网关应该既可以更改其功能应用的顺序（速率限制，身份验证/ n，路由，转换等），又可以提供一种在出现问题时进行调试的方法。

API组成

通常，期望将多个API混搭为一个API，从而对多个服务进行抽象。 诸如GraphQL之类的东西可能适合此要求。

如您所见，在客户端和提供者服务之间提供强大的解耦点不仅仅涉及允许HTTP流量进入群集。

严格控制允许的服务进/出

API网关的另一个重要功能是“管理”哪些数据/请求被允许进入应用程序体系结构以及哪些数据/响应被允许出去。 这意味着，网关将需要深入了解进入架构的请求或那些发出的请求。 例如，常见的场景是Web应用程序防火墙以防止SQL注入攻击。 另一个是“防止数据丢失”技术，可以防止在请求PCI-DSS / HIPPA / GDPR时返回SSN或PII。 边缘是帮助实施这些政策的自然之所。

同样，定义和执行这些功能并不只是允许HTTP流量进入集群那么简单。

定制安全性/桥接信任域

API网关提供的最后一个主要功能是边缘安全性。 这涉及对应用程序体系结构之外的用户和服务提出挑战，以提供身份和范围策略，从而可以限制对特定服务和业务功能的访问。 这与上一节相关。

一个常见的示例是能够绑定到包括Open ID Connect在内的OAuth / SSO流。 这些“标准”面临的挑战是它们可能未完全实施或实施不正确。 API网关需要一种灵活地适应这些环境并提供自定义的方法 。

在许多企业中，已经存在身份/信任/认证机制，并且API网关的很大一部分将能够本地集成以实现向后兼容性。 尽管已经出现了像SPIFEE这样的新标准，但企业采用起来还需要一段时间，与此同时，对API网关（甚至是针对在其下一代体系结构上运行的应用程序的网关）的要求也很高。 同样，您可以斜视一下，并说这也与上述转换/解耦点有关。

如何采用一个/另一个/两者/都不选择？

在之前的博客中，我概述了采用这种技术（API网关和服务网格）所面临的一些挑战，并提供了一些有关如何最佳采用的技巧。

在这里重新迭代：从边缘开始。 这是体系结构中熟悉的部分。 选择最合适的一个也是要考虑的事情。 自从我们引入了云基础架构和云原生应用程序架构以来，假设发生了变化。 例如，如果您要采用Kubernetes，我强烈建议您考虑从头开始构建的应用程序联网技术，以生活在这个世界中（例如，查看Envoy Proxy与已提出并转移的某些内容。例如，在Solo .io ，我们利用Envoy的Gloo建立了一个开源项目。

您是否需要服务网格？ 如果要部署到云平台，需要多种类型的语言/框架来实现您的工作负载并构建微服务架构，那么您可能需要一种。 有很多选择。 我已经做了关于比较和对比各种技术的讨论，其中我的OSCON演示是最新的 。 请随时与您联系以寻求最适合您的指导 。

结语

是的，就功能而言，API网关与服务网格重叠。 它们在使用的技术（例如Envoy）方面也可能有重叠。 但是，它们的角色有很大不同，理解这一点可以在部署微服务体系结构并发现过程中意外的假设时为您省去很多麻烦。

翻译自: https://www.javacodegeeks.com/2020/02/do-i-need-an-api-gateway-if-i-use-a-service-mesh.html

如何为服务网格选择入口网关