嗯,,sidecar就是上面这种。。
特征:
传统形态下,SDK代表着一个特定语言的库、工具包等,由应用程序和微服务框架(比如说dubbo)共处一个进程中,在发布升级中共享生命周期。
serviceMesh下,推荐的是右边的sidecar方案,sidecar方案下没有引入新的功能,调用的拓扑也没有改变,只是改变了原有功能的位置,以独立的应用来存在。大家可以暂时以nginx来理解其网络代理能力也可以。
缺点: 1、从调用方到服务方增加了两次调用,有性能上的损失。(实际上的设计针对这个做优化,物理机上所有应用跟SideCar之间虽然是跨进程,处于不同的JVM应用中,但是它们处于同一台物理机中,故它们之间的调用可以走内核态方式,整体性能的损失可以在1%以内,平均延迟1.5毫秒左右),理论上多一跳的平均性能损耗在1.5毫秒左右; 2、调用复杂度增加,问题排查难度加大
总结: 对于大规模部署微服务,内部服务异构程度高的场景,使用ServiceMesh方案是一个不错的选择。ServiceMesh实现了业务逻辑和控制的解耦,但是也带来了额外的开销,由于网络中多了一次调用,增加了性能的损耗和访问的延迟。同时,由于每个服务(一般每一台物理机) 都需要部署Sidecar,这也会使本来就具有一定复杂度的分布式系统变得更加复杂。尤其是在实施初期,对ServiceMesh的管理和运维会是一个比较棘手的问题。