微服务系列（三）：服务注册与发现

1 微服务的注册与发现

微服务注册与发现类似于生活中的"电话通讯录"的概念，它记录了通讯录服务和电话的映射关系。在分布式架构中，服务会注册进去，当服务需要调用其它服务时，就这里找到服务的地址，进行调用。

步骤如下：

1、你先要把"好友某某"记录在通讯录中。

2、拨打电话的时候通过通讯录中找到"好友某某"，并拨通回电话。

3、当好友某某电话号码更新的时候，需要通知到你，并修改通讯录服务中的号码。

从这个过程中我们看到了一些特点：

1、把 "好友某某" 的电话号码写入通讯录中，统一在通讯录中维护，后续号码变更也是更新到通讯录中，这个过程就是服务注册的过程。

2、后续我们通过"好友某某"就可以定位到通讯录中的电话号码，并拨通电话，这个过程理解为服务发现的过程。

而我们微服务架构中的服务注册与发现结构如下图所示：

图片中是一个典型的微服务架构，这个结构中主要涉及到三大角色：

provider - 服务提供者

consumer - 服务消费者

它们之间的关系大致如下：

1、每个微服务在启动时，将自己的网络地址等信息（微服务的ServiceName、IP、Port、MetaData等）注册到注册中心，注册中心存储这些数据。

2、服务消费者从注册中心查询服务提供者的地址，并通过该地址调用服务提供者的接口。

3、各个微服务与注册中心使用一定机制（例如心跳）通信。如果注册中心与某微服务长时间无法通信，就会注销该实例。

优点如下：

1、解耦：服务消费者跟服务提供者解耦，各自变化，不互相影响

2、扩展：服务消费者和服务提供者增加和删除新的服务，对于双方没有任何影响

3、中介者设计模式：用一个中介对象来封装一系列的对象交互，这是一种多对多关系的中介者模式。

从功能上拆开主要有三块：服务注册、服务发现，和注册中心。我们一个一个来看。

1.1 服务注册

如图中，为Register注册中心注册一个服务信息，会将服务的信息：ServiceName、IP、Port以及服务实例MetaData元数据信息写入到注册中心。当服务发生变化的时候，也可以更新到注册中心。

服务提供者（服务实例）的服务注册模型是一种简单、容易理解、流行的服务注册模型，其在多种技术生态中都有所体现：

1、在K8S生态中，通过 K8S Service服务信息，和Pod的 endpoint（用来记录service对应的pod的访问地址）来进行注册。

2、在Spring Cloud生态中，应用名对应服务Service，实例 IP + Port 对应 Instance实例。比较典型的就是A服务，后面对应有多个实例做负载均衡。

3、在其他的注册组件中，比如 Eureka、Consul，服务模型也都是服务 -> 服务实例。

可以认为服务实例是一个真正的实体的载体，服务是对这些相同能力或者相同功能服务实例的一个抽象。

1.2 服务发现

服务发现实际就是我们查询已经注册好的服务提供者，比如 p->p.queryService(serviceName)，通过服务名称查询某个服务是否存在，如果存在，

返回它的所有实例信息，即一组包含ip 、 port 、metadata元数据信息的endpoints信息。

这一组endpoints信息一般会被缓存在本地，如果注册中心挂掉，可保证段时间内依旧可用，这是去中心化的做法。对于单个 Service 后面有多个 Instance的情况（如上图），做 load balance。

服务发现的方式一般有两种：

1、拉取的方式：服务消费方（Consumer）主动向注册中心发起服务查询的请求。

2、推送的方式：服务订阅/通知变更（下发）：服务消费方（Consumer）主动向注册中心订阅某个服务，当注册中心中该服务信息发生变更时，注册中心主动通知消费者。

1.3 注册中心

注册中心提供的基本能力包括：提供服务注册、服务发现以及健康检查。

服务注册跟服务发现上面已经详细介绍了，健康检查指的是指注册中心能够感知到微服务实例的健康状况，便于上游微服务实例及时发现下游微服务实例的健康状况。采取必备的访问措施，如避免访问不健康的实例。

主要的检查方式包括：

1、服务Provider 进行 TTL 健康汇报（Time To Live，微服务Provider定期向注册中心汇报健康状态）。

2、注册中心主动检查服务Provider接口。

综合我们前面的内容，可以总结下注册中心有如下几种能力：

1、高可用

