资深架构师带你通过手写代码实现服务的注册与发现~ 附代码示例链接！

服务的注册与发现

解决了服务的远程调用问题之后，是不是就足够了呢？答案肯定是不够的。言归正传，设想一下，在微服务架构中会有多个服务进行交互，假设我们使用的是HTTP的通信方式，那么系统结构应该为如图2.8所示的网状调用结构，多个微服务直接相互调用。

HTTP的交互方式显然比消息队列简单得多，多个微服务相互调用也变得简单而直接。但不管是哪种方式，随着服务越来越多，微服务的调用网也将越来越大、越来越复杂。你会发现需要管理的服务信息越来越多，这些信息可能包括服务的IP、端口和URL等数据，而且这些信息需要在每个服务的消费方进行维护。

在图2.8中，服务A需要维护服务B和服务E的信息，服务B则需要维护服务A、服务D和服务E的消息，一旦某一个服务的地址或端口发生变化，所有调用它的消费方都需要进行相应的配置修改。笔者曾经做过拥有一百多个服务组成的产品级项目，当时的架构设计服务之间就是直接相互调用，所有的服务信息都是服务调用方在自己的服务端的配置文件中进行配置。

当然，一个服务不可能与一百多个服务都进行交互，但可能会与十几个服务进行通信，当服务信息发生变化时，需要非常熟悉系统的人花费接近一周的时间进行人工测试和排查，然后去修改被影响的服务的配置，才能保证服务更新后系统的正常运行，而且就算是再熟悉系统的人也可能会有遗漏。

那么如何才能解决这个问题呢？答案非常简单，既然人工检测和更新效率低下且容易出错，那就改用自动即可。回忆一下之前介绍过的SOA的服务调用设计，微服务架构中沿用了服务注册这一设计，提供服务注册的服务通常称为注册中心，如图2.9所示。

服务注册中心的设计有效地解决了这个问题，服务提供者可以理解为微服务中的一个服务，服务消费者可以是其他的微服务，也可以是BFF（Backend For Frontend，用于前端的后端）、API网关等服务。关于BFF和API网关将在后续章节陆续介绍。

当服务提供者需要对外提供服务时，会主动向服务注册中心注册，注册中心会保存各个服务提供者的信息，并且通过心跳等机制定期检查服务提供者的健康情况，一旦检测到服务不可用，就要根据一定的规则从注册中心剔除该服务的信息。

服务消费者只需配置注册中心的信息，然后通过唯一标识（如服务提供者的应用名称），就可以查询到服务提供者的信息，也包括服务提供者的健康状态。当服务提供者的信息发生变化时，如修改了一些服务实例的端口号，只要服务提供者在注册时所使用的唯一标识不变，服务消费者是无须修改任何代码或配置的，注册中心会将最新的、可用的服务提供者的信息返回服务消费者。

那么，具体的技术实现有哪些？目前作为注册中心，比较主流的可能是通过ZooKeeper、Consul和Eureka这样的服务框架来完成，当然也完全可以自己设计一个，笔者曾经用Redis写过一个服务注册中心。要实现注册中心并不难，难的是需要开发全套的、完整的服务治理框架，Spring在这一点上有着天然的优势。因此，我们还是以SpringCloud为例，Spring在众多框架中选择Netflix的Eureka作为默认的基础服务注册框架，当然Spring也分别实现了基于ZooKeeper和Consul的注册中心，同时Spring也在开发一套原生的注册中心，以摆脱第三方的框架，但是无论是从成熟度还是从运用的广度来看，Spring CloudNetflix Eureka还是目前的首选。下面来看看Spring Cloud NetflixEureka的具体实践。

Spring Cloud Netflix Eureka主要分为Server和Client两个概念，注册中心就是Server，其他的服务注册者和服务调用者都是Client。当然ÿ