K8s已自带服务发现，使用Dapr微服务框架时还需要其服务发现能力吗？

核心定位差异 #

Kubernetes 原生服务发现和 Dapr 服务调用本质是不同层级的能力，不存在替代关系，核心定位的区别如下：

• Kubernetes 原生服务发现是集群基础设施层的基础能力：基于 CoreDNS + Service 资源实现，只解决四层网络的寻址问题，即「找到指定服务对应的Pod IP列表」，不对上层应用的通信逻辑做任何干预，也不感知业务层的协议、错误、治理需求。
• Dapr 服务调用是应用层的通信治理能力：工作在七层，底层可以直接复用 Kubernetes 原生服务发现做寻址，在上层封装了微服务架构下所有通用的通信逻辑，目标是把通信治理相关的代码从业务逻辑里剥离，统一由 Sidecar 处理。

Dapr 服务相关能力的额外优势 #

如果你已经在使用 Kubernetes ，引入 Dapr 的服务调用能力可以获得以下额外价值：

• 多协议自动兼容转换：同时支持 HTTP、gRPC 协议，你可以用 HTTP 调用提供 gRPC 接口的服务，也可以用 gRPC 调用提供 HTTP 接口的服务，协议转换逻辑完全由 Dapr Sidecar 处理，不需要业务代码做适配。
• 开箱即用的微服务治理能力：默认提供超时控制、自定义重试策略、熔断、流量灰度、流量镜像等常用治理能力，不需要额外引入其他微服务框架组件，所有规则都可以通过 Dapr 原生 CRD 声明配置，和业务代码完全解耦。
• 跨环境跨集群的统一服务寻址：不管服务部署在 Kubernetes 集群、虚拟机、还是边缘节点，只要接入了 Dapr ，就可以通过统一的 app-id 完成服务调用，不需要手动维护不同环境、不同集群的服务发现映射规则，也不需要处理复杂的跨集群网络打通配置。
• 零埋点的可观测能力：所有服务调用的请求量、耗时、成功率、错误码等指标会自动采集，链路追踪默认支持，不需要在业务代码里做任何埋点，就可以拿到完整的服务调用链路数据。
• 统一的通信安全管控：默认开启 mTLS 双向加密，服务间通信全程加密传输，还可以通过访问控制策略精确配置指定服务允许被哪些应用调用，不需要手动维护证书，也不用配置复杂的 Kubernetes NetworkPolicy 做细粒度访问控制。
• 标准化的错误处理与上下文传递：Dapr 会统一处理服务调用的异常、重试时的幂等校验，也支持在调用链路里透传自定义的上下文状态，不需要业务代码重复封装请求头、写重复的错误处理逻辑。

内容的提问来源于stack exchange，提问作者BTRox