这个主要体现在两个方面。一个方面是，注册中心本身作为基础设施层，具备高可用；第二种是就是前面我们说到的去中心化，极端情况下的故障，短时间内是不影响微服务应用的调用的

2、可视化操作

常用的注册中心，类似 Eureka、Consul 都有比较丰富的管理界面，对配置、服务注册、服务发现进行可视化管理。

3、高效运维

注册中心的文档丰富，对运维的支持比较好，并且对于服务的注册是动态感知获取的，方便动态扩容。

4、权限控制

数据是具有敏感性，无论是服务信息注册或服务是调用，需要具备权限控制能力，避免侵入或越权请求

5、服务注册推、拉能力

这个前面说过了，微服务应用程序（服务的Consumer），能够快速感知到服务实例的变化情况，使用拉取或者注册中心下发的方式进行处理。

2 主流注册中心选型

注册中心的选型直接影响微服务架构的可用性和运维复杂度。本节按推荐优先级从高到低排列：Nacos（国内首选）→ Consul（国际化首选）→ Etcd（云原生场景）→ ZooKeeper（Dubbo 存量系统）→ Eureka（已停止维护，仅作历史参考）。

2.1 Nacos（推荐）

2.1.1 介绍

Nacos（Dynamic Naming and Configuration Service）是阿里巴巴开源的一款集服务注册发现和配置管理于一体的中间件，在中国互联网生态中已成为主流选择。

Nacos 的核心特性如下：

1、同时支持 CP 和 AP 模式：可根据业务场景灵活切换一致性模型。临时实例使用 AP 模式（Distro 协议），持久化实例使用 CP 模式（Raft 协议），兼顾可用性与一致性。

2、注册发现 + 配置管理一体化：不同于其他注册中心需要配合额外的配置中心（如 Spring Cloud Config），Nacos 原生集成了动态配置管理能力，减少基础设施依赖。

3、原生支持 Spring Cloud 和 Dubbo：对 Spring Cloud Alibaba 和 Dubbo 生态提供开箱即用的适配，迁移成本低。

4、丰富的管理界面：提供可视化控制台，支持服务列表查看、健康状态监控、配置在线编辑和灰度发布。

5、大规模生产验证：在阿里、字节等大厂的大规模实践验证下，Nacos 在国内技术社区拥有活跃的生态和丰富的文档支持。

2.1.2 整体架构

Nacos 集群由多个节点组成，核心架构分为三层：

1、Naming Service（注册发现）：管理服务实例的注册、注销和健康检查。临时实例通过客户端心跳保活（AP 模式），持久实例通过服务端主动探测（CP 模式）。

2、Config Service（配置管理）：管理配置的发布、变更和推送。支持命名空间（Namespace）、分组（Group）和数据ID（Data ID）三级隔离。

3、Consistency Protocol（一致性协议）：底层同时实现了 Distro（AP，最终一致性，用于临时实例同步）和 Raft（CP，强一致性，用于持久实例和配置数据），根据数据类型自动选择。

2.1.3 接入 Spring Cloud 生态

Nacos 通过 spring-cloud-starter-alibaba-nacos-discovery 接入 Spring Cloud，服务提供者启动时自动注册到 Nacos，消费者通过服务名自动发现并负载均衡调用。详细的代码示例见本文第三章实战部分。

2.2 Consul

2.2.1 介绍

Consul是HashiCorp推出的一款软件，是一个Service Mesh解决方案，提供了功能丰富的控制面功能：

1、Service Discovery（服务发现）

2、Configuration（配置化）

3、Segmentation Functionality

这些功能可以根据需要独立使用，或者将它们一起使用用来构建完整的Service Mesh。

Consul提供的关键功能如下：

1、Service Discovery：服务注册/发现功能。

2、Health Checking：健康检查，丰富的健康检查方式；

3、KV Store：KV存储功能，可应用多种场景，如动态配置存储，分布式协调、leader选举等。

4、Multi DataCenter：多数据中心。

2.2.2 整体架构

如上图为Consul的架构，这边对技术点做一下说明：

1、Raft: 一种分布式一致性算法，Consul使用该算法保持强一致性，所以也是典型的CP模式

2、Client：Client是一种agent，其将会重定向所有的RPC 请求到Server。Client是无状态的，其主要参与LAN Gossip协议池。其占用很少的资源，并且消耗很少的网络带宽。

3、Server：Server是一种agent，其包含了一系列的责任包括：参与Raft协议写半数（Raft Quorum）、维护集群状态、响应RPC响应、和其他Datacenter通过WAN gossip交换信息和重定向查询请求至leader或者远端Datacenter。

