客户端与服务端服务发现的取舍

服务发现要解决的问题是：调用方怎么知道该找哪个实例、多个实例时怎么分摊负载。客户端方案（如 Spring Cloud Netflix Eureka）让应用自己在启动时向注册中心报到、关闭时注销，调用别的服务前先去注册中心查一遍可用地址列表，再由应用自己按某种策略选一个——控制权完全在应用手里，代价是每种语言/框架都要单独接入注册中心客户端，还多了一个注册中心本身需要维护。服务端方案把这套逻辑整体挪到部署平台层，应用完全不用感知注册中心的存在，只管把请求发给一个固定的名字，剩下的服务注册、地址解析、负载均衡全部由平台透明代理完成——这正是 Kubernetes Service 对象的做法。发散：这本质是”控制权”和”心智负担”之间的取舍——客户端方案能做到服务端方案做不到的精细控制（比如 hedging：把同一个请求同时发给多个实例抢最快的响应），但绝大多数场景根本用不上这种精细度，白白多背了一层基础设施复杂度，这也是为什么书里明确推荐没有特殊需求就该用 Kubernetes 原生方案。