Service Mesh 翻译为“服务网格”,作为服务间通信的基础设施层。轻量级高性能网络代理,提供安全的、快速的、可靠地服务间通讯,与实际应用部署一起,但对应用透明。应用作为服务的发起方,只需要用最简单的方式将请求发送给本地的服务网格代理,然后网格代理会进行后续的操作,如服务发现,负载均衡,最后将请求转发给目标服务。
Service Mesh 目的是解决系统架构微服务化后的服务间通信和治理问题。 服务网格由 Sidecar 节点组成,这个模式的精髓在于实现了数据面(业务逻辑)和控制面的解耦。具体到微服务架构中,即给每一个微服务实例同步部署一个 Sidecar。
在 Service Mesh 部署网络结构图中,绿色方块为应用服务,蓝色方块为 SideCar,应用服务之间通过 Sidecar 进行通信,整个服务通信形成图中的蓝色网络连线,图中所有蓝色部分就形成了 Service Mesh。其具备如下主要特点:
从上述 Service Mesh 的定义看:
综合上述,Service Mesh 主要解决用户如下 3 个维度的痛点需求:
通过将微服务通信下沉到基础设施层,屏蔽了微服务处理各种通信问题的复杂度,形成微服务之间的抽象协议层。开发者无需关心通信层的具体实现,也无需关注 RPC 通信(包含服务发现、负载均衡、流量调度、流量降级、监控统计等)的一切细节,真正像本地调用一样使用微服务,通信相关的一起工作直接交给 Service Mesh。
功能上,Service Mesh 并没有提供任何新的特性和能力,Service Mesh 提供的所有通信和服务治理能力在 Service Mesh 之前的技术中均能找到,比如 Spring Cloud 就实现了完善的微服务 RPC 通信和服务治理支持。
Service Mesh 改变的是通信和服务治理能力提供的方式,通过将这些能力实现从各语言业务实现中解耦,下沉到基础设施层面,以一种更加通用和标准化的方式提供,屏蔽不同语言、不同平台的差异性,有利于通信和服务治理能力的迭代和创新,使得业务实现更加方便。
Service Mesh 避免了多语言服务治理上的重复建设,通过 Service Mesh 语言无关的通信和服务治理能力,助力于多语言技术栈的效率提升。
通过标准化,带来一致的服务治理体验,减少多业务之间由于服务治理标准不一致带来的沟通和转换成本,提升全局服务治理的效率。
Service Mesh 的核心是数据平面 Sidecar 与控制平面 Control Plane,如下图:
数据平台可以认为是将 Spring Cloud、Dubbo 等相关的微服务框架中通信和服务治理能力独立出来的一个语言无关的进程,并且更注重通用性和扩展性。在 Service Mesh 中,不再将数据平面代理视为一个个独立的组件,而是将这些代理连接在一起形成一个全局的分布式网格。
在传统的微服务架构中,各种服务框架的功能(如,服务发现、负载均衡、限流熔断等)代码逻辑或多或少的都需要耦合到服务实例的代码中,给服务实例增加了很多无关业务的代码,同时带来了一定的复杂度。
有了 SideCar 之后,服务节点只做业务逻辑自身的功能,服务之间的调用只需交给 SideCar,由 SideCar 完成注册服务、服务发现、请求路由、熔断限流、日志统计等业务无关功能。
在这种新的微服务架构中,所有的 SideCar 组成在一起,就形成了服务网格。那么这个大型的服务网格并不是完全自治的,它还需要一个统一的控制节点 Control Plane。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。