searchusermenu
  • 发布文章
  • 消息中心
点赞
收藏
评论
分享

优秀文章分享:服务网格(Service Mesh)在微服务中解决了什么问题?-API7技术团队

2023-02-28 07:48:34
16
0

服务网格是一种技术架构,它用于管理微服务系统中各个服务之间的通信,旨在处理微服务间的流量(也称为东西向流量)。

在云原生应用中,一个应用的背后可能存在着成百上千个服务,各个服务可能又有着若干个实例,各个实例的状态也一直在变化。在如此复杂的服务运行环境中,如何保障用户的可靠访问以及维持业务的平稳运行成为一个很大的挑战,服务网格的治理方案便应运而生。

服务网格就像是微服务间的 TCP/IP,负责服务间的网络调用、限流限速、监控等。服务网格目前主要应用在 Kubernetes 平台上,其最经典的一种实现模式是 Sidecar 模式:将一些通用功能抽象到 Sidecar 容器中,并将 Sidecar 容器与服务容器挂载在同一个 Pod 里。由于 Sidecar 容器与服务容器并行,且各个 Sidecar 间相互通讯,共同构成了网格形式的网络,因此称之为服务网格。当然,Sidecar 并非唯一的一种服务网格实现模式,除此之外还有 DaemonSet 模式及 Ambient mesh 模式。

为什么需要服务网格?

在服务网格流行之前,很多微服务架构的服务治理都是通过微服务框架配合控制平台实现的,这种方式存在以下几个问题:

框架与业务耦合,整体复杂度与运维难度很高,且开发者需要对公共库有一定的了解,没法只专注于业务实现。

需要维护多种语言版本的框架,增加了维护的成本。

微服务框架本身的升级成本比较高,在升级时往往需要进行业务重启等操作。

线上存在很多版本的框架,会导致复杂的兼容性考虑。

面对以上这些问题,原 Twitter 工程师 Willian Morgan 提出了 Service Mesh 的概念,即服务网格。服务网格通过 Sidecar 模式实现在不侵入业务服务的情况下将基础设施与业务逻辑解耦,实现跨语言统一更新发布及运维。

服务网格将流量管理、可观测性和安全通讯等功能下沉到基础组件,因此开发者无需关心通信层和服务治理的具体实现,与通信相关的一切工作直接交给服务网格,让开发者能够更关注于业务的开发。基于服务网格的这些特点,前面提到的几个问题都能够得到有效解决。

服务网格是如何工作的?

服务网格不会为应用的运行时环境加入新功能,任何架构中的应用还是需要相应的规则来指定请求如何从 A 点到达 B 点。但服务网格的不同之处在于,它从各个服务中提取逻辑管理的服务间通信,并将其抽象为一个基础架构层。

目前服务网格大多数采用是数据面 + 控制面的架构模式

其中控制面用于管理和配置数据面以及在运行时执行策略。单个网格中控制平面的所有实例共享相同的配置资源。主要聚焦于安全、可观测性、流量管控等策略的处理和下发,同时还能够收集和集中数据平面的遥测数据,供运维人员使用。

而数据面通常以代理的形式实现,是由一个个的网络代理 Sidecar 组成,Sidecar 与业务应用实例并行,通过拦截业务数据流以管控业务应用的流量。

在前面的介绍中有提到服务网格是将 Sidecar 设计模式在 Kubernetes 进行实现,通过容器化的方式实现了封装,Sidecar 主张以额外的容器来扩展或增强主容器,这个额外的容器被称为 Sidecar 容器,它与业务容器在同一个 Pod 中。而服务网格即是一个个 Sidecar 代理所构成的网格式网络。

服务网格的实际应用

在微服务架构中,工程师往往会为对外暴露的服务采取加密或访问限制的措施以保障服务的安全,但却忽视了集群内部的流量通信安全,所以至今仍有很多微服务应用没有采取服务间通信的加密措施,集群内部的流量以明文的形式进行传输,非常容易导致内部流量遭到数据窃听或是中间人攻击。

而为了防止集群内部流量遭到攻击,通常会使用 mTLS 将通讯数据进行加密。mTLS 可以用于确保服务网格中微服务之间的通信安全。它使用加密安全技术相互认证各个微服务并加密它们之间的流量。

虽然可以直接在微服务中定义通信安全策略并执行身份验证和加密,但在每一个微服务中去单独实现相同的功能效率是很低的。而且增加功能还需要改动业务代码,侵入业务逻辑。且即便完成了功能,后期的升级迭代与测试都需要开发者投入额外精力去维护,无法专注于业务功能的开发。

而使用服务网格,我们就可以在不影响原本业务的情况下零感知的为服务提供 mTLS 通信。因为在服务网格中,服务通信相关的功能都被转移至 Sidecar 代理中实现。在整个实现过程中,业务应用都不会受到影响,降低开发者心智负担。

当然,服务网格除了可以实现类似 mTLS 这类的内部流量安全配置功能,通过调整控制面的配置还能快速的拓展包括流量管控,可观测性,协议编解码等更多功能。

0条评论
作者已关闭评论
夏****天
1文章数
0粉丝数
夏****天
1 文章 | 0 粉丝
夏****天
1文章数
0粉丝数
夏****天
1 文章 | 0 粉丝

