Dubbo偶遇Service Mesh，开发简单强如怪物，拼尽全力无法战胜

湫qiu
306 阅读5分钟

服务演化

单体 --> 微服务

image.png

为了高可用，一个服务至少部署两个实例。左侧是单体架构，右侧是微服务架构。

左侧需要网关（nginx）进行负载均衡，动态扩容只需修改nginx配置文件

右侧 进程内函数调用变成了进程间远程调用，所以在进行调用的时候需要知道ip+port

没有什么事是加一层解决不了的

image.png 为了高可用，rpc需要服务发现。动态扩容需要有注册中心支持（也可以修改每个service的配置文件？有人会这么做吗）

dubbo/spring cloud 的思路就是通过注册中心进行服务发现，再进行rpc， 同时还要接入各种框架（Eureka、Ribbon、Hystrix、Sleuth）实现负载均衡，降级熔断，链路追踪。

微服务再升级

SpringCloud/Dubbo的劣势

  • 程序员们仍然需要正确理解和使用这些库（Eureka、Ribbon、Hystrix、Sleuth），上手成本和出错概率依然很高。
  • 限制技术选择：使用这些技术后，应用很容易就会被对应的语⾔和框架强绑定

于是CloudNative带着Service Mesh来了

Service Mesh

Service Mesh 特点

  • 基础设施（中间件）。
  • 处理服务与服务之间的通讯。
  • 让服务间的请求传递变得可靠。
  • 云原生应用。
  • 网络代理。
  • 跟应用部署在一起。

有了Service Mesh，程序可以专注于业务，而服务发现，负载均衡，降级熔断，链路追踪可以给Service Mesh做，甚至还可以做灰度发布，链路加密mTLS

那么Service Mesh是怎么做到的呢？简单来说，Service Mesh 就是通过 Sidecar模式 ，将上述类库和框架要干的事情从应用中彻底剥离了出来，并统一下沉到了基础设施层。

image.png

很符合我的CS的印象，没有什么事是加一层解决不了的，如果有就再加一层。

因为Service Mesh是一个单独的服务，业务端还可以用多种语言书写，接入Service Mesh即可，无需多学习不同语言的微服务框架。

目前最流行的Service Mesh是Istio

所以

  • SpringBoot + Istio ≈ Spring Cloud
  • gin + Istio + gRPC ≈ Spring Cloud

当然也都是要注册服务的，不然Istio发现不了，可以注册到k8s，也可以用注册中心

Sidecar

image.png Sidecar 模式是一种设计模式，它将应用的功能模块从主应用中分离出来，放到一个独立的进程（也就是 Sidecar 容器，在容器化场景下很常见）中运行，这个 Sidecar 进程和主应用进程共享网络等资源，并且可以对主应用的输入输出进行拦截、处理等操作，比如可以负责服务发现、配置管理、日志收集、流量监控等功能，为主应用提供额外的能力支持，而不需要对主应用自身的代码进行大量修改。

Service Mesh vs Gateway

这是我在学习时的疑问，因为这两个的功能实在是有点像

Service MeshAPI Gateway
专注于服务间通信的治理，解决微服务之间的通信问题（如服务发现、负载均衡、流量管理、安全等）。专注于南北向流量的管理，作为外部客户端与内部服务之间的入口，处理外部请求。
主要处理东西向流量（即服务之间的流量）。主要处理南北向流量（即外部客户端到服务的流量）。
适用于微服务架构内部的服务间通信治理。适用于为外部客户端提供统一的API入口。
通常以Sidecar代理的形式部署在每个微服务旁边，透明地处理服务间通信。通常部署在微服务集群的边缘，作为外部请求的入口。
- Istio - Linkerd - Consul Connect- Kong - Nginx - Spring Cloud Gateway

只能说他们都是 network proxy 但是他们专注的点不一样

Service Mesh 和 RPC 的关系

Service Mesh 和 RPC 结合使用：

  • Service Mesh 负责服务间通信的治理（如流量管理、安全、可观测性）。
  • RPC 负责高效的服务间通信和数据传输。
Service MeshRPC
解决微服务间通信的治理问题，适用于大规模、复杂的微服务架构。解决服务间高效通信的问题，适用于高性能、低延迟的场景。
是一个基础设施层，不绑定具体协议。

Istio

简单讲一下Istio的架构

image.png

在 Istio 中，Pilot、Citadel、Galley 和 Envoy 是四个核心组件，上图中的proxy就是Envoy

Envoy
  • Envoy 是数据平面（Data Plane）的代理，负责实际的流量管理。
Pilot
  • Pilot 是控制平面（Control Plane）的组件，负责将流量管理规则（如路由、负载均衡、服务发现等）下发到 Envoy 边车代理。
Citadel
  • Citadel 是负责安全性的组件，用于管理证书和密钥，实现服务间的双向 TLS（mTLS）加密和身份验证。
Galley
  • Galley 是配置管理组件，负责验证、转换和分发 Istio 的配置（如 VirtualService、DestinationRule 等）到其他控制平面组件（如 Pilot）。

总结？

我现在的项目用的是公司自研？的一套类似Istio的边车服务，有金丝雀发布，协议转换，流量控制，负载均衡等功能，随便拉菜鸡一个实习生（没错就是我）只需要会SpringBoot，就可以开发业务，可以开发RPC接口，还可以随时被优化（/(ㄒoㄒ)/~~）。

avatar
文章
阅读
粉丝