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

### 前言

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

@lvlongxiang199  https://opentelemetry.io/zh/

看规模

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

|_____________________req____________|
   |___b__|       |__c__|    |__db_|

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

换个理解方法。

既然有团队负责这个，有团队负责那个。

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

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

微服务的一整套都是刷 kpi

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

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

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