服务网格——服务网格架构（概念原理2）

目录

控制平面

数据平面

参考

服务网格的实现模式

Ingress或边缘代理

路由器网格

Proxy per Node

Sidecar代理/Fabric模型

Sidecar代理/控制平面

多集群部署和扩展

Istio 架构解析

---

下图是Conduit Service Mesh（现在已合并到Linkerd2中了）的架构图，这是Service Mesh的一种典型的架构。

图片 - 服务网格架构示意图

服务网格中分为控制平面和数据平面，当前流行的两款开源的服务网格 Istio 和 Linkerd 实际上都是这种构造，只不过 Istio 的划分更清晰，而且部署更零散，很多组件都被拆分，控制平面中包括 Mixer、Pilot、Citadel，数据平面默认是用Envoy；而 Linkerd 中只分为 Linkerd 做数据平面，namerd 作为控制平面。

控制平面

控制平面的特点：

• 不直接解析数据包
• 与控制平面中的代理通信，下发策略和配置
• 负责网络行为的可视化
• 通常提供API或者命令行工具可用于配置版本化管理，便于持续集成和部署

数据平面

数据平面的特点：

• 通常是按照无状态目标设计的，但实际上为了提高流量转发性能，需要缓存一些数据，因此无状态也是有争议的
• 直接处理入站和出站数据包，转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等
• 对应用来说透明，即可以做到无感知部署

参考

• 企业级服务网格架构之路解读

服务网格的实现模式

我们在前面看到了通过客户端库来治理服务的架构图，那是我们在改造成Service Mesh架构前使用微服务架构通常的形式，下图是使用Service Mesh架构的最终形式。

图片 - Service Mesh 架构示意图

当然在达到这一最终形态之前我们需要将架构一步步演进，下面给出的是参考的演进路线。

Ingress或边缘代理

如果你使用的是Kubernetes做容器编排调度，那么在进化到Service Mesh架构之前，通常会使用Ingress Controller，做集群内外流量的反向代理，如使用Traefik或Nginx Ingress Controller。

图片 - Ingress 或边缘代理架构示意图

这样只要利用Kubernetes的原有能力，当你的应用微服务化并容器化需要开放外部访问且只需要L7代理的话这种改造十分简单，但问题是无法管理服务间流量。

路由器网格

Ingress或者边缘代理可以处理进出集群的流量，为了应对集群内的服务间流量管理，我们可以在集群内加一个Router层，即路由器层，让集群内所有服务间的流量都通过该路由器。

图片 - 路由器网格架构示意图

这个架构无需对原有的单体应用和新的微服务应用做什么改造，可以很轻易的迁移进来，但是当服务多了管理起来就很麻烦。

Proxy per Node

这种架构是在每个节点上都部署一个代理，如果使用Kubernetes来部署的话就是使用DaemonSet对象，Linkerd第一代就是使用这种方式部署的，一代的Linkerd使用Scala开发，基于JVM比较消耗资源，二代的Linkerd使用Go开发。

图片 - Proxy per node 架构示意图

这种架构有个好处是每个节点只需要部署一个代理即可，比起在每个应用中都注入一个sidecar的方式更节省资源，而且更适合基于物理机/虚拟机的大型单体应用，但是也有一些副作用，比如粒度还是不够细，如果一个节点出问题，该节点上的所有服务就都会无法访问，对于服务来说不是完全透明的。

Sidecar代理/Fabric模型

这个一般不会成为典型部署类型，当企业的服务网格架构演进到这一步时通常只会持续很短时间，然后就会增加控制平面。跟前几个阶段最大的不同就是，应用程序和代理被放在了同一个部署单元里，可以对应用程序的流量做更细粒度的控制。

图片 - Sidecar代理/Fabric模型示意图

这已经是最接近Service Mesh架构的一种形态了，唯一缺的就是控制平面了。所有的sidecar都支持热加载，配置的变更可以很容易的在流量控制中反应出来，但是如何操作这么多sidecar就需要一个统一的控制平面了。

Sidecar代理/控制平面

下面的示意图是目前大多数Service Mesh的架构图，也可以说是整个Service Mesh架构演进的最终形态。

图片 - Sidecar 代理/控制平面架构示意图

这种架构将代理作为整个服务网格中的一部分，使用Kubernetes部署的话，可以通过以sidecar的形式注入，减轻了部署的负担，可以对每个服务的做细粒度权限与流量控制。但有一点不好就是为每个服务都注入一个代理会占用很多资源，因此要想方设法降低每个代理的资源消耗。

多集群部署和扩展

以上都是单个服务网格集群的架构，所有的服务都位于同一个集群中，服务网格管理进出集群和集群内部的流量，当我们需要管理多个集群或者是引入外部的服务时就需要网格扩展和多集群配置。

 

Istio 架构解析

下面是以漫画的形式说明 Istio 是什么。

 

 

该图中描绘了以下内容：

• Istio 可以在虚拟机和容器中运行
• Istio 的组成
  • Pilot：服务发现、流量管理
  • Mixer：访问控制、遥测
  • Citadel：终端用户认证、流量加密
• Service mesh 关注的方面
  • 可观察性
  • 安全性
  • 可运维性
• Istio 是可定制可扩展的，组建是可拔插的
• Istio 作为控制平面，在每个服务中注入一个 Envoy 代理以 Sidecar 形式运行来拦截所有进出服务的流量，同时对流量加以控制
• 应用程序应该关注于业务逻辑（这才能生钱），非功能性需求交给 Service Mesh