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