服务发现与服务网格

服务发现怎样定位不断变化的实例？

• 服务发现: 把稳定服务名转换成当前可用实例的位置，让客户端不用写死容器或虚拟机地址;
• 动态来源: 扩缩容、重新部署和故障替换会持续改变实例数量及地址;
• 注册中心: 保存服务到实例地址及状态的映射，需保持高可用和足够新鲜;
• 失效风险: 地址存在不代表实例已经就绪，发现结果要结合健康、租约或部署状态;

客户端发现怎样完成一次调用？

客户端 → 查询注册中心 → 获取实例集合
客户端 → 选择实例 → 直接调用

• 责任: 客户端库负责查询、缓存和选择实例;
• 收益: 可以按调用场景调整负载策略，减少中间转发层;
• 代价: 不同语言客户端都要实现并更新发现逻辑，缓存过旧还会访问失效实例;

服务端发现怎样隐藏实例选择？

客户端 → 稳定入口 → 查询或订阅实例信息 → 转发到后端

• 责任: 负载均衡器或其他中间组件选择后端，客户端只知道入口;
• 收益: 简化客户端并集中维护发现策略;
• 代价: 增加入口处理与可用性要求，入口也要感知实例变化;

实例如何注册与注销？

方式	谁维护记录	权衡
自注册	实例自己注册、发心跳并注销	接入直接，但业务运行时承担额外责任
第三方注册	部署控制器或观察者追踪实例变化	应用更简单，但依赖外部生命周期观测

• 异常退出: 进程崩溃来不及主动注销，应依靠租约超时或健康检测清理;
• 原文示例: etcd、Consul、ZooKeeper 可用于协调或注册，Thrift 主要是 RPC 框架，不能当作同等注册中心产品;

服务网格在发现之外增加什么？

• 服务网格: 在服务间通信基础设施中集中提供路由、观测和连接安全等能力;
• 与发现关系: 使用发现信息定位实例，但职责还包括调用策略和通信治理;
• 原文示例: Istio 提供网格控制与治理，Envoy 常作为数据平面代理，二者不是同一层次产品;
• 成本: 增加代理与控制面的资源、配置和排错复杂度，应基于实际治理需求采用;