[服务网格] 服务网格似乎没那么必要上？

接触 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 有什么刚需场景吗