换个理解方法。

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

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

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

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

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

看规模

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