Eureka概念
1.Eureka
1.1
是什么?
Service Discovery
想象一下编写代码调用REST
或者Thrift API
的服务,为了实现这个调用,你的代码需要知道服务实例的网络位置(IP
地址和端口)。
在运行在物理硬件的传统应用中,服务实例的网络位置是相对静止的。
例如,代码可以从配置文件中读取网络位置,这个配置文件偶尔会更新。
但是,在现代基于云的微服务应用中,这是非常难以解决的问题,正如图显示的一样:
服务实例被动态地赋予网路位置
。另外,由于自动伸缩、故障和升级,服务实例集合经常会动态改变。所以客户端代码需要使用详细设计的服务发现机制。
服务发现有2
种模式:
一种是客户端发现模式,一种是服务端发现模式。
当使用
客户端发现模式
时,
客户端负责确定可用服务实例的网络位置并且对通过它们的请求进行负载均衡。客户端查询服务注册中心
,
服务注册中心是一个可用服务实例的数据库
。客户端接着
使用负载均衡算法选择可用的服务实例中的一个并把这个请求路由到该实例。
当服务实例启动的时候,它的网络地址被注册到服务注册中心
。当该
实例终止的时候,该地址从服务注册中心移除
。
服务实例的注册通常使用心跳机制定期刷新
。
Eureka
是
Netflix OSS
开发的服务发现框架,采用的是客户端发现模式。
Springcloud
将它集成在自己的子项目
spring-cloud-netflix
中,实现
springcloud
的服务发现服务发现功能。
包括 Client
与 Server
。Server
被配置和部署为高可用的,每个Server
将已注册服务的状态复制到其他Server
。
1.2
有什么用?
因为在一个完整的系统架构中,任何单点的服务都不能保证不会中断,因此我们需要服务发现机制,在某个节点中断后,其他的节点能够继续提供服务,从而保证整个系统是高可用的。
服务发现是微服务架构的一个关键点。手工配置每个客户端或者某种形式的约定是非常困难和脆弱的。
Eureka Server
会
提供服务注册服务
,各个服务节点启动后,会在Eureka Server
中进行注册,这样Eureka Server
中就有了所有服务节点的信息。
并且Eureka
有
监控页面
,可用在页面中直观的看到所有注册的服务的情况。
同时Eureka
有
心跳机制
,当某个节点服务在规定时间内没有发送心跳信号时,Eureka
会从服务注册中把这个服务节点移除。
Eureka
还提供了
客户端缓存机制
,即使所有的Eureka Server
都挂掉,客户端扔可以利用缓存中的信息调用服务节点的服务。
Eureka
一般配合Ribbon
进行使用,Ribbon
提供了客户端负载均衡的功能,Ribbon
利用从Eureka
中读取到的服务信息,在调用服务节点提供的服务时,会合理的进行负载。
Eureka
通过心跳检查、健康检查、客户端缓存等机制,保证了系统具有高可用和灵活性。
Eureka
与传统负载的区别:
客户端能够获取所要调用的服务端的所有信息。
这种方式的好坏取决你看待和使用它的方式
,如果你需要一个基于Session
的负载,传统的基于代理的负载更适合。
Eureka
更适合无状态的服务,这有利于应用的可扩展性。
当负载均衡中断(宕机)后,应用的高可用性。
传统基于代理的负载均衡器中断后,
整个系统不可用。
而Eureka
将可用的服务端的信息缓存在客户端上,即使 Eureka Server
中断后,系统依然保持可用。
1.3
怎么用?
它提供
REST
API
来注册和查询服务实例。服务实例通过
POST
请求来注册它的网络地址,每隔30s
,它都要通过
PUT
请求来刷新它的注册信息。当服务实例发送HTTP
的
DELETE
请求,或者注册(包括刷新)超时的时候,该注册信息都会从服务注册中心移除。如你所想,客户端可以通过使用
HTTP
的
GET
请求来获取已经注册的服务实例。
Netflix
通过在每个Amazon EC2
可用区域运行一个或者多个Eureka
服务器来
实现高可用性
。每个Eureka
服务器运行在有
弹性IP地址
的EC2
实例上。使用DNS
的TEXT
记录来存储Eureka
集群的配置,这个配置是从可用区域到Eureka
服务器的网络地址的列表的映射表,当Eureka
服务器启动的时候,它查询DNS
来获取Eureka
集群配置,定位它的伙伴,分配给自己一个没有使用的
弹性IP地址
。
Eureka
客户端、服务和服务客户端通过查询
DNS
来发现Eureka
服务器的网络地址。客户端更希望使用在相同可用区域里的Eureka
服务器。但是,如果没有可用的,就需要使用别的可用区域的里的Eureka
服务器。
Eureka
的客户端源码解读
DiscoveryClient.java
这个类中含有了client
侧的很多操作:
Register:
客户端将运行信息注册到 eureka server
。
Renew:
客户端每30s
通过给 server
发送心跳来“续约”,续约告诉 Eureka Server
本实例依然存活。如果 server
超过 90s
依然没有收到续约,就会从注册中移除该实例。
Fetch:
客户端从server
获取注册信息并将他们缓存在本地,然后 client
可以通过这些信息查找 services
。
这些信息会周期性(30s
)的进行增量更新。
这些增量信息在 server
端会保存较长的时间(3 mins
),
因此增量获取可能返回相同的信息,Eureka client
自动处理这些重复信息。
Eureka client
得到增量信息后,通过比较 server
返回的实例数量来融合这些信息。如果信息不匹配,整个注册信息就会被重新获取。 Eureka server
会缓存增量和全量的注册信息,这些信息以JSON
或者XML
返回。(Eureka
使用JSON
)。
Cancel
:客户端可以给服务端发送 Cancel
请求,该请求会从 server
中移除注册信息。这样该客户端将不在接受其他客户端的请求。
生命周期:
信息面版