前言
接触 servicemesh 有一段时间了，越来越觉得这个东西在当前场景下是个可有可无的东西。
于是问了下 GPT ，servicemesh 解决了啥问题，以下是他的回答以及我的想法：
1.服务发现和负载均衡
在微服务架构中，服务实例可能会动态增加或减少。Service Mesh 负责服务发现和负载均衡，确保请求能够被路由到健康的实例上。
事实上，公司里有非常可靠的注册中心（独立团队维护），这个部分根本用不到 Service Mesh 。
2.安全性
Service Mesh 提供了服务间通信的安全性，包括加密、认证和授权。例如，它可以通过 mTLS （ Mutual TLS ）来确保服务间通信的加密和身份验证。
事实上，公司里使用很多私有协议，而且安全这块也有单独的团队。
3.可观察性
Service Mesh 提供了对服务间通信的详细监控和跟踪，包括请求的延迟、错误率和流量分布等。这有助于快速诊断和解决问题。
这个我理解，常规的分布式链路工具就能做这个
4.流量管理
Service Mesh 可以实现复杂的流量管理策略，例如熔断、限流、重试和超时等。这有助于提高系统的稳定性和可靠性。
熔断限流或许可以，但是流量代理私自做重试显然会有潜在幂等性等问题，没必要放在这里做
5.故障注入和测试
Service Mesh 允许在生产环境中进行故障注入和测试，以验证系统的鲁棒性和容错能力。这有助于提前发现潜在问题。
这一块了解不多，但是我理解 Service mesh 能过的故障注入应该很有限，Linux 有成熟的网络注入工具 TC ，公司里有很成熟的故障注入工具，包括但不限于网络故障注入
6.策略管理
Service Mesh 提供了一个集中化的地方来管理和应用各种策略，例如安全策略、流量管理策略和访问控制策略等。
算优点吧，但也是致命的缺点，当前应用规模非常大，Istio 的控制面就算抗的住，一旦 Crash 问题影响很大
7.平台无关性
Service Mesh 独立于应用代码，这意味着你可以在不同的编程语言和框架中使用它，而无需修改代码。这使得它特别适合多语言、多框架的微服务环境。
这一点比较困惑，只要预定好通信协议，应该就没有这个问题。Service Mesh 顶多就是做协议转换，事实上，公司里开发基座基本是统一的，协议转换完全可以在基座中实现。
综上所述，Service Mesh 在上述提到的场景里，完全没有必要上，硬上还有风险，此外还要占用额外的 CPU 等资源
大家场景里，ServiceMesh 有什么刚需场景吗

适合超大规模的条件下，业务和机架分离。举个例子，DB 访问，缓存中间件访问，服务发现，trace 等等这些东西全在 sidecar 里，鸡架更新对于业务完全无感。

项目可能完全没必要上，但面试的时候必须上，大上特上！

如果贵司已经是这也有那也有了的话那当然是没必要硬上。。。但是 mesh 的技术中立好处在于，在其上引入一套新的技术栈（包括对应的实现：服务发现、内网通信、tracing 、熔断 / 限流等日常治理之类）都几乎不需要侵入到业务中，如果用传统的方式开发的话需要基础架构提供一整套对应技术栈需要的 SDK ，这种对于技术栈很复杂的情况会很有意义

ServiceMesh 本身不是刚需产品，整体上还是偏向于过渡态的，比如现在团队很杂，没有统一的 SDK ，有些调度策略没办法统一实现，那么 ServiceMesh 就很有必要，可以帮你解决问题，但是如果团队基建都很 Nice ，那确实不需要。这是一个量体裁衣的事情。

如果需要晋升，那就大上特上

前两个 mesh 是可以做，但 springboot 这类的基座是不是也可以做呢？另外后两个无感可以展开讲讲吗

之前的项目大规模用过 istio ，我的感受是完全没有必要。。。而且运维成本很高，线上问题很难处理。

我其实也没看出来 istio 解决了什么痛点，感觉不存在他的舒适区。面向晋升需求可以用用

service mesh 的主要优势是把服务发现，流量路由，协议转换和服务治理这些东西完全和业务服务解构。举个简单的例子，你是架构，想上一个新的治理规则，但是你们一共有 1000 个微服务，其中有 600 个微服务需要升级框架才能支持。这种时候如果没有 service mesh ，可能全公司数十个团队要花数千个 PD 才能完成框架版本的收敛并增加这个治理规则，而如果用了 service mesh ，架构侧分批升级 sidecar 并下发规则就可以了。

一旦规模大起来了，没有 service mesh 会使这些工作效率非常低下。

微服务的一整套都是刷 kpi

我也是这样想的，个人觉得中国九成的公司只靠 Spring Cloud Alibaba 的 Nacos 那一套，就可以完成大部分微服务治理的需求，istio 最显著的一个实际意义是在公司前期的基础设施做的比较脏乱差的情况下，起到一个抹平不同时间线，不同业务向的技术栈差异的作用。

换个理解方法。既然有团队负责这个，有团队负责那个。那 k8s 其实也没必要用了。他本身也只是在机器上调度容器启停更新容器镜像而已。写几十个 shell 其实也能实现多机更新，shell 用 ipvs 实现流量转发，每个机器 container 挂个 nginx 互相同步配置文件就是 ingress 了。bind9 实现内网 dns 。nfs 的共享存储。这样就重新发明 k8s 了。

SM 很难评，如果基础设施/开发能力薄弱，SM 可以一键为业务提供服务发现，流量路由等等高阶能力。但基础设施/开发能力薄弱估计有很难维护好 SM 自身。另一方面，如果基础设施已经很健全了（如 OP 的场景），引入 SM 的投入和收益又很不成正比。

这种的 trace 能关联 rpc 跟 db 查询吗 ? 比如处理一个请求 req 的时候, 访问了服务 b, c 以及 db, 能在 UI 上看到这个 req 对 db 的访问吗 ? 预期的树形结构是这样的|_____________________req____________| |___b__| |__c__| |__db_|

当然可以

那是如何实现的 ? 用的魔改的 db 驱动 ?

看规模

opentelemetry.io/zh/

发这个连接有什么用吗 ?

我的问题是 servicemesh 如何通过 sidecar 实现 trace. opentelemetry 更像是一个规范及 sdk, 从我之前的经验来看, 得需要埋点实现, 似乎没法做到侵入性的实现 trace 等功能

如果你访问 DB 的流量也是 sidecar 代理的，那 sidecar 里上报不就好了

在读一遍我的问题. sidecar 上报这能无侵入的实现. 但是如何无侵入的关联 traceCtx , 知道这个 db 查询是哪个 rpc 请求触发的 ?

我在 hesudu.com/t/1079010?p=1＃r_15371204 里头的确没提到这一点