Mesh: SideCar 是什么?
嗯,,sidecar就是上面这种。。
mesh : 微服务传统形态 和 sidecar形态
特征:
传统形态下,SDK代表着一个特定语言的库、工具包等,由应用程序和微服务框架(比如说dubbo)共处一个进程中,在发布升级*享生命周期。
serviceMesh下,推荐的是右边的sidecar方案,sidecar方案下没有引入新的功能,调用的拓扑也没有改变,只是改变了原有功能的位置,以独立的应用来存在。大家可以暂时以nginx来理解其网络代理能力也可以。
- 在ServiceMesh架构中,给每一个微服务实例部署一个SidecarProxy。该SidecarProxy负责接管对应服务的入流量和出流量,并将微服务架构中的服务订阅、服务发现、熔断、限流、降级、分布式跟踪等功能从服务中抽离到该Proxy中。
- Sidecar以一个独立的进程启动,可以每台宿主机共用同一个Sidecar进程,也可以每个应用独占一个Sidecar进程。所有的服务治理功
能,都由Sidecar接管,应用的对外访问仅需要访问Sidecar即可。当该Sidecar在微服务中大量部署时,这些Sidecar节点自然就形成了一个服务网格。
微服务框架的痛点和改进
-
对于基础架构框架开发者来说存在痛点:面向开发者的模式:新加了功能需要使用框架的应用开发人员配合升级版本,比如要升级maven中的依赖版本号,重新打包发布应用程序,时间上受制于相应的业务应用。业务开发人员相对来说只考虑自身业务稳定等因素,对基础框架的升级具有天然的抗拒心理。
-
使用SideCar模式带来的改进:这个模式的精髓在于实现了数据面(业务逻辑)和控制面的解耦。带来了下面的两个优点:
1、面向运维:解耦了调用业务方和微服务,让它们的具备不同的发布升级的生命周期
2、SideCar作为一个代理,可以完成更多的功能,比如跨语言、限流、负载均衡、灰度、熔断等都可以放到SideCar代理里
缺点:
1、从调用方到服务方增加了两次调用,有性能上的损失。(实际上的设计针对这个做优化,物理机上所有应用跟SideCar之间虽然是跨进程,处于不同的JVM应用中,但是它们处于同一台物理机中,故它们之间的调用可以走内核态方式,整体性能的损失可以在1%以内,平均延迟1.5毫秒左右),理论上多一跳的平均性能损耗在1.5毫秒左右;
2、调用复杂度增加,问题排查难度加大
总结:
对于大规模部署微服务,内部服务异构程度高的场景,使用ServiceMesh方案是一个不错的选择。ServiceMesh实现了业务逻辑和控制的解耦,但是也带来了额外的开销,由于网络中多了一次调用,增加了性能的损耗和访问的延迟。同时,由于每个服务(一般每一台物理机)
都需要部署Sidecar,这也会使本来就具有一定复杂度的分布式系统变得更加复杂。尤其是在实施初期,对ServiceMesh的管理和运维会是一个比较棘手的问题。