学习自：【精选】Eureka原理看这一篇就够了_阿小木的愤怒的博客-CSDN博客
1、分布式
分布式系统：由多个应用程序协同来完成任务的一种工作模式系统。这里的任务可能是一个下单操作、复杂的统计计算、存储一个超大数据等等。总之这种任务不适合或无法由单个程序独立完成，需要多个程序协同完成。
2、服务发现
1）解耦、程序屏蔽 与 IP、端口依赖
分布式系统中，程序之间通过一次或多次远程调用或数据传输完成任务。
调用程序前我们首先需要知道被调用程序在网络中的位置，要在网络中定位程序的位置自然会想到IP+Port的方式。但是这种方式存在两个问题：
①IP地址没有特殊含义，不便于记忆和理解；
②当被调用程序的IP、Port发生改变，调用者也要同步修改。
服务发现的作用之一：将程序之间对于IP+Port的依赖转化为对服务名的依赖，服务名可以根据业务功能来命名。
因此，解耦、屏蔽服务间的IP+Port依赖是分布式系统需要解决的第一个问题。
2）动态管理服务状态
分布式系统中，程序状态是随时变化、不可预测的，谁也无法保证下一秒某个程序还能正常运行（服务宕机、磁盘损坏、线程全被占用、网络不稳定），如果某个程序挂掉，调用者不能及时知道，就会出现连锁反应。
服务发现的作用之二：对服务状态进行管理，当服务状态发生改变，可以第一时间通知程序调用者：
①程序之间需要彼此知道对方的状态和信息；
②对方程序状态发生改变可以及时知晓。
3、Eureka如何设计服务发现
1）统一管理中心
服务发现要实现抽象程序标识达到解耦、屏蔽IP+Port、程序状态实时管理。
要进行管理，就要有一个统一的管理中心——注册中心。
注册中心就是Eureka的大脑，负责Eureka各项管理、协调职能。
2）基本概念
Eureka对于管理者与被管理者进行了区分，管理者——注册中心（S端），被管理者——干活的应用程序（C端），分别对应EurekaServer、EurekaClient。
S端-注册中心-管理者
C端-提供服务与消费服务的应用程序-被管理者
3）基本流程
- C端发起服务注册；
- S端保存注册信息到注册表；
- C端定时发生心跳检测；
- S端服务剔除及自我保护；
- C端发起服务下线；
- C端或S端注册信息到本地内存；
- C端整合服务发现。
①C端发起服务注册
C端向S端发送请求，将自身相关信息提交给S端。该过程称为服务注册。
Eureka S端会提供一个接口，用来接收C端服务注册的请求，S端会一直监听该接口，等待C端调用。
C端在启动时先找到S端及自身信息（分区、服务名、IP、Port等），调用S端提供的服务注册接口，将自身的信息发送过去。
配置信息可能在C端的配置文件中，也可能在配置中心统一配置。
②S端保存注册信息
S端保存C端请求发送的服务注册信息到本地内存注册表。
注册表是服务发现的核心，基本所有操作都是围绕注册表进行操作，注册表的添加、获取、更新、删除、同步等一系列操作。
Eureka的注册表是一个双字典结构数据，服务发现的目的是标识服务和服务状态的管理，因此注册表中会有服务标识、服务基本信息、服务状态信息等。
③C端定时发送心跳检测
C端定时向S端发送请求服务，告诉S端自己正常运行。
C端只是启动时注册服务信息，后续运行过程中S端并不知道C端是否正常运行，就无法对C端状态进行实时管理。因此C端定时不断向S端发送请求，告诉S端自己正常运行，这种主动上报状态的过程，在Eureka中称为服务续约。
具体实现，S端提供一个续约接口，C端通过定时任务不断调用续约接口，S端收到请求后，更新注册表中服务续约时间。
④S端服务剔除和自我保护
S端如果一段时间内没收到C端心跳请求，就从注册表移除该C端。
心跳检测时C端会定时发送心跳请求，S端收到请求会将注册表中的服务续约时间进行更新，目的是S端可以实时知道C端运行状态。
如果S端在一段时间（默认90s）没收到C端心跳请求，此时S端认为C端挂掉，就会从注册表中移除该C端信息，该过程称为服务剔除。
网络问题引发的通信中断
有时由于网络问题，C端和S端会无法通信，但是此时C端仍然正常运行，按照续约规则，所有的C端会从注册表中被移除，这会影响那些正常运行的C端。
此时S端有自我保护机制来解决这种问题：
S端判断15分钟内，有超过85%的C端都没有进行服务续约，则进入自我保护；
进入自我保护机制后，S端不再剔除未续约C端，S端只接收新C端的注册与服务查询。
⑤C端发送服务下线请求
C端正常关闭，向S端发送服务下线请求，S端会直接从注册表移除该C端。
Eureka通过心跳续约、服务剔除来排查异常服务，对于正常关闭的服务，可以通过发送服务下线请求，使S端从注册表移除C端，该过程称为服务下线。
⑥C端定时获取注册表信息
C端分为生产者（服务提供者）和消费者（服务调用者）。
C端会定时向S端发送请求，获取其注册表信息，保存到本地内存。
在设计中，C端本地也有一个注册表，还有一个定时器，定时从S端更新注册表信息，保存到C端本地内存。
⑦C端整合服务发现
C端消费者从本地注册表获取C端生产者的服务信息，并进行后续操作。
4、Eureka如何保持高可用、一致性
Eureka支持集群部署，在不同机房部署多个S端实例，这样可以横向扩展服务发现的规模，当有一个S端挂掉，其他S端仍能正常运行，保证系统的高可用。但是集群多个节点部署时，需要考虑一个问题，就是数据一致性。
1）CAP理论
Linux：CAP定理——分布式计算 - ShineLe - 博客园
C（Consistency，一致性）：所有节点数据保持一致；
A（Available，可用性）：系统能对请求作出及时响应，不管响应成功还是失败；
P（Partition Tolerance，分区容错）：系统由于某些故障发生分区，各区系统仍能持续提供服务的能力。
这三者是一定无法同时满足的。
作为一个分布式系统，P是必须满足的，否则就失去了分布式的意义。
所以另一个特性只能在C（一致性）和A（可用性）中选择一个：如果要保证一致性，就要进行所有节点的数据同步，该过程中无法保证系统可用性，会出现超时；如果要保证可用性，就无法保证一致性。
Eureka的设计中认为系统可用性优于一致性，采用AP，作为对比的zookeeper采用的是CP（下图所示案例）：
当zookeeper体系下，双机房之间网络时，只有主节点所在的机房能进行正常的服务注册，另一个机房中的从节点无法去主节点同步信息，所以在该机房中会注册失败。此时机房2中由于zk的一致性要求，牺牲了部分可用性。
而对于Eureka而言，采用的是AP，当网络发生分区，机房2中的服务仍可以注册，服务之间也能正常调用，但是两个机房数据会不一致，为了可用性牺牲了一致性。
Eureka为什么采用AP？
在服务发现时注册表信息不会涉及业务逻辑，保存的是一些服务器信息，这些信息不会经常发生变化，换句话说就是不一致的概率比较低，因此采用AP。
2）S端数据同步
分布式系统下数据同步模式一般分为两种：主从模式、对等模式。
主从模式
集群中有一个主副本和多个从副本，主本负责写入，之后会将数据同步到其他从本，从本负责读操作。
该模式下主本面临所有的写操作，可能会成为瓶颈，但能保证一致性。
对等模式
集群中不存在主从副本，每个节点都能进行读写，之后节点之间进行相互数据同步，优点是没有单点写压力，缺点是数据同步、数据冲突是个需要解决的问题。
Eureka中节点进行数据同步的示意图
5、Eureka分区
region
地理上的分区，如亚洲分区、华北分区等等，地区没有具体大小限制，根据实际划分。
zone
可以理解为region下的具体分区（机房），例如北京分区下有两个机房，可以划分出两个区域zone1、zone2。
通过分区管理，可以实现不同区域不同机房的服务进行就近调用，降低延迟。