Service Mesh 和 API Gateway 关系深度探讨
肉眼品世界
共 5546字,需浏览 12分钟
·
2022-04-09 21:00
备注1:为了节约篇幅,我们将直奔主题,假定读者对 Service Mesh 和 API Gateway 已有基本的了解。 备注2: 这边文章更关注于梳理整个脉络,内容不会展开的特别细,尤其是其他文章已经详细阐述的部分。如果您在浏览本文之后,还想更深入的了解细节,请继续阅读文章最后的参考资料和推荐阅读。
# 原本清晰的界限:定位和职责
Service Mesh:微服务的网络通信基础设施,负责(系统内部的)服务间的通讯; API Gateway:负责将服务以 API 的形式暴露(给系统外部),以实现业务功能;
位于最底层的是拆分好的原子微服务,以服务的形式提供各种能力; 在原子微服务上是(可选的)组合服务,某些场景下需要将若干微服务的能力组合起来形成新的服务; 原子微服务和组合服务部署于 系统内部,在采用 Service Mesh 的情况下,由 Service Mesh 提供服务间通讯的能力; API Gateway 用于将系统内部的这些服务暴露给 系统外部,以 API 的形式接受外部请求;
Service Mesh 部署在系统内部:因为原子微服务和组合服务通常不会直接暴露给外部系统; API Gateway 部署在系统的边缘:一方面暴露在系统之外,对外提供 API 供外部系统访问;一方面部署在系统内部,以访问内部的各种服务;
东西向通讯:指服务间的相互访问,其通讯流量在服务间流转,流量都位于系统内部; 南北向通讯:指服务对外部提供访问,通常是通过 API Gateway 提供的 API 对外部暴露,其通讯流量是从系统外部进入系统内部;
解释一下“东西南北”的由来:如上图所示,通常在地图上习惯性的遵循“上北下南,左东右西”的原则。
# 哲学问题:网关访问内部服务,算东西向还是南北向?
# Sidecar:真正的重合点
这个时候 Service Mesh 和 API Gateway 的关系就变得有意思了,因为 Service Mesh 中 Sidecar 的引入,所以前面的“哲学问题”又有了一个新的解法:API Gateway 这次真的可以分拆为两个独立部署的物理实体,而不是逻辑上的两个部分:
API Gateway 本体:实现 API Gateway 除了访问内部服务之外的功能; Sidecar:按照 Service Mesh 的标准做法, 我们视 API Gateway 为一个部署于 Service Mesh 中的普通服务,为这个服务 1:1 的部署 Sidecar;
# BFF:把融合进行到底
组合服务还属于服务的范畴,只是实现机制上组合了多个服务,对外暴露的依然是一个完整和规范的服务; BFF 不同,BFF 如名字所示,Backend For Frontend,完全是为了前端而存在,核心目标之一是简化前端的访问; 对我们今天的话题而言,最关键的一点:BFF 完全收口了从外部进入的流量,而组合服务没有,API Gateway 是可以直接访问原子微服务的;
和 BFF 部署在一起的,是没有 API Gateway 功能的普通 Sidecar; API Gateway 和 Sidecar 融合之后,这就是一个“有 API Gateway 功能的大 Sidecar”(或者是“有 Sidecar 功能的特殊 API Gateway”):虽然扮演了 API Gateway 的角色,但本质上依然包含一个完整功能的 Sidecar,和 BFF 自带的 Sidecar 是等同的;
流量直接打到 BFF 上(BFF 前面可能会挂其他的网络组件提供负载均衡等功能); BFF 的 Sidecar 接收流量,完成 API Gateway 的功能,然后将流量转给 BFF; BFF 通过 Sidecar 调用内部服务(和没有合并时一致);
# 总结
作者:敖小剑
来源:金融级分布式架构
推荐阅读:
评论