微服务边车模式深度解析：赋能云原生应用的终极指南（自己搞一个简单SideCar？）

什么是SideCar?

file

Sidecar模式定义：

Sidecar 模式是一种常用于微服务架构中的设计模式，该模式允许将应用程序的核心功能与辅助功能（如日志记录、监控、配置管理、网络通信等）分离开来。在这种设计模式中，每个微服务主容器旁边都有一个“边车”（Sidecar）容器运行辅助功能，就像摩托车旁的边车一样，Sidecar 容器和主容器共享同一个生命周期和网络空间。

你专心开车，其他交给我。

file

整体Sidecar就是这样：

file

总结：把非核心业务杂七杂八的东西分离出来，微服务的关注点尽可能只在业务上面，减少业务开发的复杂度。

Sidecar主要干啥？

Sidecar模式通常会处理以下范围的功能：

网络通信：
- 代理和管理微服务之间的通信，例如用来处理进出的网络流量、服务发现、负载均衡、断路、重试和超时。
安全性：
- 实现安全协议，如TLS加密、认证、授权和密钥管理。
监控与日志记录：
- 收集和导出日志、性能度量指标和追踪信息，以供监控系统使用。
配置管理：
- 动态加载和管理配置数据，而无需重启应用程序。
故障处理和调试：
- 提供调试支持，记录崩溃报告和性能瓶颈。
健康检查：
- 周期性地检查主服务的健康，并可实施自我修复措施。
API 网关或接口转换：
- 处理服务的REST或gRPC API，提供API网关功能，或者对老旧系统进行接口转换。
服务依赖抽象：
- 管理服务间的数据库连接、队列等系统资源的访问。
请求/响应转换：
- 对进出的请求或响应数据进行转换或扩展。

Sidecar有哪些实现？

Sidecar在容器化和微服务领域有很多实现：

1. Envoy

Envoy是一个开源的、高性能的边缘和服务代理，专门设计用于云原生应用环境。由Lyft公司首次开发发布，后来成为了Cloud Native Computing Foundation（CNCF）的一部分。它的设计允许它同时在应用程序的边缘和内部使用，作为边缘网关、负载均衡器或服务网格的一部分，以提高微服务之间的通信质量和效率。

file

Istio
Istio是一个开源的服务网格，用于连接、保护、控制和观察在Kubernetes集群中运行的服务。它为微服务提供一种统一的方式来管理网络通信，安全性，策略和观察性，无需改变应用本身的代码。Istio利用了Envoy代理，它作为Sidecar部署在每个服务的Pod中，拦截所有进出Pod的网络通信。
Linkerd
Linkerd是一个开源的服务网格，专门为云原生应用设计，用以在微服务架构中提供可靠的服务间通信。它提供关键功能，如服务发现、负载均衡、故障处理、请求路由和安全性，在不改动服务代码的情况下，使得服务更容易监控、管理和控制。Linkerd是由Buoyant公司开源的，并且是Cloud Native Computing Foundation（CNCF）的一部分。
…

自己搞一个简单的？

我们个人势单力薄，搞一个像他们这么有高级功能的组件还是挺费时间的，况且我们还在温饱线上挣扎。

但是又想在这块搞点小事情，那么整个简单的。

先来个简单的需求

一个业务系统部署在k8s集群中，每个服务采用一个Pod一个服务的方式部署，每个Pod都有一个Service。

file

就这么简单来一下就可以了，Service关联Pod提供统一访问入口。

那根据SideCar的拓扑，我们可以在Service和Pod中容器之间加一个Sidecar来管理流量，像这样：

file

在这个拓扑中，所有流量先进SVC（逻辑上哈），然后转发给车最后转发给Pod。

车的具体需求？

管理HTTP流量（TCP的暂时不支持）：只开发一个IP白名单规则。如果请求这个服务的IP不在这个白名单中，则返回404，否则转发该请求。
白名单规则配置：支持单个IP地址，支持CIDR地址。

需求就是这么简单，我们让SVC把流量先转给车，车处理了一下以后再转发给业务服务。

准备开干

首先开发一个HTTP服务器

使用Go built-in API就可以很简单开发实现一个HTTP服务器,就是使用net包：

http.HandleFunc("/", handler)err = http.ListenAndServe(conf.Server.Addr, nil)if err != nil {log.Fatal("ListenAndServe: ", err)}

COPY

几行代码搞定，额，这还是有点快，让人猝不及防。那这样我们的HTTP服务器就搞定了

其次读取配置文件

我们用yaml来定义白名单配置，白名单中有IP和CIDR地址。


whitelist:- 192.168.1.1- 192.168.1.2- 10.22.81.0/24- ::1

COPY

然后我们使用yaml解析库来读取它。

先来下载一下依赖库：


go get gopkg.in/yaml.v2

COPY

然后使用库提供的api来读取yaml文件：


type Conf struct {Server     Server     `yaml:"server"`Downstream Downstream `yaml:"downstream"`Whitelist  []string   `yaml:"whitelist"`
}err = yaml.Unmarshal(source, &conf)if err != nil {log.Panic(err)}

COPY

设置HTTP的请求处理函数

我们请求处理函数从X-FORWARDED-FOR协议头来获取请求的Ip列表字符串，字符串以ip1,ip2,ip3,...来组成的。

