在微服务架构里，经常听到“服务注册中心”和“服务发现”这两个词，很多人觉得它们是一回事。其实不然，就像快递站和查快递单号，一个存信息，一个找信息，分工明确。
注册中心是服务的“户口本”
每个服务启动后，得先去注册中心报个到，把自己的名字、IP地址、端口、健康状态这些信息登记上去，这个过程叫“服务注册”。比如你开了个外卖小店，得先在美团上开店填地址电话，才能被用户搜到。
常见的注册中心有 Eureka、Consul、Nacos。它们的作用就是集中管理所有服务的元数据。服务下线或宕机时，还会主动注销或被心跳机制标记为不健康。
服务发现是消费者的“导航仪”
当订单服务要调用支付服务时，它不会硬编码写死地址，而是问一句：“支付服务都在哪？” 这个“问”的过程就是服务发现。它从注册中心拉取可用的支付服务列表，再选一个发起调用。
服务发现通常由客户端（如 Ribbon）或服务网格（如 Istio）实现。有些框架会定期刷新服务列表，有点像地图App自动更新附近可配送的商家。
两者协作流程示例
以 Spring Cloud + Nacos 为例：
// 支付服务启动时注册自己
nacos.discovery.register-enabled=true
spring.application.name=payment-service
server.port=8081// 订单服务通过名称查找并调用
String url = "http://payment-service/pay";
restTemplate.getForObject(url, String.class);这里 Nacos 扮演注册中心角色，而 OpenFeign 或 RestTemplate 完成服务发现任务。
类比生活更容易理解
可以把注册中心想象成小区里的快递柜。每个快递员（服务）把包裹（自身信息）放进对应格子（注册）。你（调用方）不用满街找快递，直接刷个码（服务发现），系统就告诉你哪个柜子能取件。
没有注册中心，服务之间就得互相记住地址，一旦某个服务换了位置，整个链条都得改配置，运维成本飙升。有了这套机制，增减服务就像插拔U盘，灵活多了。
所以，下次听到这两个词，记住：注册中心负责“我在这儿”，服务发现负责“他在哪儿”。一个写，一个读，配合干活不累。