你好，我是何小锋。在上一讲中，我讲了“怎么设计一个灵活的 RPC 框架”，总结起来，就是怎么在 RPC 框架中应用插件，用插件方式构造一个基于微内核的 RPC 框架，其关键点就是“插件化”。

今天，我要和你聊聊 RPC 里面的“服务发现”在超大规模集群的场景下所面临的挑战。

为什么需要服务发现？

先举个例子，假如你要给一位以前从未合作过的同事发邮件请求帮助，但你却没有他的邮箱地址。这个时候你会怎么办呢？如果是我，我会选择去看公司的企业“通信录”。

同理，为了高可用，在生产环境中服务提供方都是以集群的方式对外提供服务，集群里面的这些 IP 随时可能变化，我们也需要用一本“通信录”及时获取到对应的服务节点，这个获取的过程我们一般叫作“服务发现”。

对于服务调用方和服务提供方来说，其契约就是接口，相当于“通信录”中的姓名，服务节点就是提供该契约的一个具体实例。服务 IP 集合作为“通信录”中的地址，从而可以通过接口获取服务 IP 的集合来完成服务的发现。这就是我要说的 RPC 框架的服务发现机制，如下图所示：

1. 服务注册：在服务提供方启动的时候，将对外暴露的接口注册到注册中心之中，注册中心将这个服务节点的 IP 和接口保存下来。
2. 服务订阅：在服务调用方启动的时候，去注册中心查找并订阅服务提供方的 IP，然后缓存到本地，并用于后续的远程调用。