标签:弹性 核心 控制 com 快速 通信 度量 c11 对比
简单来讲,Service Mesh 简化了微服务架构中服务间调用复杂度。
这就涉及到了2个问题:
对于每个微服务,我们可以简单的视为包含2个部分:
其中网络部分是非常复杂的,需要解决很多问题,例如:
每个微服务都需要处理这些网络问题,如果所有微服务都使用同一套语言还好,可以使用一个框架统一解决,但如果使用了多种语言,那么每种语言又需要统一处理一遍。
所以,可以说:
微服务架构中,最复杂的不是构建服务本身,而是处理服务间调用问题。
核心部分说明:
微服务实现自己的业务功能。
虽然很多网络功能都可以统一由 Service Mesh 解决,但有些基础的功能还需要微服务自己来解决。
例如,和 Service Mesh 如何沟通呢?使用 HTTP1.x, gRPC, TCP?
这部分功能通常由开发框架中的网络库来解决。
这部分就是用来解决应用级别通用的网络问题,例如熔断、超时、服务发现 ……。
把这些问题与微服务中的业务代码完全隔离开,开箱即用。
负责管理所有 service mesh 的代理。
例如:
1)访问控制
2)监控
3)服务发现
……
梳理一下 Service Mesh 的核心功能:
非常流行的2个开源实现:
他们的架构都比较简单,实现机制不同。
Service Mesh 把通用的服务调用需要处理的问题都统一处理了,你可以更加专注于服务自身的业务了,也可以放心的使用不同开发语言。
但 Service Mesh 也有不足,首先就是增加了系统整体的复杂度,例如增加了 Sidecar、Control Plane,而且服务间的通信不像以前那么直接了,需要经过代理。还有就是成熟度还不是很高,需要大规模线上应用的磨合完善。
推荐阅读:
标签:弹性 核心 控制 com 快速 通信 度量 c11 对比
原文地址:https://www.cnblogs.com/yogoup/p/12204118.html