在搭建微服务架构时，经常会听到“服务注册中心”和“服务发现”这两个词。很多人觉得它们是一回事，其实不然。虽然它们紧密配合，但分工明确，就像快递系统里的“地址登记处”和“快递查询系统”。
服务注册中心是干什么的？
你可以把服务注册中心想象成一本动态更新的电话簿。每当一个微服务启动，比如订单服务、用户服务，它就会主动跑到注册中心报到：“我上线了，我的IP是192.168.1.10，端口是8080。”
这个“报到”的过程就是注册。常见的注册中心有 Eureka、Consul、Nacos 等。它们负责记录哪些服务在线、在哪台机器上运行、健康状态如何。如果服务挂了，注册中心还会通过心跳机制检测到并把它从名单中移除。
// 伪代码：服务注册示例
serviceRegistry.register("order-service", "192.168.1.10:8080");服务发现又是什么？
有了电话簿，还得有人去查。当订单服务需要调用支付服务时，它不会写死对方的IP地址，而是问注册中心：“支付服务在哪？” 这个“问”的过程就是服务发现。
服务发现通常由客户端或负载均衡器完成。比如 Spring Cloud 中的 Ribbon 就会在调用前先向注册中心发起查询，拿到可用的支付服务实例列表，再选择一个发起请求。
// 伪代码：服务发现示例
List<ServiceInstance> instances = serviceDiscovery.getInstances("payment-service");
ServiceInstance target = loadBalancer.choose(instances);两者的关系：协作但不重叠
注册中心是“存信息”的，服务发现是“取信息”的。没有注册中心，服务发现无处可查；没有服务发现，注册中心里的数据就没人用。它们像车站的“班次公告屏”和“乘客查车”——一个发布，一个获取。
举个生活化的例子：你开了一家新奶茶店，先去工商局登记（注册），之后顾客才能通过地图App搜到你的店（发现）。登记不等于被搜到，但后者依赖前者。
实际架构中如何配合
在典型的微服务流程中：
- 服务启动 → 向注册中心注册自己
- 其他服务需要调用它 → 发起服务发现请求
- 注册中心返回可用实例列表
- 调用方通过负载均衡选择一个实例发起通信
有些工具如 Nacos 同时支持注册和发现功能，但这不代表两者概念等同。就像智能手机能拍照也能打电话，但相机和通话功能依然是两个模块。