4、Datacenter: Datacenter其是私有的、低延迟、高带宽的网络环境，去除了在公共网络上的网络交互。

5、Consensus: Consensus一致性在leader 选举、顺序执行transaction 上。当这些事务已经提交至有限状态机（finite-state machine）中，Consul定义consensus作为复制状态机的一致性。本质上使用实现了Raft协议，对于具体实现细节可参考 Consensus Protocol。

6、Gossip：Consul使用了Serf，其提供了Gossip协议多种用途，Serf提供成员关系、失败检查和事件广播。

7、LAN Gossip: Local Area Network Gossip其包含在同一个网络环境或Datacenter的节点。

8、WAN Gossip: Wide Area Network Gossip 其只包含Server节点，这些server分布在不同的datacenter中，其主要通过因特网或广域网相互交流。

9、RPC: 远程过程调用，用于服务之间的通信。

10、CAP抉择：在高可用方面，Consul使用Raft协议作为其分布式一致性协议，本身对故障节点有一定的容忍性，在单个DataCenter中Consul集群中节点的数量控制在2*n + 1个节点，其中n为可容忍的宕机个数，通常为3个节点。

所以是典型的CP模式。

根据Consul 的选举机制和服务原理，我们有两个注意点：

1、部署Consul Service 节点应该奇数为宜，因为+1的偶数节点和奇数节点可容忍的故障数是一样的，比如上图3和4，另一方面，偶数个节点在选主节点的时候可能会出现二分选票的情况，还得重新选举。

2、Consul Service 节点数不是越多越好，虽然Server数量越多可容忍的故障数越多，但是Raft进行日志复制也是很耗时间的，而且Server数量越多，性能越低，所以结合实际场景，一般建议Server部署3个即可。

有兴趣的同学可以去Consul官网看看它的选举机制，还可以对比下Redis中Sentinel模式。

2.3 Etcd

2.3.1 介绍

Etcd 是由 CoreOS 团队开发的一款分布式键值存储系统，使用 Go 语言编写，基于 Raft 一致性协议实现数据的强一致性保证。Etcd 最广为人知的角色是 Kubernetes 的默认存储后端，负责存储集群的所有配置数据和状态信息。

Etcd 的关键特性如下：

1、强一致性：基于 Raft 协议，保证集群中所有节点的数据一致，属于典型的 CP 系统。

2、Watch 机制：客户端可以对某个 Key 或前缀设置 Watch，当数据发生变化时，Etcd 会主动推送通知，非常适合服务发现场景。

3、高性能读写：支持每秒数万次的读写操作，低延迟的响应保证了在高并发场景下的可用性。

4、Kubernetes 的默认存储后端：K8S 中 Service、Endpoint、Pod 等核心资源的注册与发现都依赖 Etcd。

2.3.2 整体架构

Etcd 集群通常由奇数个节点（建议 3 或 5 个）组成，通过 Raft 协议选举 Leader 节点：

1、Leader 选举：集群启动或 Leader 故障时，通过 Raft 协议在 Follower 中选举新的 Leader，所有写请求由 Leader 处理。

2、日志复制：Leader 将写请求以日志形式复制到多数 Follower 节点，当多数节点确认后，该写入才被提交，保证了强一致性。

3、数据模型：Etcd 使用扁平的 Key-Value 模型，支持前缀查询和范围查询，配合 Lease（租约）机制实现 TTL 过期，天然适合服务注册场景。

2.3.3 Kubernetes 中的服务发现

在 Kubernetes 生态中，Etcd 是服务发现的核心基础设施：

1、Pod 启动后，其 IP 和端口信息通过 Endpoint 资源写入 Etcd。

2、K8S Service 通过 Label Selector 关联 Pod，对应的 Endpoint 列表存储在 Etcd 中。

3、kube-proxy 或 CoreDNS 通过 Watch Etcd 中的 Service/Endpoint 变化，实时更新路由规则或 DNS 记录。

这种机制使得 Kubernetes 中的服务注册与发现完全自动化，无需业务代码介入。

2.4 ZooKeeper

介绍

作为一个分布式的、开源的协调服务，ZooKeeper 实现了一系列基础功能，包括简单易用的接口。这些接口被用来实现服务的注册与发现、数据同步、分布式锁、配置中心、集群选举、命名服务等。

