使用了 Service Mesh 后我还需要 API 网关吗?

https://www.kubernetes.org.cn/6762.html

api gateway和istio 是不一样的 追求不一样

这篇文章也许无法打破缠绕在 API 网关和服务网格周围的喧嚣。即便已经是 2020 年了,围绕这些话题仍然会存在大量的疑虑。
第一个曝光:我在 Solo.io 这家公司工作,公司的业务聚焦于今天我们要讨论的主题。我提前说明一下以免你会有“你的观点是有偏见的”的反应。每个人的观点都有偏见。但可以肯定的是,我在 Solo.io 工作是因为我想看到这些想法被付诸实施并推向市场,而不是与之相反。

第二个曝光:我正在写一本有关服务网格的书,名为《Istio in Action》,这花了我很多时间。在本文中,不可否认我是站在 Istio的角度来讨论“服务网格”的,但如果我指的是更普遍的服务网格的概念时,我会特别指出。

**为什么会有另一个关于此话题的博客?**

有大量关于当前主题的文章。我们看过“API 网关用于南北流量,而服务网格用于东西流量”。还有人写了“API 网关用于管理业务功能,而服务网格用于服务到服务通信”。API 网关具有服务网格不具备的特定功能,其中一些可能不再适用。另一方面,有些人更接近我的思考方式。

然而,市场中仍存在明显的困惑。

我也希望看到人们如何看待不同方法之间权衡的严肃讨论。例如,服务网格和 API 网关之间的职责/主张存在重叠。人们对选择感到困惑和不知所措。

— Andrew Clay Shafer 雷启理 (@littleidea)

June 12, 2019

**困惑是什么**

