架构设计内容分享(六十八)：云原生 Service Mesh 的 2 大宏观架构

目录

如何做架构解耦呢？

第1大模式：Sidecar(边车)模式架构

sidecar的（边车）负责的功能

sidecar模式好处、坏处

如何解决依赖的复杂性和性能问题呢？

优化之后的sidecar模式优点：

第2大模式：代理模式

Mesh中Sidecar分体架构与微服务Provider一体架构对比

在微服务实例维度的对比

两大基础组件的对比

sidecar 对应到啥组件？

小结：

---

要穿透 云原生 Service Mesh（服务网格），首先要理解 其宏观架构模式。

在宏观架构模式上，云原生 Service Mesh（服务网格）的核心思想，就是进行微服务Provider 的架构解耦。

如何做架构解耦呢？

具体来说，把 SpingCoud 框架下的 单个服务实例 ，一分为二，解耦成两个服务：

• Sidecar服务   （非 业务服务）

• 纯业务  服务  （原生业务服务）

为了实现分布式、大规模服务治理，云原生 Service Mesh（服务网格）宏观架构，主要涉及两大模式：

• Sidecar （边车）模式

• Poxy 代理模式

明白了以上两大架构模式， 云原生 Service Mesh（服务网格）就理解了60%。

第1大模式：Sidecar(边车)模式架构

Sidecar边车～挎斗摩托车!

为什么称为Sidecar模式，是因为它类似于连接在摩托车旁的边车。

Sidecar模式：

Sidecar模式 把整个微服务（如SpringCloud微服务）  进行服务实例的架构解耦，一分为二，分为两个服务

• sidecar服务  （链路跟踪、负载均衡、熔断降级、性能检测、服务治理）

• 主应用服务  （业务服务）

在部署维度，如果使用container 容器模式部署，那么也就变成两个容器:

• 一个独立的container,  负责部署 业务服务

• 一个独立的sidecar服务,   负责部署 链路跟踪、负载均衡、熔断降级、性能检测、服务治理 等  支撑服务。

 

在该模式中，附加的sidecar服务被主应用程序中，并为应用程序提供其所支持的特性。

sidecar服务与 业务服务 同生共死，相濡以沫：

sidecar与主应用程序有相同的生命周期，与主应用程序一起创建和退出。

sidecar模式有时被称为sidekick模式，它是一种分解模式。

sidecar模式还允许应用程序由异构组件和技术实现。

sidecar的（边车）负责的功能

应用程序和服务通常需要一些相关的基础功能，如：

• 流量代理

• 性能监控、

• 日志、

• 配置

• 限流、

• 降级

• 链路跟踪

• 等等

这些基础功能可以作为独立的组件或服务实现。

可以直接集成到应用程序中，与应用程序在相同的进程中运行，从而有效地利用共享资源。

也如果将应用程序分解，独立为不同进程，独立运行。

sidecar模式好处、坏处

解耦之后的好处：

• 可以使用不同的语言和技术实现sidecar。

  在运行时环境和编程语言方面独立于它的主应用程序，因此您不需要为每种语言开发一个sidecar。

• 相互之间更好的隔离，其中一个组件的中断可能会影响其他组件或整个应用程序。

• “非侵入式框架” ，“侵入式框架” 是业务代码和 服务治理SDK/Agent等非业务代码耦合在一起，sidecar模将业务代码和 服务治理SDK/Agent等非业务代码解耦，属于 “非侵入式框架”

解耦之后的坏处：

• 每个组件都有自己的依赖项，并且需要特定于语言的库来访问底层平台,并与主应用程序共享的任何资源。

• 在WEB应用中，增加了一次请求和响应的中转，会增加应用程序的延迟。

• 管理这些特定于语言的接口的代码和依赖关系也会增加相当大的复杂性，特别是对于服务托管、部署和管理。

如何解决依赖的复杂性和性能问题呢？

很简单，

就是伴随式部署，将这些基础程序和应用程序绑定在一起部署，

只是由一个限定：二者 使用独立的进程或容器部署。

 

sidecar服务不一定是应用程序的一部分，但它会连接到应用程序。

业务程序部署到哪里，sidecar服务 就部署到哪里。

Sidecars是支持与主应用程序一起部署的流程或服务。

在摩托车上，边车与一辆摩托车相连，每辆摩托车都可以有自己的边车。

以同样的方式，sidecar服务和其主应用程序具有相同的生命周期。

对于应用程序的每个实例，sidecar的一个实例被部署和托管在它旁边。

如何解决性能问题呢？

因为sidecar 靠近主应用程序，所以在它们之间没有实质的网络IO，通信不会有明显的延迟

性能问题，基本就解决了。

优化之后的sidecar模式优点：

• 在运行时环境和编程语言方面独立于它的主应用程序，因此您不需要为每种语言开发一个sidecar。

• sidecar可以访问与主应用程序相同的资源。例如，可以监控自己和主应用程序所使用的系统资源。

• 因为它靠近主应用程序，所以在它们之间通信时没有明显的延迟。

• 即使对于不提供可扩展性机制的应用程序，也可以使用sidecar来扩展功能，方法是将sidecar作为自己的进程附加到主应用程序所在的主机或子容器中。

sidecar模式经常与容器一起使用，并被称为sidecar容器或sidekick容器。

第2大模式：代理模式

sidecar角色的一个核心功能，就行进行 请求的拦截和代理，或者说 流量代理。

流量代理 就是 类似于 Nginx 的 请求代理。

通过类似反向代理的形式，在 客户端和 业务服务的中间，  横插一脚，

具体来说：

由 sidecar 拦截 client 到 业务服务中间的 请求进行转发，以及  拿到响应结果，再转发给 client

所以，在WEB应中，sidecar提供类似反向代理的角色。

Mesh中Sidecar分体架构与微服务Provider一体架构对比

在微服务实例维度的对比

微服务的一个服务实例provider，变成了两个服务实例，

• 一个 原生的业务服务，

• 一个 sidecar 伴随式服务

两大基础组件的对比

在SpringCloud 框架中

• nacos：提供服务发现功能和路由规则

• sentinel：策略控制，比如：服务调用速率限制

在istio 服务网格 （service）框架中：

• Pilot：提供服务发现功能和路由规则

• Mixer：策略控制，比如：服务调用速率限制

在注册中心配置中心、 限流熔断这块，微服务和 Service Mesh的对比

sidecar 对应到啥组件？

sidecar  是一种模式和角色，并不是一个 组件。

对应的例子是，比如 Ribbon 是组件，但是其角色是 balance 负载均衡。

那么，在云原生框架中，sidecar 对应到啥组件？ 不同的 云原生 框架， 其组件的名称不同。

在istio框架中，sidecar角色所对应的组件，叫做  envoy ，

envoy  意思是特使、使者、使节、 (谈判等的)代表，

envoy  的主要功能，粗的来说，就是两个：

• 反向代理

• 一大堆服务治理监控组件的 sdk/agent

envoy  的示意图，如下：

 

小结：

要穿透 云原生 Service Mesh（服务网格），首先要理解 其宏观架构模式。

在宏观架构模式上，云原生 Service Mesh（服务网格）框架的核心，就是进行微服务Provider 的架构解耦。

为了实现分布式、大规模服务治理，云原生 Service Mesh（服务网格）宏观架构，在宏观上，主要涉及两大模式：

• Sidecar （边车）模式

• Poxy 代理模式

明白了以上两大架构模式， 云原生 Service Mesh（服务网格）的原理和实操，其实，就是非常轻松和越快了。