背景

问题描述

上篇文章的例子中可以看到，远程调用时，我们的 URL 是写死的

String url = "http://127.0.0.1:9090/product/" + orderInfo.getProductId();

当更换机器，或者新增机器时，这个 URL 就要跟着变更，就需要去通知所有的相关服务求修改。随之而来的就是各个项目的配置未见反复更新，各个项目的频繁部署。这种没有具体意义，但又不得不做的工作，会让人非常痛苦

解决思路

试想生活中的场景：
我们的生活，避免不了和各个机构（医院，学校，政府部门等）打交道，就需要保存各个机构的电话号码。如果机构换了电话号码，就需要通知各个使用方，但这些机构的使用方群体是巨大的，没法做到一一通知，怎么处理呢？

机构电话如果发生变化，通知 114。用户需要联系机构时，先打 114 查询电话，然后再联系各个机构。114 查号台的作用主要有两个：

• 号码注册：服务方把电话上报给 114
• 号码查询：使用方通过 114 可以查到对应的号码

同样的，微服务开发时，也可以采用类似的方案

• 服务启动/变更时，向注册中心报道。注册中心记录应用和 IP 的关系
• 调用方调用时，先去注册中心获取服务方的 IP，再去服务方进行调用

什么是注册中心

在最初的架构体系中，集群的概念还不那么流行，且机器数量也比较少，此时直接使用 DNS + Nginx 就可以满足几乎所有服务的发现。相关的注册信息直接配置在 Nginx。

• 但是随着微服务的流行与流量的激增，机器规模逐渐变大，并且机器会有频繁的上下线行为，这种时候需要运维手动地去维护这个配置信息是一个很麻烦的操作
• 所以开发者们开始希望有这么一个东西，它能维护一个服务列表，哪个机器上线了，哪个机器宕机了，这些信息都会自动更新到服务列表上，客户端拿到这个列表，直接进行服务调用即可
• 这个就是注册中心

---

注册中心主要有三种角色：

• 服务提供者（Server）：一次业务中，被其他微服务调用的服务。也就是提供接口给其他微服务
• 服务消费者（Client）：一次业务中，调用其他微服务的服务。也就是调用其他微服务提供的接口
• 服务注册中心（Registry）：用于保存 Server 的注册信息，当 Server 节点发生变更时，Registry 会同步变更。服务与注册中心适用于一定机制通信，如果注册中心与某服务长时间无法通信，就会注销该实例

他们之间的关系以及工作内容，可以通过两个概念来描述：

• 服务注册：服务提供者在启动时，向 Registry 注册自身服务，并向 Registry 定期发送心跳，汇报存活状态
• 服务发现：服务消费者从注册中心查询服务提供者的地址，并通过该地址调用服务提供者的接口。服务发现的一个重要作用就是提供给消费者一个可用的服务列表

CAP 理论

要谈到注册中心，就避不开 CAP 理论

---

CAP 理论是分布式系统设计中最基础，也是最关键的理论

• 一致性（Consistency）：CAP 理论中的一致性，指的是强一致性。所有节点在同一时间具有相同的数据
• 可用性（Availability）：保证每个请求都有响应（响应结果可能不对）
• 分区容错性（Partition Tolerance）：当出现网络分区后，系统仍然能够对外提供服务

一个部分全国各地都有岗位，这时候，总部下发一个通知，由于通知需要开会周知全院，当有客户咨询时：

1. 所有成员对客户的回应结果都是一致的（一致性）
2. 客户咨询时，一定有回应（可用性）
3. 当其中一个成员休假时，这个部门的其他成员也可以对客户提供咨询服务（分区容错性）

CAP 理论告诉我们：一个分布式系统不可能同时满足数据一致性、服务可用性和分区容错性这三个基本需求，最多只能同时满足其中的两个

在分布式系统中，系统间的网格不能 100% 保证健康，服务又必须对外保证服务。因此 Partition Tolerance 不可避免。那就只能在 C 和 A 选择一个，也就是 CP 或者 AP 架构

---

正常情况

网路异常

• CP 架构：为了保证分布式系统对外的数据一致性，于是选择不返回任何数据
• AP 架构：为了保证分布式系统的可用性，节点 2 返回 V0 版本的数据（即使这个数据不正确）
• 更多参考： https://cloud.tencent.com/developer/article/1860632

常见的注册中心

1. Zookeeper：

   • Zookeeper 的官方并没有说它是一个注册中心，但是国内 Java 体系，大部分的集群环境都是依赖 Zookeeper 来完成注册中心的功能

2. Eureka

   • Eureka 是 Netflix 开发的基于 REST 的服务发现框架，主要用于服务注册，管理，负载均衡和服务故障转移
   • 官方声明在 Eureka 2.0 版本停止维护，不建议使用。但是 Eureka 是 Spring Cloud 服务注册/发现的默认实现，所以目前还是有很多公司在使用

3. Nacos

   • Nacos 是 Spring Cloud Alibaba 架构中的重要组件，除了服务注册、服务发现功能之外 Nacos 还支持配置管理、流量管理、DNS、动态 DNS 等多种特性

CAP 理论对比

	Zookeeper	Eureka	Nacos
CAP 理论	CP	AP	CP 或 AP 默认 AP
在分布式环境中，即使拿到一个错误的数据，也胜过无法提供实例信息而造成请求失败要好（比如淘宝 11.11，京东 618 都是谨遵 AP 原则）

Eureka 介绍

Eureka 是 NetFlix OSS 套件中关于服务注册和发现的解决方案。Spring Cloud 对 Eureka 进行了集成，并作为优先推荐方案进行宣传，虽然目前 Eureka 2.0 已经停止维护，新的微服务架构设计中，也不再建议使用，但是目前依然有大量公司的微服务系统使用 Eureka 作为注册中心

Eureka 主要分为两个部分：

• Eureka Server：作为注册中心 Server 端，喜爱那个微服务应用程序提供服务注册、发现、健康检查等能力
• Eureka Client：服务提供者，服务启动时，会向 Eureka Server 注册自己的信息（IP，端口，服务信息等），Eureka Server 会存储这些信息

关于 Eureka 的学习，主要包含以下三个部分：

1. 搭建 Eureka Server
2. 将 order_service，product_service 都注册到 Eureka
3. order_service 远程调用时，从 Eureka 中获取 product_service 的服务列表，然后进行交互