在数据模型上，类似于传统的文件系统，节点类型分为：

1、持久节点：节点创建后一直存在，除非执行删除操作。

2、临时节点（注册中心场景下的主要实现机制）：临时节点的生命周期和客户端会话绑定，客户端会话失效后节点自动清除。微服务启动时创建临时节点，停止后节点自动消失。

ZooKeeper 的核心特点：最终一致性、可靠性（消息被一台服务器接受则被所有服务器接受）、原子性（更新只能成功或失败）、顺序性（所有 Server 消息发布顺序一致）。

整体架构

ZooKeeper 集群通过选举产生 Leader，使用 Paxos/ZAB 强一致性算法，是典型的 CP 系统。多个节点组成分布式架构，每个 Server 在内存中存储一份数据，Leader 负责处理数据更新操作。

接入 Dubbo 生态

ZooKeeper 在注册中心方面对 Dubbo 生态支持较好。Provider 启动时向 ZooKeeper 注册信息，Consumer 启动时向 ZooKeeper 订阅，当 Provider 信息变化时 ZooKeeper 主动推送通知变更（与 Eureka 的定时拉取不同）。

注意：虽然 ZooKeeper 在 Dubbo 生态中仍有大量存量使用，但 Dubbo 3.x 已原生支持 Nacos 作为注册中心，新项目建议优先选择 Nacos。

2.5 Eureka（已停止维护）

Netflix Eureka 2.0 已停止开发，Eureka 1.x 处于维护模式。新项目不建议使用。本节仅作为历史参考。

Eureka 是 Netflix OSS 套件中的服务注册与发现组件，早期因 Spring Cloud 的集成和推广而被广泛采用。其核心设计思想（Peer-to-Peer 对等通信、AP 优先、自我保护机制）对后续注册中心产品有深远影响。

核心特点：去中心化架构（无 Master/Slave），节点间通过复制保持最终一致性，属于 CAP 中的 AP 系统。支持自我保护（大量心跳丢失时不立即剔除实例）。

不推荐的原因：不支持 Watch 推送（只能定时拉取，感知延迟高）、无内置配置管理能力、社区已停止活跃开发。

2.6 总结对比

指标	Eureka	Zookeeper	Consul	Etcd	Nacos
一致性协议	AP	CP（Paxos算法）	CP（Raft算法）	CP（Raft算法）	AP/CP（Distro+Raft）
健康检查	TTL(Time To Live)	TCP Keep Alive	TTL\HTTP\TCP\Script	Lease TTL KeepAlive	TTL\HTTP\TCP\Client Beat
watch/long polling	不支持	watch	long polling	watch	long polling + push
雪崩保护	支持	不支持	不支持	不支持	支持
安全与权限	不支持	ACL	ACL	RBAC	RBAC
是否支持多数据中心	是	否	是	否	是
是否有管理界面	是	否（可用第三方ZkTools）	是	否	是
Spring Cloud 集成	支持	支持	支持	支持	支持
Dubbo 集成	不支持	支持	支持	不支持	支持
K8S 集成	不支持	不支持	支持	支持	支持

Eureka是典型的AP类型，Zookeeper和Consul是典型的CP类型。如何选择取决你的业务是倾向A：高可用性还是 C：强一致性。

当然，业务是复杂的，在真正的技术选型时，还是要根据自己的实际业务现状来判断。有一些倾向，比如你的系统是Spring Cloud体系下，那优先选择Nacos、Consul。

如果业务会更多向云原生对齐，则Consul、Etcd会是比较优先的选择。如果是国内 Spring Cloud 或 Dubbo 生态，Nacos 凭借注册发现与配置管理一体化的能力，已成为首选方案。

3 Spring Cloud 框架下实战

Spring Cloud是微服务架构的一站式解决方案，我们平时构建微服务的过程中需要做的如配置管理、服务发现、负载均衡、断路器、智能路由、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作。Spring Cloud 为我们提供了一套简易的编程模型，使我们能在 Spring Boot 的基础上轻松地实现微服务项目的构建。

Spring Cloud 为服务治理做了一层抽象，支持多种注册中心的无缝切换（Nacos、Consul、Eureka 等），不影响业务代码中的注册、发现、调用逻辑。下面以当前主流的 Nacos 和 Consul 为例，演示 Spring Cloud 下的服务注册与发现实战。

3.1 Spring Cloud Nacos 实战

