service mesh（一）架构发展历史

文章目录

• service mesh（一）架构发展历史
• • 数据面和控制面
  • service mesh架构演变
  • istio
  • • sidecar模式
  • 流量治理
  • • 熔断
    • 限流

数据面和控制面

图中proxy节点是service mesh的数据面，是一个单独的进程，和运行着业务逻辑的service进程部署在同一台机器或者节点上，proxy节点代理流经service进程的所有流量，如执行服务发现，限流，流量治理策略都是通过这个数据面完成的

图中control plane是service mesh的控制面，proxy节点需要执行的路由流量，治理策略都是通过这个控制面下发的

可以看到，数据面和控制面是对业务进程隔离的，即实现了流量治理和业务逻辑解耦

service mesh架构演变

k8s ingress做流量转发

• 可以利用k8s的原生能力实现对进出集群的流量处理，但是无法管理集群内服务间的流量

k8s ingress+route层

• 由于k8s的ingress只能实现对进出集群的流量进行处理，对于集群内服务间的流量则通过在集群内增加route层实现，让集群内所有服务间的流量都通过该路由器，通过该route层对所有流量进行管理

Proxy per Node

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

Sidecar代理/Fabric模型

• 接近service mesh模型，缺少数据面，sidecar需要支持热更新

service mesh最终形态

istio

Istio 作为控制平面，在每个服务中注入一个 Envoy 代理以 Sidecar 形式运行来拦截所有进出服务的流量，同时对流量加以控制

Istio 的组成

• Pilot：服务发现、流量管理
• Mixer：访问控制、遥测
• Citadel：终端用户认证、流量加密

sidecar模式

sidecar模式是istio采用的模式

对于service mesh来说，sidecar就是用于处理进出入业务服务流量的代理节点

在 Kubernetes 的 Pod 中，在原有的应用容器旁边运行一个 Sidecar 容器，可以理解为两个容器共享存储、网络等资源，可以广义的将这个注入了 Sidecar 容器的 Pod 理解为一台主机，两个容器共享主机资源。所有进出应用容器的流量都会被sidecar拦截处理

流量治理

熔断

什么是服务雪崩？一个服务的不可用导致这个服务所在的整条链路服务不可用，称之为服务雪崩

上图是服务雪崩的示例，假设我们的系统由5个服务组成，服务1调用服务2、3，服务3调用服务4、5，但由于某些原因（到达性能极限、未知bug、网络分区等）服务4访问很慢，这时如果没有服务的熔断与降级那么调用者服务3会因为服务4异常而积累过多请求导致产生大量等待的线程（BIO模型），进而服务3也会引发访问慢或中止服务的问题，对其调用服务1也会重复服务3的问题，如此一来，由服务4本身的问题而引发依赖服务的整个链路都出问题，这就是典型的服务雪崩效应。

所以，服务熔断就是指当下游服务因为某种原因变得不可用或者响应过慢或者请求错误数达到一定阈值时，上游服务为了保证自己整体服务的可用性，在一定时间内不再继续调用有问题的下游服务，直接返回，避免请求阻塞等待导致服务资源耗尽崩溃，时间过后会尝试放行部分请求来请求下游服务，如果还有问题，则继续熔断

限流

限流是基于这样的一个事实：Server 在过载状态下，其请求处理的成功率会降低。比如一个 Server 节点正常情况下能够处理 2000 QPS，在过载情况下（假设达到 3000 QPS），这个 Server 就只能处理 1000 QPS 甚至更低。限流可以主动 drop 一些流量，使得 Server 本身不会过载，防止雪崩效应。