API Gateway Pattern
此类API网关的示例包括:
- Spring Cloud Gateway
- Solo.io Gloo
- Netflix Zuul
- IBM-Strongloop Loopback/Microgateway
也可以使用更通用的编程或集成语言/框架(例如:
- Apache Camel
- Spring Integration
- Ballerina.io
- Eclipse Vert.x
- NodeJS
由于这种类型的API网关与应用和服务的开发紧密相关,因此我们希望开发人员能够参与帮助指定API网关公开的API,了解所涉及的任何聚合逻辑以及快速测试和更改此API基础架构的能力。我们还希望运维人员或SRE对API网关的安全性、弹性和可观察性配置有一些意见。这种层级的基础架构还必须适应不断发展的、按需的、自助服务开发人员工作流。可以通过查看GitOps模型获取更多这方面信息。
进入服务网格(Service Mesh)在云基础架构上运行服务架构的一部分难点是,如何在网络中构建正确级别的可观察性和控制。在解决此问题的先前迭代中,我们使用了应用程序库和希望的开发人员治理来实现此目的。但是,在大规模和多种开发语言环境下,服务网格技术的出现提供了更好的解决方案。服务网格通过透明地实现为平台及其组成服务带来以下功能:
- 服务到服务(即东西向流量)的弹性
- 安全性包括最终用户身份验证、相互TLS、服务到服务RBAC / ABAC
- 黑盒服务的可观察性(专注于网络通信),例如请求/秒、请求延迟、请求失败、熔断事件、分布式跟踪等
- 服务到服务速率限制,配额执行等
精明的读者会认识到,API网关和服务网格在功能上似乎有所重叠。服务网格的目的是通过在L7透明地解决所有服务/应用程序的这些问题。换句话说,服务网格希望融合到服务中(实际上它的代码并没有嵌入到服务中)。另一方面,API网关位于服务网格以及应用程序之上(L8?)。服务网格为服务、主机、端口、协议等(东西向流量)之间的请求流带来了价值。它们还可以提供基本的集群入口功能,以将某些此功能引入南北向。但是,这不应与API网关可以带来北/南流量的功能相混淆。(一个在集群的南北向和一个是在一组应用程序的南北向)
Service Mesh和API网关在某些方面在功能上重叠,但是在它们在不同层面互补,分别负责解决不同的问题。理想的解决方案是将每个组件(API管理、API网关、服务网格)合适的安置到您的解决方案中,并根据需要在各组件间建立良好的边界(或在不需要时排除它们)。同样重要的是找到适合去中心化开发人员和运营工作流程的这些工具实现。即使这些不同组件的术语和标识存在混淆,我们也应该依靠基本原理,并了解这些组件在我们的体系结构中带来的价值,从而来确定它们如何独立存在和互补并存。
微服务不能没有网关,就如同 Java 程序员不能没有IDEA、Eclipse。为什么呢?
之所以网关对微服务这么重要,主要有以下几点原因:
1. 解决 API 放哪里的问题要知道,采用微服务架构的系统本身是由很多的独立服务单元组合起来的。而客户端要调用系统,则必须通过系统提供的各种对外开放的 API 来实现。
问题来了,这些 API 要放在哪里呢?直接放在组成系统的服务单元上行不行?
比如,在一套电商系统上,关于订单相关的 API ,放在组成订单服务的服务单元上;风控服务的 API ,放在组成风控服务的服务单元上。
好,咱们假设有这么一个场景,有一位用户想在这套电商系统上查看下商品详情。那么,这个查看商品详情的操作,就可能:
- 调用商品服务的 API 获取商品描述
- 调用评价服务的 API 获取相关评价
- 调用商家服务的 API 获取商家信息
- 调用礼券服务的 API 获取相关礼券
- ……