Nacos 作为注册中心接入 Spring Cloud 非常简便，通过 Spring Cloud Alibaba 提供的 spring-cloud-starter-alibaba-nacos-discovery 即可完成集成。

3.1.1 启动 Nacos Server

从 Nacos 官方 Release 下载最新稳定版，解压后启动：

# 单机模式启动（开发环境）
sh startup.sh -m standalone

启动后访问 http://localhost:8848/nacos，默认账号密码均为 nacos，可以看到 Nacos 控制台。

3.1.2 创建服务提供者

创建 Spring Boot 项目，pom.xml 中引入依赖：

<dependencies>
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
</dependencies>

application.yml 配置：

server:
  port: 8001
spring:
  application:
    name: nacos-provider          # 服务名称，注册到 Nacos 后其他服务通过此名称发现
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848   # Nacos Server 地址
        namespace: public              # 命名空间（多环境隔离）

主类无需额外注解（Spring Cloud Alibaba 会自动启用服务注册）：

@SpringBootApplication
public class ProviderApplication {
    public static void main(String[] args) {
        SpringApplication.run(ProviderApplication.class, args);
    }
}

提供一个简单的接口：

@RestController
public class HelloController {
    @GetMapping("/hello")
    public String hello(@RequestParam String name) {
        return "Hello, " + name + " from Nacos Provider!";
    }
}

启动后，在 Nacos 控制台的"服务列表"中可以看到 nacos-provider 已注册。

3.1.3 创建服务消费者

创建另一个 Spring Boot 项目作为消费者，同样引入 nacos-discovery 依赖。application.yml：

server:
  port: 8002
spring:
  application:
    name: nacos-consumer
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848

通过 @LoadBalanced + RestTemplate 实现基于服务名的调用：

@SpringBootApplication
public class ConsumerApplication {
    @Bean
    @LoadBalanced   // 开启客户端负载均衡
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }

    public static void main(String[] args) {
        SpringApplication.run(ConsumerApplication.class, args);
    }
}

@RestController
public class ConsumerController {
    @Autowired
    private RestTemplate restTemplate;

    @GetMapping("/call")
    public String call() {
        // 直接使用服务名 nacos-provider 替代 IP:Port
        return restTemplate.getForObject(
            "http://nacos-provider/hello?name=Consumer", String.class);
    }
}

访问 http://localhost:8002/call，返回 Hello, Consumer from Nacos Provider!。整个过程中，消费者不需要知道提供者的 IP 和端口——通过 Nacos 注册中心自动发现。

3.1.4 Nacos 的额外能力

相比其他注册中心，Nacos 在 Spring Cloud 生态中还提供以下开箱即用的能力：

能力	说明
配置管理	`spring-cloud-starter-alibaba-nacos-config`，无需额外部署 Spring Cloud Config
命名空间隔离	通过 `namespace` 实现多环境（dev/staging/prod）隔离
服务分组	通过 `group` 实现同一命名空间内的逻辑分组
权重路由	在控制台直接调整实例权重，实现流量调配
健康检查	同时支持客户端心跳（临时实例）和服务端主动探测（持久实例）

3.2 Spring Cloud Consul 实战

Consul 用于实现分布式系统的服务发现与配置。与其它分布式服务注册与发现的方案，Consul 的方案更具"一站式"特征，内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，不再需要依赖其它工具（比如 ZooKeeper 之类的）。

而Spring Cloud Consul ，是将其作为一个整体，在微服务架构中为我们的基础设施提供服务发现和服务配置的工具。

3.2.1 Consul 的优势

1、使用 Raft 算法来保证一致性, 比复杂的 Paxos 算法更直接。

2、支持多数据中心，内外网的服务采用不同的端口进行监听。多数据中心集群可以避免单数据中心的单点故障,而其部署则需要考虑网络延迟, 分片等情况等。 zookeeper 和 etcd 均不提供多数据中心功能的支持，上面表格中有体现。

3、支持健康检查。

4、支持 http 和 dns 协议接口。 zookeeper 的集成较为复杂, etcd 只支持 http 协议。

5、官方提供 web 管理界面, etcd 无此功能。

3.2.2 安装Consul注册中心

1、官方下载64版本：https://www.consul.io/downloads.html

2、解压后复制到目录 /usr/local/bin 下

3、启动终端，先看下啥版本的

liyifei@MacPro ~ % consul --version
Consul v1.10.4
Revision 7bbad6fe
Protocol spoken by default, understands to (agent will automatically use protocol >when speaking to compatible agents)

