微服务中的Sidecar模式

什么是sidecar
sidecar如何工作
- [Sidecar 代理服务注册发现](#Sidecar 代理服务注册发现)
- [Sidecar 代理异构服务发起服务调用](#Sidecar 代理异构服务发起服务调用)
- 异构服务如何被调用
常见应用
以MOSN流量接管为例
[使用 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 端口

首先服务端会向自己的 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)