第三方集成

如何选择注册发现扩展？

类型	适配器	选择依据
KV/一致性系统	etcd、Consul、Zookeeper	一致性、watch、运维能力
服务平台	Nacos、Polaris、Eureka、ServiceComb	已有平台与治理体系
网络命名	DNS	简单、K8s 友好，但实例粒度取决于记录
过滤层	RuleBasedResolver	在发现结果上按标签筛选

• Server: 构造 Registry 后通过 server.WithRegistry 注入;
• Client: 构造 Resolver 后通过 client.WithResolver 注入;
• 认证/TLS: 使用适配器 Option 配置，不把凭据硬编码到业务代码;
• 健康语义: 注册成功不等于业务 ready; readiness 必须由业务依赖状态决定;

如何用配置中心下发治理策略？

• etcd、Nacos、Zookeeper、Consul、Apollo、File: 可通过 Suite 转换为 Kitex 治理策略;
• 策略: timeout、retry、circuit breaker、fallback、Server limiting;
• File: 适合本地和静态配置; 默认支持 JSON/YAML，可自定义 parser;
• 动态配置: 校验范围、保留最后有效值、记录版本并支持回滚;
• 通配配置: 可提供 service/method 默认策略，但特例优先级必须明确;

如何管理观测扩展？

• 接入与指标: 统一由 可观测性 说明，避免每个适配器建立另一套指标口径;
• 依赖边界: exporter、provider 和 Kitex 的兼容版本一起固定，按下面的依赖治理步骤验证;

如何控制扩展依赖的风险？

• kitex-contrib: 社区维护的扩展集合，不随 Kitex 内核自动保证兼容;
• 版本矩阵: 固定 Kitex、适配器与第三方 Client 的兼容组合;
• 故障测试: 断连、鉴权失败、watch 中断、空实例、旧配置与恢复;
• shutdown: 关闭 watcher、连接、provider 和后台 goroutine;
• 替换成本: 业务代码只依赖 Kitex Registry/Resolver 等窄接口;