微服务中的Sidecar模式

微服务中的Sidecar模式

引用

CSDN

1.

https://blog.csdn.net/weixin_45770491/article/details/141325992

Sidecar模式是微服务架构中一种重要的设计模式，它通过在应用程序旁边运行一个单独的进程，为应用程序添加各种功能，而无需修改应用程序的代码或配置。本文将详细介绍Sidecar模式的工作原理、应用场景及其优势，并探讨Sidecar与面向切面编程（AOP）的关系。

什么是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端口

1. 首先服务端会向自己的Sidecar发起服务注册请求，告知Sidecar需要注册的服务(比如充值服务Deposit)以及IP+端口（1.2.3.4:20880）
2. 服务端的Sidecar会向服务注册中心（如SOFA Registry）发起服务注册请求，告知需要注册的服务(Deposit)以及IP+端口，不过这里需要注意的是注册上去的并不是业务应用的端口（20880），而是Sidecar自己监听的一个端口（例如：20881）
3. 调用端向自己的Sidecar发起服务订阅请求，告知需要订阅的服务信息
4. 调用端的Sidecar向调用端推送服务地址，这里需要注意的是推送的IP是本机，端口是调用端的Sidecar监听的端口（例如20882）
5. 调用端的Sidecar会向服务注册中心（如SOFA Registry）发起服务订阅请求，告知需要订阅的服务信息
6. 服务注册中心（如SOFA Registry）向调用端的Sidecar推送服务地址（1.2.3.4:20881）

经过上述的服务发现过程，流量转发过程就显得非常自然了：

1. 调用端拿到的服务端地址是127.0.0.1:20882，所以就会向这个地址发起服务调用
2. 调用端的Sidecar接收到请求后，通过解析请求头，可以得知具体要调用的服务信息，然后获取之前从服务注册中心返回的地址后就可以发起真实的调用（1.2.3.4:20881）
3. 服务端的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）是两种不同的概念，主要在软件架构和编程范式上有不同的应用，不过它们在某些场景下可以有共同的或类似的目标，例如解耦关注点和增强功能的实现。

1. Sidecar:

• 概念: Sidecar是一种微服务架构模式，即在同一个主应用的旁边运行一个独立的守护进程（通常是一个容器），用于辅助主应用实现某些功能，例如日志记录、监控、服务发现、安全等。
• 应用: Sidecar模式常用于服务网格（如Istio）以实现跨应用的基础设施功能，而不需要每个应用服务自行实现这些功能。
• 特点: 提供与应用无缝集成的共享系统服务，通过与应用在同一Pod中运行来实现低延迟和高效通信。

2. AOP (Aspect-Oriented Programming):

• 概念: AOP是一种编程范式，旨在通过将关注点（如日志记录、安全性、事务管理等）分离为“方面”（Aspects）来增强编程模块的功能。这些关注点横切系统的多个模块，与其核心业务逻辑分离。
• 应用: AOP通常用于Java（Spring Framework）中，通过使用注解或XML配置来定义方面，以动态代理或代码织入的方式在运行时增强类或者方法。
• 特点: 通过声明的方式在不改变现有代码的情况下向程序添加横切关注点，实现代码解耦和复用。

关系与区别:

• 共同目标：两者都旨在隔离关注点，简化主业务逻辑的实现。同样地，Sidecar和AOP都可以用于增强应用或服务的功能。
• 实现方式：Sidecar通过物理上（或逻辑上，容器模块实现上）分离进程来实现功能扩展，而AOP通过代码层面上的动态增强和代码织入来操作。
• 应用领域：Sidecar更侧重于微服务架构中的基础设施功能，而AOP更适合于应用开发中的代码逻辑关注点分离。