微服务中的Sidecar模式
什么是sidecar
sidecar是服务网络架构的产物。
Sidecar,全称 Sidecar proxy,为在应用程序旁运行的单独的进程,它可以为应用程序添加许多功能,而无需在应用程序中添加额外的第三方组件,或修改应用程序的代码或配置。将应用程序的功能划分为单独的进程运行在同一个最小调度单元中(例如 Kubernetes 中的 Pod)可以被视为 sidecar 模式。在软件架构中, Sidecar 连接到父应用并且为其添加扩展或者增强功能。Sidecar 应用与主应用程序松散耦合。它可以屏蔽不同编程语言的差异,统一实现微服务的可观察性、监控、日志记录、配置、断路器等功能。
sidecar如何工作
Sidecar 代理服务注册发现
下图为异构服务通过sidecar接入注册中心。异构服务本身可能为非Java或传统应用,接入困难。
来自单个服务的所有传入和传出网络流量都流经 Sidecar 代理。因此,Sidecar 能够管理微服务之间的流量,收集遥测数据并实施相关策略。从某种意义上说,该服务不了解整个网络,只知道附加的 Sidecar 代理。
异构服务本身不会和注册中心有请求调用,而是通过sidecar代理注册接入注册中心,获得服务注册、发现等功能。
Sidecar 代理异构服务发起服务调用
异构服务本身不和注册中心有直接联系,所以异构服务的调用也需要走sidecar,通过sidecar进行服务发现调用,sidecar收到异构服务的请求后通过服务发现和负载均衡选中目标服务实例,转发请求至目标服务。
异构服务如何被调用
如果异构服务为服务提供方(会被其它服务调用),服务发起方会先注册中心发现sidecar代理注册的实例信息,将请求发送到Sidecar,Sidecar将请求转发给异构服务完成调用请求。
常见应用
K8s 的pod,Istio,MOSN(兼容Istio,使用Go语言)
以MOSN流量接管为例
假设服务端运行在 1.2.3.4 这台机器上,监听 20880 端口
- 首先服务端会向自己的 Sidecar 发起服务注册请求,告知 Sidecar 需要注册的服务(比如充值服务Deposit)以及 IP + 端口(1.2.3.4:20880)
- 服务端的 Sidecar 会向服务注册中心(如 SOFA Registry)发起服务注册请求,告知需要注册的服务(Deposit)以及 IP + 端口,不过这里需要注意的是注册上去的并不是业务应用的端口(20880),而是 Sidecar 自己监听的一个端口(例如:20881)
- 调用端向自己的 Sidecar 发起服务订阅请求,告知需要订阅的服务信息
- 调用端的 Sidecar 向调用端推送服务地址,这里需要注意的是推送的 IP 是本机,端口是调用端的 Sidecar 监听的端口(例如 20882)
- 调用端的 Sidecar 会向服务注册中心(如 SOFA Registry)发起服务订阅请求,告知需要订阅的服务信息
- 服务注册中心(如 SOFA Registry)向调用端的 Sidecar 推送服务地址(1.2.3.4:20881)
经过上述的服务发现过程,流量转发过程就显得非常自然了:
- 调用端拿到的服务端地址是 127.0.0.1:20882,所以就会向这个地址发起服务调用
- 调用端的 Sidecar 接收到请求后,通过解析请求头,可以得知具体要调用的服务信息,然后获取之前从服务注册中心返回的地址后就可以发起真实的调用(1.2.3.4:20881)
- 服务端的 Sidecar 接收到请求后,经过一系列处理,最终会把请求发送给服务端(127.0.0.1:20880)
使用 sidecar 模式的优势
使用 sidecar 模式部署服务网格时,无需在节点上运行代理,但是集群中将运行多个相同的 sidecar 副本。在 sidecar 部署方式中,每个应用的容器旁都会部署一个伴生容器,这个容器称之为 sidecar 容器。Sidecar 接管进出应用容器的所有流量。
在 Kubernetes 的 Pod 中,在原有的应用容器旁边注入一个 Sidecar 容器,两个容器共享存储、网络等资源,可以广义的将这个包含了 sidecar 容器的 Pod 理解为一台主机,两个容器共享主机资
因其独特的部署结构,使得 sidecar 模式具有以下优势:
- 将与应用业务逻辑无关的功能抽象到共同基础设施,降低了微服务代码的复杂度。
- 因为不再需要编写相同的第三方组件配置文件和代码,所以能够降低微服务架构中的代码重复度。
- Sidecar 可独立升级,降低应用程序代码和底层平台的耦合度。
sidecar和面向切片编程AOP的关系
Sidecar和AOP(面向切片编程,Aspect-Oriented Programming)是两种不同的概念,主要在软件架构和编程范式上有不同的应用,不过它们在某些场景下可以有共同的或类似的目标,例如解耦关注点和增强功能的实现。
- Sidecar:
- 概念: Sidecar是一种微服务架构模式,即在同一个主应用的旁边运行一个独立的守护进程(通常是一个容器),用于辅助主应用实现某些功能,例如日志记录、监控、服务发现、安全等。
- 应用: Sidecar模式常用于服务网格(如Istio)以实现跨应用的基础设施功能,而不需要每个应用服务自行实现这些功能。
- 特点: 提供与应用无缝集成的共享系统服务,通过与应用在同一Pod中运行来实现低延迟和高效通信。
- AOP (Aspect-Oriented Programming):
- 概念: AOP是一种编程范式,旨在通过将关注点(如日志记录、安全性、事务管理等)分离为“方面”(Aspects)来增强编程模块的功能。这些关注点横切系统的多个模块,与其核心业务逻辑分离。
- 应用: AOP通常用于Java(Spring Framework)中,通过使用注解或XML配置来定义方面,以动态代理或代码织入的方式在运行时增强类或者方法。
- 特点: 通过声明的方式在不改变现有代码的情况下向程序添加横切关注点,实现代码解耦和复用。
关系与区别:
- 共同目标:两者都旨在隔离关注点,简化主业务逻辑的实现。同样地,Sidecar和AOP都可以用于增强应用或服务的功能。
- 实现方式:Sidecar通过物理上(或逻辑上,容器模块实现上)分离进程来实现功能扩展,而AOP通过代码层面上的动态增强和代码织入来操作。
- 应用领域:Sidecar更侧重于微服务架构中的基础设施功能,而AOP更适合于应用开发中的代码逻辑关注点分离。
参考
术语表 · Kubernetes 中文指南——云原生应用架构实战手册 (jimmysong.io)
Sidecar 模式 · Kubernetes 中文指南——云原生应用架构实战手册 (jimmysong.io)
什么是 Sidecar[通俗易懂]-腾讯云开发者社区-腾讯云 (tencent.com)
Sidecar Design Pattern in your Microservices Ecosystem – samirbehara
微服务中的 Sidecar 设计模式解析 | 云原生社区(中国) (cloudnative.to).
支持几十种业务场景,字节跳动大规模 Sidecar 运维管理实践-腾讯云开发者社区-腾讯云 (tencent.com)
Sidecar 模式 - failymao - 博客园 (cnblogs.com)