什么是服务发现微服务架构意味着有更多独立的服务，服务之间通过远程通信来交互。如果只有少量的服务或者服务部署的频率较低，则可以通过硬编码/配置的方式提供服务的地址。但现实是我们必须面对大量服务实例和频繁上线的部署行为，这个时候，服务之间想要知道彼此的地址和运行时的状态，就需要通过服务发现组件来实现了。服务发现是指在分布式系统中，自动发现并识别可用的服务实例的过程。这些服务实例可以是不同主机上运行的，也可以使用不同的端口或协议来提供服务。在一个典型的服务发现系统中，服务注册到一个中心位置。其他服务或客户端可以通过查询这个中心位置来获取可用服务实例的信息。通常，服务注册中心会记录服务实例的网络位置、元数据和健康状况等信息，这有助于客户端决定要请求哪个服务实例来提供服务。服务发现的必要功能服务查找服务注册服务健康检查服务变更通知CAP 定理在一个分布式系统中，只能同时满足一致性、可用性和分区容错性这3个基本特征中的2个，这就是著名的CAP定理CAP的详细内容，可以参考

CAP 定理

技术随笔

业界提供的用于服务发现的注册中心，基本上都满足AP/CP常见的注册中心

服务发现的常用模式客户端服务发现在客户端服务发现模式中，客户端负责查找微服务的网络位置，并在它们之间进行负载平衡请求。首先，客户端查询服务注册表并检索位置。然后，客户端使用其专用负载均衡器来选择微服务并发送请求。客户端服务发现的优势它简单易懂。客户端在发送请求之前就知道微服务的位置。客户端可以通过其专用负载均衡器做出智能负载平衡决策。客户端服务发现的缺点客户端负责实现服务发现逻辑。客户端与服务注册表耦合。需要为客户端使用的每种语言实现服务发现逻辑。服务端服务发现服务器端发现模式通过解耦客户端和服务注册表来解决客户端发现中的一个重要问题。在这种方法中，客户端没有专用的负载均衡器。相反，负载均衡器充当中间人，负责与服务注册表进行通信。首先，客户端通过负载均衡器请求微服务。然后，负载均衡器查询服务注册表并找到相关微服务的位置。最后，负载均衡器将请求路由到微服务。这种模式在现代应用程序中被广泛使用，因为客户端和微服务都独立于服务注册表。最重要的是，我们不需要从头开始实现服务器端发现负载均衡器，因为许多部署环境都提供负载均衡器。例如，我们可以在Kubernetes环境中使用AWS弹性负载均衡器或代理作为服务器端发现负载均衡器。国内华为云、阿里云都提供相应的负载均衡器服务器端服务发现的优势服务注册表与客户端解耦。异构：没有必要为客户端使用的每种语言实现服务发现逻辑。服务器端服务发现的缺点请求效率：多一跳，会影响请求效率服务端服务发现的开源实现spring cloud gatewaytraefikkongistio + envoykubernetes servicemosnlinkerdBFEcounter