大约一年前,我写了一篇关于 API 网关身份危机的文章,评估了 API 管理 [Kubernetes](http://www.alauda.cn) Ingress 和 API 网关(带有相关定义)的差异。在那篇文章的最后,我试图解释服务网格是如何应对这些功能的,但是没有详细说明它们如何不同,以及什么时候使用它们。我强烈推荐阅读这篇文章,因为在某些方面,它是“第一部分”,本文作为“第二部分”。
我认为产生混淆的原因如下:

技术使用上存在重叠(代理)

功能上存在重叠(流量控制,路由,指标收集,安全/策略增强等)

“服务网格”可替代 API 管理的理念

服务网格能力的误解

一些服务网格有自己的网关

最后一点尤其使人困惑。

如果服务网格仅仅是针对东西流量(边界内),那么为什么有一些服务网格,如 [Istio](http://www.alauda.cn) 所说,有一个 Ingress 网关针对南北流量(并且是网格的一部分)?例如下面来自 Istio Ingress 网关的文档:

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

我们的 API 不是 HTTP 吗?如果我们通过 Istio的网关将 HTTP 请求引入集群/网格中(顺便说一句,这基于强大的 Envoy 代理 项目),这还不够吗?

假设

当我们提到“服务网格”时,将假定是指 Istio 和 [Istio](http://www.alauda.cn) 的网关。选择这个场景是因为它最能说明重叠和混淆。其他服务网格也有网关,而有些还没有显式网关。当然你的情况也许会有所不同。

它们的重叠在哪里

业务的第一个步骤是识别 API 网关和服务网格功能看上去重叠的区域。两者都处理应用程序流量,所以重叠应该不足为奇。下面的清单列举了一些重叠的功能:

遥测数据收集

分布式追踪

服务发现

负载均衡

TLS 终止/开始

JWT 校验

请求路由

流量切分

金丝雀发布

流量镜像

速率控制

好吧,它们确实有重叠。那么你需要一个?还是两个?还是都不需要?

它们的分叉点在哪里

服务网格运行在比 API 网关更低的级别,并在架构中所有单个服务上运行。服务网格为服务客户提供关于架构拓扑的“更多细节”(包括客户端负载均衡、服务发现、请求路由),应该实现的弹性机制(超时、重试、熔断),应该收集的遥测(度量、跟踪)和参与的安全流(mTLS、RBAC)。所有这些实现细节通常由某个 sidecar(请考虑 Envoy)提供给应用程序,但它们不必这样做。请参阅我在 ServiceMeshCon 有关服务网格数据平面演化的演讲。

下面的话引自 API 身份危机:

服务网格的目标是通过在 L7 上透明地操作来解决任何服务/应用程序中列举的问题。换句话说,服务网格希望接入到服务中(而不是到服务中编写代码)。

结论:服务网格为服务/客户端提供了更多关于架构其余部分实现的细节/保真度。

另一方面,API 网关则扮演着不同的角色:“抽象细节”和解耦实现。API 网关提供了跨应用程序架构中所有服务的内聚抽象——作为一个整体,为特定的 API 解决了一些边缘/边界问题。

无论服务网格是否存在,API 网关都存在于应用程序/服务之上,并为其他部分提供抽象。它们做的事情包括聚合 API、抽象 API 和用不同的实现方式暴露它们,并基于用户在边缘添加更复杂的零信任安全策略。应用程序架构边界上的问题与边界内的问题。

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

在微服务/云原生架构的边界上,API 网关提供了服务网格无法在同等程度上解决的三个主要能力:

边界解耦

严格控制数据的进出

桥接安全信任域

让我们看看:

边界解耦

API 网关的核心功能是为边界外的客户端提供稳定的 API 接口。从 Chris Richardson 的微服务模式一书中,我们可以将“API 网关模式”改写为:

显式地简化一组 API / 微服务的调用

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

这里的关键是 API 网关,当它实现时,它将作为应用程序架构的单一入口点,成为客户端的 API

来自 API 网关身份危机 一文中 API 网关的实现案例:

Solo.io Gloo

Spring Cloud Gateway

Netflix Zuul

IBM-Strongloop Loopback/Microgateway

从功能上看,API 网关需要支持什么?企业在现实的用例中会看到哪些需要 API 网关(服务网格不太适合)的情况:

请求/响应转换

应用协议转换如 REST/SOAP/XSLT

错误/速率定制响应

直接响应

对 API/代理管道的精确控制

API 聚合/分组

让我们挨个来看。

请求/响应传输

作为在 API 网关上暴露 API 的一部分,您可能希望隐藏后端 API 实现的细节。这可能是改变请求内容、删除/添加标头、将标头放入正文的一些组合,反之亦然。当后端服务对 API 进行更改时,或者当客户端不能像提供方那样快速更新时,这提供了一个很好的从客户端解耦的点。

应用协议转换

许多企业在技术上进行了投入,如基于 HTTP、SOAP 的 XML,或基于 HTTP 的 JSON。他们可能希望使用更严格的、特定于客户端的 API 来公开这些 API,并继续保持互操作性。此外,服务提供者可能希望利用新的 RPC 机制(如 gRPC)或流协议(如 rSocket)。

错误/速率定制响应

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

直接响应

当客户端(受信任的或恶意的)请求不可用的资源,或由于某种原因被阻止上行时,最好能够终止代理并使用预先屏蔽的响应返回。

对 API/代理管道的精确控制

没有一种方法可以满足所有代理的期望。API 网关应该能够改变应用其功能的顺序(速率限制、authz/n、路由、转换等),并在出现问题时提供一种调试方法。
API 聚合

在多个服务上公开一个抽象常常伴随着将多个 API 混合成一个 API 的期望。类似于 GraphQL 的东西可以满足这个需求。
正如您所看到的,在客户端和提供服务者之间提供一个强大的解耦点涉及的不仅仅是允许 HTTP 通信进入集群这么简单。

严格控制什么可以进入/离开服务

API 网关的另一个重要功能是“控制”哪些数据/请求允许进入应用架构,哪些数据/响应允许流出。这意味着,网关需要对进入或发出的请求有深入的理解。例如,一个常见的场景是 Web 应用程序防火墙防止 SQL 注入攻击。另一种是“数据丢失预防”技术,用于在请求 PCI-DSS/HIPPA/GDPR 时阻止 SSN 或 PII 被返回。边界是帮助实现这些策略的天然位置。

同样,定义和实施这些功能并不像允许 HTTP 通信流进入集群那么简单。

定制安全/桥接信任域

API 网关提供的最后一个主要功能是边缘安全性。这涉及到向存在于应用程序架构之外的用户和服务提供身份和范围策略,从而限制对特定服务和业务功能的访问。这与前面的部分相关。
一个常见的例子是能够绑定到 OAuth/SSO 流,包括 Open ID Connect。这些“标准”的挑战在于,它们可能没有得到充分实施,也可能没有得到正确实施。API 网关需要一种方法来灵活地适应这些环境以及提供定制。

在许多企业中,已经存在身份/信任/认证机制,API 网关的很大一部分是为了向后兼容而进行本地集成。虽然出现了 SPIFEE 这样的新标准,但企业需要一段时间才能落地,与此同时,API 网关(甚至是针对在其下一代架构上运行的应用程序的网关)是一个艰难的要求。同样,你可以检视并说这也和上面提到的变换/解耦点有关。

怎样落地其中一个/另一个/两者/两者都不?

在之前的一篇博客中,我概述了一些采用这种技术的挑战(API 网关和服务网格),并给出了关于如何最好地应用这种技术的提示。
重申一下:从边缘开始。这是架构中熟悉的一部分。也要考虑选择最合适的。自从我们引入了云基础设施和云原生应用架构以来,假设(编者注:文章开始所说的假设)已经发生了变化。例如,如果您打算采用 Kubernetes,我强烈建议您考虑使用从头开始构建的应用程序网络技术(例如,检查 Envoy 代理和已经被提升和转移的应用程序网络技术)。例如,在 Solo.io,我们已经为此建立了一个名为 Gloo 的开源项目。

你需要一个服务网格吗?如果您正在部署到云平台,有多种类型的语言/框架来实现您的工作负载,并构建一个微服务架构,那么您可能需要一个。选择也很多。我做过各种比较和对比的演讲,最近的是 OSCON 演讲。请随意参考并找到最合适你的。

结论

是的,API 网关在功能上与服务网格有重叠。它们在使用的技术方面也可能有重叠(例如,Envoy)。但是,它们的角色有很大的不同,理解这一点可以在部署微服务架构和发现无意的假设时为您省去很多麻烦。

本文转自CNCF
作者 Christian Posta

【转帖】使用了 Service Mesh 后我还需要 API 网关吗?的更多相关文章

  1. 蚂蚁金服 Service Mesh 渐进式迁移方案|Service Mesh Meetup 实录

    小蚂蚁说: 本文是基于在 Service Mesher Meetup 上海站的主题分享<蚂蚁金服 Service Mesh 渐进式迁移方案>内容整理,完整的分享 PPT 获取方式见文章底部 ...

  2. Service Mesh 是新瓶装旧酒吗?

    点击下载<不一样的 双11 技术:阿里巴巴经济体云原生实践> 本文节选自<不一样的 双11 技术:阿里巴巴经济体云原生实践>一书,点击上方图片即可下载! 作者 | 李云(花名: ...

  3. 谁说微服务是Spring Cloud的独角戏?Service Mesh了解一下?

    Service Mesh 的概念自 2017 年初提出之后,受到了业界的广泛关注,作为微服务的下一代发展架构在社区迅速发酵,并且孵化出了诸如 Istio 等广受业界关注的面向于云原生 (Cloud N ...

  4. Service Mesh架构的持续演进 单体模块化 SOA 微服务 Service Mesh

    架构不止-严选Service Mesh架构的持续演进 网易严选 王育松 严选技术团队 2019-11-25 前言同严选的业务一样,在下层承载它的IT系统架构一样要生存.呼吸.增长和发展,否则过时的.僵 ...

  5. 干货 | 蚂蚁金服是如何实现经典服务化架构往 Service Mesh 方向的演进的?

    干货 | 蚂蚁金服是如何实现经典服务化架构往 Service Mesh 方向的演进的? https://www.sohu.com/a/235575064_99940985 干货 | 蚂蚁金服是如何实现 ...

  6. 【转帖】赤壁之战,曹操大败只因缺了Service Mesh

    赤壁之战,曹操大败只因缺了Service Mesh 本文作者把微服务向 Service Mesh 的进化融入到了三国故事中,妙趣横生.故事比较长,大家慢慢看,精彩的在后边. http://develo ...

  7. 解读2017之Service Mesh:群雄逐鹿烽烟起

    https://mp.weixin.qq.com/s/ur3PmLZ6VjP5L5FatIYYmg 在过去的2016年和2017年,微服务技术得以迅猛普及,和容器技术一起成为这两年中最吸引眼球的技术热 ...

  8. 深入解读Service Mesh的数据面Envoy

    在前面的一篇文章中,详细解读了Service Mesh中的技术细节,深入解读Service Mesh背后的技术细节. 但是对于数据面的关键组件Envoy没有详细解读,这篇文章补上. 一.Envoy的工 ...

  9. 深入解读Service Mesh背后的技术细节

    在Kubernetes称为容器编排的标准之后,Service Mesh开始火了起来,但是很多文章讲概念的多,讲技术细节的少,所以专门写一篇文章,来解析Service Mesh背后的技术细节. 一.Se ...

随机推荐

  1. 洛谷 P3205 [HNOI2010]合唱队(区间dp)

    传送门 解题思路 观察队形的组成方式可以得出,最后一名加入区间i...j的人要么是在i位置上,要么是在j位置上,所以我们可以用dp[i][j][0]表示区间i...j最后一个加入的人站在i位置上的方案 ...

  2. python学习笔记2018-9-17

    1.print("{0:^30}\n{1:^30}\n{1:10}".format("age","name")) {0:^30}中的0是一个 ...

  3. 2018年Android面试题含答案--适合中高级(下)(转)

    这里是我整理出来的 面试题,答案我花了很久的时间.加上我自己的理解整理出来的,作者不易,请谅解.有答案的的:https://xiaozhuanlan.com/topic/6132940875   1. ...

  4. java基础源码 (2)--StringBuilder类

    Serializable(接口): 是一个IO的序列化接口,实现了这个接口,就代表这个类可以序列化或者反序列化,该接口没有方法或者字段,仅用于标识可串行话的语义. Appendable(接口): /* ...

  5. exctern C

    在C++中调用C语言 因为C++扩展了函数重载.编译时会将函数名修改,所以直接条用会出错. #ifdef __cplusplusextern "C" {#endif // __cp ...

  6. 【LeetCode】 240. 搜索二维矩阵 II

    题目 编写一个高效的算法来搜索 m x n 矩阵 matrix 中的一个目标值 target.该矩阵具有以下特性: 每行的元素从左到右升序排列. 每列的元素从上到下升序排列. 示例: 现有矩阵 mat ...

  7. POJ 2521:How much did the businessman lose

    How much did the businessman lose Time Limit: 1000MS   Memory Limit: 65536K Total Submissions: 9965 ...

  8. VM虚拟机安装windows7操作系统

    一.创建虚拟机 1. 新建虚拟机 2. 默认配置,点击下一步 3. 稍后安装操作系统,下一步 4. 选择操作系统,32位选择windows 7,64位选择windows 7 x64,点击下一步 5. ...

  9. 对DataFrame的再理解

    1.构造需要从字典构造 cds={'code':["002372.XSHE","002415.XSHE","002304.XSHE",&qu ...

  10. 《新标准C++程序设计》2.1-2.3(C++学习笔记3)

    1.结构化程序设计的不足 程序=算法+数据结构 数据结构和变量相对应,算法和函数相对应,算法是用来操作数据结构的. 结构化程序设计中,函数和其所操作的数据结构,没有直观的联系.随着程序规模的增加,程序 ...