4、执行安装命令，可以看到他的 Client Addr 的端口为8500。所以访问 8500端口站点，http://127.0.0.1:8500/ui/dc1/services

  liyifei@MacPro ~ % consul agent -dev
  ==> Starting Consul agent...
             Version: '1.10.4'
             Node ID: '6db154b4-62ff-e67d-e745-1a7270fa1ce8'
           Node name: 'B000000147796DS'
          Datacenter: 'dc1' (Segment: '<all>')
              Server: true (Bootstrap: false)
         Client Addr: [127.0.0.1] (HTTP: 8500, HTTPS: -1, gRPC: 8502, DNS: 8600)
        Cluster Addr: 127.0.0.(LAN: 8301, WAN: 8302)
           Encrypt: Gossip: false, TLS-Outgoing: false, TLS-Incoming: false, Auto-Encrypt-TLS: false

我们可以看到，现在没有客户端注册上来，只有一个自身的实例。

3.2.3 创建服务提供者

由于Spring Cloud Consul项目的实现，我们可以轻松的将基于Spring Boot的微服务应用注册到Consul上，并通过此实现微服务架构中的服务治理。

我们在micro-service-center下新建一个cloud项目consul-client，该项目pom文件添加如下：

<xml>
  <!--    在子工程中添加父工程名称-->
  <parent>
    <groupId>com.microservice</groupId>
    <artifactId>center</artifactId>
    <version>1.0.0</version>
  </parent>

  <dependencies>
    <!--        Consul服务发现-->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-consul-discovery</artifactId>
    </dependency>
    <!--        Consul健康检查-->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>
  </dependencies>
</xml>

然后修改一下application.yml的配置信息，将consul配置写入，注释应该很清楚了，如下：

spring:
  application:
    name: consul-producer # 当前服务的名称
  cloud:
    consul: # 以下为Consuk注册中心的地址，如果安装的不是这个host和port，这边可以调整
      host: localhost
      port: 8500
server:
  port: 8501 # 当前服务的端口

同样的，我们要在应用主类Application文件中通过加上@EnableDiscoveryClient注解，该注解保证当前服务被Consul当成provider发现。

大家看到这个做法跟Eureka一样，因为Spring Cloud对服务治理做的一层抽象，所以可以屏蔽Eureka和Consul服务治理的实现细节，

程序上不需要做改变，只需要引入不同的服务治理依赖，并配置相关的配置属性就能轻松的将微服务纳入Spring Cloud的各个服务治理框架中。

@SpringBootApplication
@EnableDiscoveryClient
public class ConsulClientApplication {
    public static void main(String[] args) {
        SpringApplication.run(ClientApplication.class, args);
    }
}

修改完成之后，我们就可以把这个服务提供者启动了，然后再去注册中心查看服务的注册情况，就可以看到被注册进来的Provider（consul-producer）：

3.2.4 生态对接 Spring Cloud

Consul作为注册中心，集成在Spring Cloud生态。可以看出，跟Eureka对接到Spring Cloud 生态的过程很像。

但是这边的健康检查更丰富，可以有多种不同的的Check方式：

Script check（Script+ Interval）
基于HTTP请求
基于tcp请求
基于grpc请求

4 总结

无论何种注册中心技术，本质上都是为了解决微服务中的如下问题：

解耦服务之间相互依赖的细节

我们知道服务之间的远程调用必须要知道对方的IP、端口信息。我们可以在调用方直接配置被调用方的IP、端口，这种调用方直接依赖IP、端口的方式存在明显的问题，如被调用的IP、端口变化后，调用方法也要同步修改。

通过服务发现，将服务之间IP与端口的依赖转化为服务名的依赖，服务名可以根据具微服务业务来做标识，因此，屏蔽、解耦服务之间的依赖细节是服务发现与注册解决的第一个问题。

对微服务进行动态管理

在微服务架构中，服务众多，服务之间的相互依赖也错综复杂，无论是服务主动停止，意外挂掉，还是因为流量增加对服务实现进行扩容，这些服务数据或状态上的动态变化，都需要尽快的通知到被调用方，被调用方才采取相应的措施。因此，对于服务注册与发现要实时管理者服务的数据与状态，包括服务的注册上线、服务主动下线，异常服务的剔除。

系列导航

微服务系列（一）：从演进到全景

微服务系列（二）：拆分策略与实践

微服务系列（三）：服务注册与发现

微服务系列（四）：架构落地指南