Spring-Cloud-Netflix-Eureka注册中心
概述
- eureka是netflix的子模块之一,也是一个核心的模块
- eureka里有2个组件:
一个是eurekaserver(一个独立的项目) 这个是用于定位服务以实现中间层服务器的负载平衡和故障转移
一个便是eurekaclient(我们的微服务) 它是用于与server交互的,可以使得交互变得非常简单:只需要通过服务标识符即可拿到服务 - eureka负责管理、记录服务提供者的信息
- 服务调用者无需自己寻找服务,而是把自己的需求告诉eureka,然后eureka会把符合你需求的服务告诉你。
- 类似家政中心,物业
netflix-eureka与springcloud的关系
spring cloud 封装了 netflix 公司开发的 eureka 模块来实现服务注册和发现
eureka原理
- eureka:就是服务注册中心(可以是一个集群),对外暴露自己的地址
- 提供者:启动后向eureka注册自己信息(地址,提供什么服务)
- 消费者:向eureka订阅服务,eureka会将对应服务的所有提供者地址列表发送给消费者,并且定期更新
- 心跳(续约):提供者定期通过http方式向eureka刷新自己的状态,会监听有没有定期更新,如果长时间没有心跳,就会自动把该服务移除
eureka使用
- 在之前工程中添加一个子模块名称为eureka3000
- 在总父工程添加springcloud的依赖集中管理
<dependencymanagement> <dependencies> <dependency> <groupid>org.springframework.cloud</groupid> <artifactid>spring-cloud-dependencies</artifactid> <version>hoxton.sr1</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencymanagement>
- 在eureka3000的子模块中添加依赖
<dependencies> <dependency> <groupid>org.springframework.cloud</groupid> <artifactid>spring-cloud-starter-netflix-eureka-server</artifactid> </dependency> </dependencies>
- 在resources当中创建配置文件application.yml
server: port: 3000 eureka: server: enable-self-preservation: false #关闭自我保护机制 eviction-interval-timer-in-ms: 4000 #设置清理间隔(单位:毫秒 默认是60*1000) instance: hostname: localhost
- 创建启动类,并在启动器上添加enableeurekaserver注解
@springbootapplication @enableeurekaserver public class eureka3000app { public static void main(string[] args) { springapplication.run(eureka3000app.class, args); } }
- 直接启动会报错com.sun.jersey.api.client.clienthandlerexception
原因:
eureka做为注册中心, 做为服务的管理,它不能挂掉, 如果它挂掉,整个服务全部访问不了
因此eureka也要搭建集群多台eureka服务, 集群之间要进行相互之间通信,通信靠的就是eureka-client
eureka是一个服务端, 也是一个客户商, 以后相互注册,现在没有其它的可注册,所以就会报clientexception
解决方案:不让它做为客户端注册,在application.yml添加如下配置
client: registerwitheureka: false #不把自己作为一个客户端注册到自己身上 fetchregistry: false #不需要从服务端获取注册信息(因为在这里自己就是服务端,而且已经禁用自己注册了) serviceurl: #微服务要注册到的地址. #http://localhost:3000/eureka defaultzone: http://${eureka.instance.hostname}:${server.port}/eureka
- 运行后,在浏览器地址栏直接访问http://localhost:3000/
发现启动后,还没有服务进行注册。
服务注册:
- 在user工程中添加eureka客户端相关依赖
<!--eureka的客户端--> <dependency> <groupid>org.springframework.cloud</groupid> <artifactid>spring-cloud-starter-netflix-eureka-client</artifactid> </dependency>
- 在启动器上添加注解@enableeurekaclient
@enableeurekaclient
- 创建application.yml配置文件,配置eureka的服务端地址
server: port: 5000 eureka: client: serviceurl: #eureka服务端提供的注册地址 参考服务端配置的这个路径 defaultzone: http://localhost:3000/eureka instance: instance-id: user-1 #此实例注册到eureka服务端的唯一的实例id prefer-ip-address: true #是否显示ip地址 #eureka客户需要多长时间发送心跳给eureka服务器,表明它仍然活着,默认为30 秒 (与下面配置的单位都是秒) leaserenewalintervalinseconds: 10 #eureka服务器在接收到实例的最后一次发出的心跳后,需要等待多久才可以将此实例删除,默认为90秒 leaseexpirationdurationinseconds: 30 spring: application: name: client-user #此实例注册到eureka服务端的name
- 注册goods,和上面步骤一样,注意改一下的地方
- 启动eureka3000,user,goods注册到注册中心
可以看到已经注册成功
常用配置:
- 服务注册
服务提供者在启动时,会检测配置属性中的:eureka.client.register-with-erueka=true参数是否正确,
事实上默认就是true。如果值确实为true,则会向eurekaserver发起一个rest请求
- 获取服务列表
当服务消费者启动是,会检测eureka.client.fetch-registry=true参数的值,如果为true, 则会从eureka
server服务的列表只读备份,然后缓存在本地。并且每隔30秒会重新获取并更新数据。
eureka.client.registry-fetch-interval-seconds: 5 生产环境中,我们不需要修改这个值。
- 服务续约
eureka: instance: lease-expiration-duration-in-seconds: 90 :服务续约(renew)的间隔,默认为30秒 lease-renewal-interval-in-seconds: 30 :服务失效时间,默认值90秒
在注册服务完成以后,服务提供者会维持一个心跳
也就是说,默认情况下每个30秒服务会向注册中心发送一次心跳,证明自己还活着。如果超过90秒没有发送心跳
eurekaserver就会认为该服务宕机,会从服务列表中移除,这两个值在生产环境不要修改,默认即可。
- 失效剔除
有些时候,我们的服务提供方并不一定会正常下线,可能因为内存溢出、网络故障等原因导致服务无法正常工作 eureka
server需要将这样的服务剔除出服务列表。因此它会开启一个定时任务,每隔60秒对所有失效的服务(超过90秒未响应)进行剔除
可以通过eureka.server.eviction-interval-timer-in-ms参数对其进行修改,单位是毫秒
- 自我保护机制
当把一个服务停掉后, 并不会立马从服务列表当中移除,默认是90秒清除一次
有可以注册中心和微服务之间出现了网络波动,网络不好,没有收到心跳,有可能是网络不好,但是微服务还在,所以它不会立马把服务给移除
当15分钟内85%的心跳都没有正常心跳,那么eureka认为客户端与注册中心出现了网络问题,此时会出现以下情况:
1.eureka不再从注册列表中移除因为长时间没有收到的心跳而过期的服务
2.eureka仍然能够接收服务的注册和查询请求,但是不会被同步到其它节点上
3.当网络稳定后,当前实例新注册的信息会被同步到其它节点上
cap定理(了解)
- 什么是cap定理
cap定理又称cap原则, 指的是在一个分布式系统中,consistency(一致性)、
availability(可用性)、partition tolerance(分区容错性), 最多只能同时三个特性中的两个,三者不可兼得
- consistency (一致性)
“all nodes see the same data at the same time”,
即更新操作成功并返回客户端后,所有节点在同一时间的数据完全一致,这就是分布式的一致性。
- availability(可用性)
可用性指“reads and writes always succeed” 即服务一直可用,而且是正常响应时间。
好的可用性主要是指系统能够很好的为用户服务,不出现用户操作失败或者访问超时等用户体验不好的情况
- partition tolerance(分区容错性)
大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区
分区容错的意思是,区间通信可能失败。比如,一台服务器放在本地,另一台服务器放在外地(可能是外省,甚至是外国),这就是两个区,它们之间可能无法通信
两台跨区的服务器。server1 向 server2 发送一条消息,server2 可能无法收到。系统设计的时候,必须考虑到这种情况.
一般来说,分区容错无法避免,因此可以认为 cap 的 p 总是成立
即分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性或可用性的服务。
分区容错性要求能够使应用虽然是一个分布式系统,而看上去却好像是在一个可以运转正常的整体。
- consistency 和 availability 的矛盾
如果保证 server2 的一致性,那么 server1 必须在写操作时,锁定 server2
的读操作和写操作。只有数据同步后,才能重新开放读写。锁定期间,server2 不能读写,没有可用性 如果保证 server2的可用性,那么势必不能锁定 server2,所以一致性不成立
- 取舍策略
cap三个特性只能满足其中两个,那么取舍的策略就共有三种:
1.ca without p:
如果不要求p(不允许分区),则c(强一致性)和a(可用性)是可以保证的。
但放弃p的同时也就意味着放弃了系统的扩展性,也就是分布式节点受限,没办法部署子节点, 这是违背分布式系统设计的初衷的。
2.cp without a:
如果不要求a(可用),相当于每个请求都需要在服务器之间保持强一致,而p(分区)会导致同步时间无限延长
(也就是等待数据同步完才能正常访问服务)
一旦发生网络故障或者消息丢失等情况,就要牺牲用户的体验,等待所有数据全部一致了之后再让用户访问系统。
3.ap wihtout c:
要高可用并允许分区,则需放弃一致性。 一旦分区发生,节点之间可能会失去联系,为了高可用,每个节点只能用本地数据提供服务
而这样会导致全局数据的不一致性。
抢购商品时,可能前几秒你浏览商品的时候页面提示是有库存的,当你选择完商品准备下单的时候,系统提示你下单失败,商品已售完。这其实就是先在
a(可用性)方面保证系统可以正常的服务,然后在数据的一致性方面做了些牺牲,虽然多少会影响一些用户体验,但也不至于造成用户购物流程的严重阻塞。
没有最好的策略,好的系统应该是根据业务场景来进行架构设计的,只有适合的才是最好的
上一篇: 挑战性能极限——超频概述
下一篇: JDBC-02
推荐阅读
-
Corel Roxio Creator NXT 5破解版安装注册教程(附注册机)
-
jQuery实现用户注册的表单验证示例
-
.NET/C#如何使用反射注册事件详解
-
网友留言须实名注册 国内互联网网站管理者实名制
-
火狐浏览器firefox42不能安装未注册扩展程序
-
win7注册表没有msahci的解决方法
-
Premiere CC 2019图文安装和注册补丁的使用方法
-
ACDSee Ultimate/Pro 2019专业版/旗舰版安装激活破解教程(附注册码)
-
Alien Skin Exposure X4+Bundle注册破解详细安装教程(附破解下载)
-
把任意exe程序注册成windows系统服务的教程