优秀文章分享:服务网格(Service Mesh)在微服务中解决了什么问题?-API7技术团队

2023-02-28 07:48:34
16
0

服务网格是一种技术架构,它用于管理微服务系统中各个服务之间的通信,旨在处理微服务间的流量(也称为东西向流量)。

在云原生应用中,一个应用的背后可能存在着成百上千个服务,各个服务可能又有着若干个实例,各个实例的状态也一直在变化。在如此复杂的服务运行环境中,如何保障用户的可靠访问以及维持业务的平稳运行成为一个很大的挑战,服务网格的治理方案便应运而生。

服务网格就像是微服务间的 TCP/IP,负责服务间的网络调用、限流限速、监控等。服务网格目前主要应用在 Kubernetes 平台上,其最经典的一种实现模式是 Sidecar 模式:将一些通用功能抽象到 Sidecar 容器中,并将 Sidecar 容器与服务容器挂载在同一个 Pod 里。由于 Sidecar 容器与服务容器并行,且各个 Sidecar 间相互通讯,共同构成了网格形式的网络,因此称之为服务网格。当然,Sidecar 并非唯一的一种服务网格实现模式,除此之外还有 DaemonSet 模式及 Ambient mesh 模式。

为什么需要服务网格?

在服务网格流行之前,很多微服务架构的服务治理都是通过微服务框架配合控制平台实现的,这种方式存在以下几个问题:

框架与业务耦合,整体复杂度与运维难度很高,且开发者需要对公共库有一定的了解,没法只专注于业务实现。

需要维护多种语言版本的框架,增加了维护的成本。

微服务框架本身的升级成本比较高,在升级时往往需要进行业务重启等操作。

线上存在很多版本的框架,会导致复杂的兼容性考虑。

面对以上这些问题,原 Twitter 工程师 Willian Morgan 提出了 Service Mesh 的概念,即服务网格。服务网格通过 Sidecar 模式实现在不侵入业务服务的情况下将基础设施与业务逻辑解耦,实现跨语言统一更新发布及运维。

服务网格将流量管理、可观测性和安全通讯等功能下沉到基础组件,因此开发者无需关心通信层和服务治理的具体实现,与通信相关的一切工作直接交给服务网格,让开发者能够更关注于业务的开发。基于服务网格的这些特点,前面提到的几个问题都能够得到有效解决。

服务网格是如何工作的?

服务网格不会为应用的运行时环境加入新功能,任何架构中的应用还是需要相应的规则来指定请求如何从 A 点到达 B 点。但服务网格的不同之处在于,它从各个服务中提取逻辑管理的服务间通信,并将其抽象为一个基础架构层。

目前服务网格大多数采用是数据面 + 控制面的架构模式

其中控制面用于管理和配置数据面以及在运行时执行策略。单个网格中控制平面的所有实例共享相同的配置资源。主要聚焦于安全、可观测性、流量管控等策略的处理和下发,同时还能够收集和集中数据平面的遥测数据,供运维人员使用。

而数据面通常以代理的形式实现,是由一个个的网络代理 Sidecar 组成,Sidecar 与业务应用实例并行,通过拦截业务数据流以管控业务应用的流量。

在前面的介绍中有提到服务网格是将 Sidecar 设计模式在 Kubernetes 进行实现,通过容器化的方式实现了封装,Sidecar 主张以额外的容器来扩展或增强主容器,这个额外的容器被称为 Sidecar 容器,它与业务容器在同一个 Pod 中。而服务网格即是一个个 Sidecar 代理所构成的网格式网络。

服务网格的实际应用

在微服务架构中,工程师往往会为对外暴露的服务采取加密或访问限制的措施以保障服务的安全,但却忽视了集群内部的流量通信安全,所以至今仍有很多微服务应用没有采取服务间通信的加密措施,集群内部的流量以明文的形式进行传输,非常容易导致内部流量遭到数据窃听或是中间人攻击。

而为了防止集群内部流量遭到攻击,通常会使用 mTLS 将通讯数据进行加密。mTLS 可以用于确保服务网格中微服务之间的通信安全。它使用加密安全技术相互认证各个微服务并加密它们之间的流量。

虽然可以直接在微服务中定义通信安全策略并执行身份验证和加密,但在每一个微服务中去单独实现相同的功能效率是很低的。而且增加功能还需要改动业务代码,侵入业务逻辑。且即便完成了功能,后期的升级迭代与测试都需要开发者投入额外精力去维护,无法专注于业务功能的开发。

而使用服务网格,我们就可以在不影响原本业务的情况下零感知的为服务提供 mTLS 通信。因为在服务网格中,服务通信相关的功能都被转移至 Sidecar 代理中实现。在整个实现过程中,业务应用都不会受到影响,降低开发者心智负担。

当然,服务网格除了可以实现类似 mTLS 这类的内部流量安全配置功能,通过调整控制面的配置还能快速的拓展包括流量管控,可观测性,协议编解码等更多功能。

文章来自个人专栏
文章 | 订阅
0条评论
作者已关闭评论
作者已关闭评论
0
0