我们只取第一个,就是上面示例的ip1，因为只有这个IP才表示请求方的IP，其他都是代理方的。

func handler(w http.ResponseWriter, r *http.Request) {ipStr := r.Header.Get("X-FORWARDED-FOR")if ipStr == "" {ipStr = strings.Split(r.RemoteAddr, ":")[0]} else {ipStr = strings.TrimSpace(strings.Split(ipStr, ",")[0])}// 如果IP地址在白名单中，那么就转发请求if ipInWhitelist(ipStr, conf.Whitelist) {serveReverseProxy(conf.Downstream.URL, w, r)return}// 否则返回404http.NotFound(w, r)
}

COPY

转发请求

Go内建包net实现了ReverseProxy,我们直接使用httputil.NewSingleHostReverseProxy就可以直接转发HTTP请求，很快~。


func serveReverseProxy(target string, w http.ResponseWriter, r *http.Request) {url, _ := url.Parse(target)proxy := httputil.NewSingleHostReverseProxy(url)r.URL.Host = url.Hostr.URL.Scheme = url.Schemer.Header.Set("X-Forwarded-Host", r.Header.Get("Host"))r.Host = url.Hostproxy.ServeHTTP(w, r)
}

COPY

这样我们的核心功能就实现了。

一点小细节

实现了核心流程以后，我们还得关注配置中IP的解析。
Go的net 包也提供了IP地址和CIDR地址的解析，我们只需要调用一下

net.ParseIP
net.ParseCIDR
就可以实现IP解析了。

transformToCIDR 这个函数就给IP地址增加/32转换成CIDR形式，大家可以不用太关注。


func ipInWhitelist(ipStr string, whitelist []string) bool {ip := net.ParseIP(ipStr)for _, cidr := range whitelist {_, ipNet, err := net.ParseCIDR(transformToCIDR(cidr))if err != nil {return false}if ipNet.Contains(ip) {return true}}return false
}

COPY

部署

开发这个简单的需求一百多行代码就可以搞定了，但是部署怎么办?

我们在k8s中不是有Service嘛，我们Service在配置流量转发规则的时候先转到我们的HTTP Server，然后我们HTTP再转发给业务服务。

Pod改造

原来我们的拓扑是这样的：

file

加上我们自己的sidecar就变成这样了：

file

随之而来的改造

k8s Pod支持一个Pod多个Container，所以我们可以直接在Pod中增加一个Container：
比如：原来我们的Pod定义是这样的：

- name: my-order-appimage: my-registry-domain-name/ my-order-app:${my-order-app-version}imagePullPolicy: IfNotPresentports:- containerPort: 8080

COPY

改造后：

containers:- name: sidecarimage: my-registry-domain-name/my-custom-sidecar:latestimagePullPolicy: Alwaysports:- containerPort: 8081- name: my-order-appimage: my-registry-domain-name/ my-order-app:${my-order-app-version}imagePullPolicy: IfNotPresentports:- containerPort: 8080

COPY

Pod的改造就完成了，接下来就是Service改造了。

Service改造

我们要把Service的目标端口改成我们自己的Sidecar应用才可以。

比如：原来我们的Service是这样的：
Service端口为8080，转发到app的8080端口中。


apiVersion: v1
kind: Service
metadata:name: my-order-app-servicenamespace: my-applabels:app: my-order-app
spec:ports:- name: my-order-httpport: 8080protocol: TCPtargetPort: 8080selector:app: my-order-apptype: ClusterIP

COPY

现在我们要把Target改成8081,也就是我们的Sidecar HTTP服务器端口。


apiVersion: v1
kind: Service
metadata:name: my-order-app-servicenamespace: my-applabels:app: my-order-app
spec:ports:- name: my-order-httpport: 8080protocol: TCPtargetPort: 8081selector:app: my-order-apptype: ClusterIP

COPY

这样我们的Sidecar就搞定了。

总结

通过使用Sidecar模式，我们能够实现对微服务架构的强化，也就是关注点分离，让你专注于开车，开好车，开快车。
它提供了一种有效的方式去分摊微服务的辅助功能（如日志记录、监控、配置管理、网络通信等），而无需改动微服务的核心业务逻辑。这带来了显著的优点，包括简化开发复杂度、增强服务的可维护性和可伸缩性，以及提供了横切关注点（cross-cutting concerns）的统一管理。

优点

关注点分离：通过将非核心功能从应用程序逻辑中分离出来，开发者可以更专注于业务逻辑。
可插拔性：Sidecar可以独立于应用程序部署和更新，使得维护工作更加灵活。
一致性：在多个服务中应用相同的配置和策略，不需要在每个服务上单独配置。
扩展性：新增功能时，可以在不影响现有服务的情况下，在Sidecar中添加新的组件。
增强的能力：例如，集中日志处理、安全性控制、以及动态路由等。

缺点（Sidecar的通病）:

资源使用：每个Sidecar都会消耗额外的计算和内存资源，这可能导致资源的浪费。
复杂性：虽然单个服务的复杂性降低了，但整体架构可能会因为增加的组件而变得复杂。
调试困难：由于Sidecar模式涉及多个容器协同工作，调试和追踪问题可能比传统单体应用更加困难。
网络延迟：每个请求都要通过Sidecar代理，可能会增加网络延迟。