springcloud实践(一)服务意识:Eureka

Eureka 中的3个角色

图片 1

Eureka有二种剧中人物:

  1. Service Registy服务注册表,提供注册和询问服务
  2. Provider向服务注册表注册服务、续约服务
  3. Consumer从劳动注册表查询到Provider的服务实例,并且选用实例进行直接调用。

瑟维斯 Registy服务注册宗旨

  1. 数据如何存款和储蓄。能够保持在内存、本和姑件、数据库等等
  • Eureka选取保持在内部存款和储蓄器中。
  1. 何以提供注册服务。Http、ENCOREpc等等
  • Eureka提供http格局注册服务
  1. 怎么提供查询服务。
  • 劳务消费者向劳动登记中央查询服务提供方消息,并缓存到地面。
  1. Provider变化时,如何打招呼Consumer。接纳推的不二法门照旧拉的不二法门,实时还是定时等
  • Eureka选取实时推送
  1. 劳动注册表的节点之间怎么进展音讯的同台和复制
  • 差不多说,正是请求转载,前边会开展讲
  1. 当有着的服务注册表节点都Down掉后再次启航,怎么样重新获得注册音信。从数据库中再度加载,从缓存中读取,照旧须要Provider发送心跳时再一次保存
  • Eureka在Provider发送心跳时再一次保存。

Service Provider 服务提供方

  1. 运营时向服务注册表发送注册新闻:服务登记
  2. 关门时向劳动注册表发送废除新闻:服务下线
  3. 维持心跳,使得劳动注册表能够得到Provider的流行状态:服务续约

Service Consumer 服务消费者

  1. 透过服务注册表查询Provider的实例:服务赢得
  2. 客户端负载均衡:Ribbon
  3. 客户端缓存:本地缓存

集群时期的图形服务器架设(实时同步)

在website站点上边,新建贰个名为upload的虚拟目录,由于虚拟目录的油滑,能在早晚水准上代表物理目录,并同盟原有的图纸上传和做客方式。用户的造访格局如故是:

http://www.yourdomain.com/upload/qa/test.jpg

优点:配置尤其灵敏,也能匹配老版本的上传和走访格局。

因为虚拟目录,能够针对本地任意盘符下的妄动目录。那样一来,还足以经过连接外置存款和储蓄,来展开单机的体积扩大。

症结:布置成由多台Web服务器组成的集群,种种Web服务器(集群节点)之间(虚拟目录下的)需求实时的去一起文件,由于联合效能和实时性的限量,很难保险某一随时各节点上文件是完全一致的。

宗旨架构如下图所示:

 图片 2

从上海体育地方可看出,整个Web服务器架设已经怀有“可扩展、高可用”了,主要难题和瓶颈都集聚在多台服务器之间的公文同步上。

 

上述架构中只可以在这几台Web服务器上相互“增量同步”,那样一来,就不帮衬文件的“删除、更新”操作的一块了。

最初的想法是,在应用程序层面做决定,当用户请求在web1服务器举办上传写入的还要,也一并去调用其余web服务器上的上传接口,那明明是小题大作的。所以我们选取使用LX570sync类的软件来做定时文件同步的,从而省去了“重复造轮子”的资金,也下落了危害性。

同步操作里面,一般有相比经典的二种模型,即推拉模型:所谓“拉”,就是指轮询地去赢得更新,所谓推,就是产生转移后主动的“推”给任何机器。当然,也足以使用加高级的轩然大波通报机制来实现此类动作。

在高并发写入的场景中,同步都会出现频率和实时性难点,而且大量文件同步也是很费用系统和带宽能源的(跨网段则更明显)。  

Why not use Curator/Zookeeper as a service registry?(本身未采纳过在zookeeper,就不在此深究)

官方说法:

There are some overlaps in certain areas of what Zookeeper and Eureka
provide especially in the areas of replicating registry information.
Eureka could use zookeeper to cache registry information and replicate
the same, but replication is just a small part of what Eureka provides.

Eureka deals with various other things apart from replication:

  • REST end points that deal with registrations, renewals, expirations
    and cancels.
  • Keeping the instance information up-to-date dealing with the
    intricacies of EIP binding, deployment rollbacks, autoscaling in a
    resilient manner.
  • Being resilient to network outages between clients and servers and
    between peers.

Zookeeper’s power comes to the fore with leader election, ordered
updates, distributed synchronization along with its consistency
guarantees (quorums).

None of the above except the replication registry really applies to
Eureka to justify an other dependency that we have to deal with the
following complications:

  • You will have to now find a way to assign EIPs to zookeeper similar
    to Eureka.
  • Deal with failures when zookeeper fails.

And further more, Eureka has been built carefully without any hard
dependency on any external components .

  • Most services rely on Eureka to bootstrap themselves.
  • To reduce the complexity.
  • Avoid another failure point.

其余一篇文章中也做了对待:Zookeeper做登记核心的败笔

文中主要建议了七个缺陷:

  • ZooKeeper不能很好的处理互连网分区难题,当互联网分区中的客户端节点无法到达Quorum时,会与ZooKeeper失去联络,从而也就无法利用其劳动意识体制。(在ZooKeeper中,即使在同贰个网络分区(partition)的节点数(nodes)数达不到
    ZooKeeper选择Leader节点的“法定人数”时,它们就会从ZooKeeper中断开,当然还要也就无法提供Service发现服务了。)
  • 服务意识系统应该是七个AP系统,设计上针对可用性;而ZooKeeper是贰个CP系统。
  • ZooKeeper的安装和保卫安全万分劳累,实操的时候也简单失误,比如在客户端重建沃特cher,处理Session和十分的时候。

自然,PeterKelley提议的那多少个难点并不是不能够克制的,并不可能印证基于ZooKeeper就不可能做好二个劳务意识系统,可是大家大概有更简单的方案比如Eureka来落实。

缓解方案如下:

第1,关闭旧版本上传入口(制止后续利用导致数据不等同)。将旧图片数据经过rsync工具三回性迁移到独门的图片服务器上(即下图中讲述的Old
Image
Server)。在最前端(七层代理,如Haproxy、Nginx)用ACL(访问规则控制),将旧图片对应U中华VL规则的伸手(正则)匹配到,然后将请求直接转接内定的web
服务器列表,在该列表中的服务器上安排好提供图片(以Web格局)访问的站点,并参与缓存策略。那样完结旧图片服务器的分别和缓存,兼容了旧图片的走访规则并升级旧图片访问功效,也制止了实时同步所拉动的标题。

 

完全架构如图:

 图片 3

基于法斯特DFS的独自图片服务器集群架构,尽管早已尤其的多谋善算者,不过出于国内“南北互联”和IDC带宽开支等题材(图片是可怜消耗流量的),大家最后依旧选取了商用的CDN技术,达成起来也12分不难,原理其实也很简短,作者那里只做个大约的介绍:

将img域名cname到CDN厂商钦赐的域名上,用户请求访问图片时,则由CDN厂商提供智能DNS解析,将多年来的(当然也恐怕有任何更复杂的政策,例如负载情状、健康景况等)服务节点地址重临给用户,用户请求到达钦命的服务器节点上,该节点上提供了近似Squid/Vanish的代办缓存服务,假如是率先次呼吁该路线,则会从源站获取图片能源重回客户端浏览器,借使缓存中存在,则向来从缓存中获得并赶回给客户端浏览器,完成请求/响应进度。

出于采纳了商用CDN服务,所以大家并从未考虑用Squid/Vanish来自行创设前置代理缓存。

地点的任何集群架构,能够很有利的做横向增添,能知足一般垂直领域中大型网站的图片服务须要(当然,像taobao那样超大规模的恐怕另当别论)。经测试,提供图片访问的单台Nginx服务器(至强E5四核CPU、16G内部存款和储蓄器、SSD),对小静态页面(压缩后大概唯有10kb左右的)能够扛住几千个并发且毫无压力。当然,由于图片自己体量比纯文本的静态页面大过多,提供图片访问的服务器的抗并发能力,往往会受限于磁盘的I/O处理能力和IDC提供的带宽。Nginx的抗并发能力依旧非常强的,而且对财富占用十分低,特别是处理静态财富,就好像都不要求有过多操心了。能够依照实际访问量的急需,通过调整Nginx的参数,对Linux内核做调优,参与分级缓存策略等手段能够做更大程度的优化,也足以经过扩充服务器或然升级服务器配置来做扩充,最直白的是由此购销更尖端的存储设备和更大的带宽,以满意更大访问量的供给。

值得一提的是,在“云计算”流行的当下,也援引高速发展之间的网站,使用“云存款和储蓄”那样的方案,既能帮您化解各项存款和储蓄、扩张、备灾的标题,又能做好CDN加速。最重庆大学的是,价格也不贵。

小结,有关图片服务器架设扩展,大概围绕这几个标题展开:

  1. 体量规划和扩展难题。
  2. 数码的协同、冗余和容灾。
  3. 硬件设备的资产和可相信性(是一般机械硬盘,依旧SSD,只怕更高端的存款和储蓄设备和方案)。
  4. 文件系统的选料。依照文件特性(例如文件大小、读写比例等)采用是用ext四分三照旧NFS/GFS/TFS那个开源的(分布式)文件系统。
  5. 图片的增长速度访问。选用商用CDN或许自行建造的代办缓存、web静态缓存架构。
  6. 旧图片路径和访问规则的包容性,应用程序层面包车型大巴可扩充,上传和走访的性格和安全性等。

Resilience 弹性

Eureka clients are built to handle the failure of one or more Eureka
servers. Since Eureka clients have the registry cache information in
them, they can operate reasonably well, even when all of the eureka
servers go down.Eureka clients将数据缓存在地头,尽管全部Eureka
servers都挂了,还是能平常运转。

Eureka Servers are resilient to other eureka peers going down. Even
during a network partition between the clients and servers, the servers
have built-in resiliency to prevent a large scale outage.
当别的server挂了,只怕网络中断了, server还能独立工作

单机时期的图片服务器架设(集中式)

初创一时半刻由于岁月燃眉之急,开发人员水平也很简单等原因。所以普通就直接在website文件所在的目录下,建立一个upload子目录,用于保存用户上传的图片文件。假使按工作再细分,能够在upload目录下再建立差别的子目录来分裂。例如:upload\QA,upload\Face等。

在数据库表中保存的也是”upload/qa/test.jpg”这类相对路径。

用户的拜访格局如下:

http://www.yourdomain.com/upload/qa/test.jpg

次第上传和写入措施:

程序员A通过在web.config中布局物理目录D:\Web\yourdomain\upload 
然后通过stream的法子写入文件;

程序员B通过Server.Map帕特h等情势,依照绝对路径获取物理目录 
然后也经过stream的章程写入文件。

可取:达成起来最简便易行,无需任何复杂技术,就能打响将用户上传的公文写入钦赐目录。保存数据库记录和走访起来倒是也很有益于。

缺陷:上传格局混乱,严重不便利网站的恢宏。

本着上述最原始的架构,首要面临着如下难点:

  1. 乘势upload目录汉语件越多,所在分区(例如D盘)要是出现体量不足,则很难扩大容积。只可以停机后转移更大容积的存款和储蓄设备,再将旧数据导入。
  2. 在配备新本子(安插新本子前透过供给备份)和普通备份website文件的时候,须求同时操作upload目录中的文件,固然考虑到访问量回涨,前面铺排由多台Web服务器组成的载荷均衡集群,集群节点之间一旦做好文件实时同步将是个难点。

 

How New Peer Initializes新节点起初化

运行时把温馨视作是瑟维斯 Consumer服务消费者,从任何Peer Eureka获取(get
Registry)全部服务的登记音信(即一对一于获取服务列表)。然后遍历服务列表,对各种服务,在大团结那里实行Register,isReplication=true,从而做到开头化。

此时此刻的图纸服务器架设(分布式文件系统+CDN)

在营造当前的图纸服务器架设在此以前,能够先彻底甩掉web服务器,间接配置单独的图形服务器/域名。但面临如下的标题:

  1. 旧图片数据怎么做?能或不可能持续合营旧图片路径访问规则?
  2. 独自的图形服务器上急需提供单身的上传写入的接口(服务API对外发布),安全题材何以确定保障?
  3. 同理,假设有多台独立图片服务器,是行使可扩张的共享存款和储蓄方案,照旧使用实时同步机制?

 

直到应用级其他(非系统级) DFS(例如法斯特DFS HDFS MogileFs
MooseFS、TFS)的风靡,简化了这些问题:执行冗余备份、支持自动同步、协理线性扩大、扶助主流语言的客户端api上传/下载/删除等操作,部分帮助文件目录,部分扶助提供Web的措施来做客。

考虑到各DFS的特点,客户端API语言帮衬情状(须要帮衬C#),文档和案例,以及社区的帮助度,大家最终选取了法斯特DFS来布局。

唯一的题材是:大概会不包容旧版本的走访规则。假若将旧图片三回性导入法斯特DFS,但出于旧图片访问路径分布存款和储蓄在差异工作数据库的各种表中,全部立异起来也拾叁分困难,所以必须得非凡旧版本的造访规则。架构升级往往比做全新架构更有难度,正是因为还要协作在此以前版本的难题。(给飞机在空间换引擎可比造架飞机难得多)

Eureka 怎么着管理服务?

劳动治理的真相:服务的增加和删除改查。

增:注册。有服务提供方向服务登记宗旨登记。

删:服务清除。服务登记中央将定时清除失效服务。

改:无

查:服务意识、获取。由劳务消费者向服务注册中心取得服务提供方新闻。

劳动续约:服务提供方定时向劳动登记中央发送心跳(暗许30秒发送三遍),服务提供方超过一段时间(暗中同意90秒)未向劳动注册中央发送心跳,则服务登记中央将劳动下线。

鉴于数量是缓存在地头,首要正是对registry变量进行操作。

private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry =new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();

集群时期的图纸服务器架设立异(共享存款和储蓄)

 沿用虚拟目录的方法,通过UNC(网络路径)的法子达成共享存款和储蓄(将upload虚拟目录指向UNC)

用户的走访方式1:

http://www.yourdomain.com/upload/qa/test.jpg

用户的造访格局2(能够配备独立域名):

http://img.yourdomain.com/upload/qa/test.jpg

支撑UNC所在server上计划独立域名指向,并铺排轻量级的web服务器,来兑现独立图片服务器。

   优点:
通过UNC(互联网路径)的措施来开始展览读写操作,可避防止多服务器之间同步相关的题目。相对来讲很灵巧,也支撑扩大体积/扩充。扶助配置成单身图片服务器和域名访问,也完全包容旧版本的拜访规则。   

   缺点
:然而UNC配置有些麻烦,而且会导致一定的(读写和平安)品质损失。只怕会出现“单点故障”。假诺存储级别没有raid也许更尖端的灾备措施,还会导致数据丢失。

基本框架结构如下图所示:

 图片 4

在后期的累累基于Linux开源架构的网站中,倘使不想一起图片,或者会使用NFS来兑现。事实注明,NFS在高并发读写和海量存款和储蓄方面,成效上存在一定难题,并非最佳的挑选,所以当先二分一网络商户都不会使用NFS来兑现此类应用。当然,也能够经过Windows自带的DFS来贯彻,缺点是“配置复杂,效能未知,而且缺少资料多量的其实案例”。其它,也有局地店铺利用FTP或Samba来贯彻。

 

地方提到的三种架构,在上传/下载操作时,都因而了Web服务器(尽管共享存款和储蓄的那种架构,也能够配备独立域名和站点来提供图片访问,但上传写入还是得经过Web服务器上的应用程序来拍卖),那对Web服务器来讲确实是导致巨大的下压力。所以,更建议使用独立的图样服务器和独立的域名,来提供用户图片的上传和访问。

Eureka 进阶

单独图片服务器/独立域名的利益

  1. 图片访问是很开支服务器资源的(因为会波及到操作系统的上下文切换和磁盘I/O操作)。分离出来后,Web/App服务器能够更小心发挥动态处理的能力。
  2. 独立存款和储蓄,更利于做扩大容积、容灾和数目迁移。
  3. 浏览器(相同域名下的)并发策略限制,品质损失。
  4. 访问图片时,请求消息中总带cookie消息,也会招致质量损失。
  5. 惠及做图片访问请求的负载均衡,方便使用种种缓存策略(HTTP
    Header、Proxy Cache等),也进一步便利迁移到CDN。

……

 

我们能够动用Lighttpd或然Nginx等轻量级的web服务器来架构独立图片服务器。

Non-Java services and clients

对此非java语言的服务:

  1. 用该语言完成client的效应
  2. 通过side car 机制得以实现。

在主流的Web站点中,图片往往是不可或缺的页面成分,特别在巨型网站中,差不多都将面临“海量图片财富”的存储、访问等相关技术难点。在针对图片服务器的架构扩张中,也会历经重重弯弯曲曲甚至是血泪教训(尤其是最初设计不足,造成前期架构上很难包容和扩充)。

替代性技术

SpringCloud提供了二个劳务意识组件:Eureka/Consul/Zookeeper。在摩拜公开的SpringCloud实践的PPT中,选取了是Consul。

洋洋铺面为此选用Windows(.NET)平台来创设网站和图片服务器,很当先1/4由创始团队的技巧背景决定的,早期的技术职员或者更熟稔.NET,或许组织的决策者认为Windows/.NET的易用性、“短平快”的支付情势、人才基金等地方都相比吻合创业初期的团队,自然就分选了Windows。中期工作发展到自然规模,也很难轻易将总体架构迁移到别的开源平台上了。当然,对于构建大规模网络,更建议首要选用开源架构,因为有为数不少成熟的案例和开源生态的支撑(也会有好多坑,就看是你协调第①去踩坑,依旧在外人踩了修复之后您再用),防止重复造轮子和开支高额授权开支。对于迁移难度较大的选拔,个人相比较推荐Linux、Mono、Jexus、Mysql、Memcahed、Redis……混搭的架构,同样能支撑具有高并发访问和天数据量等特色的互连网选取。

参考文献

本文将以贰个诚实垂直门户网站的发展进度,向大家连连道来。

七台河身份验证

Eureka
Server的达州认证官网链接-老版本

在新式版本中位居了config中
client

假定客户端的eureka.client.serviceUrl.defaultZone参数值(即Eureka
Server的地点)中隐含HTTP Basic
Authentication音信,如http://user:password@localhost:8761/eureka,那么客户端就会活动使用该用户名、密码消息与Eureka服务端进行认证。要是你供给更复杂的辨证逻辑,你不能够不注册3个DiscoveryClientOptionalArgs组件,并将ClientFilter零件注入,在此地定义的逻辑会在历次客户端向服务端发起呼吁时进行。

server端配置:

security:
  user:
     name: ziyun
     password: dd2016

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>

client配置

http://user:password@EurekaHost:EurekaPort/eureka/

eureka:
  client:
    serviceUrl:
      defaultZone: http://ziyun:dd2016@eureka-server:10001/eureka/

note: 密码不能带特殊符号!!!

创设在Windows平台之上的网站,往往会被正式众多技能认为很“保守”,甚至会有点。很超越51%原因,是由于微软技能连串的封闭和某个技术人士的打草惊蛇造成的(当然,首要依然人的难点)。由于长时间缺少开源帮助,所以广大人只好“闭门造车”,那样很简单形成思维局限性和短板。以图表服务器为例子,假若早期没有容积规划和可扩展的宏图,那么随着图片文件的随处追加和访问量的提高,由于在性质、容错/容灾、增添性等方面包车型地铁安顿不足,后续将会给开发、运营工作带动很多题材,严重时甚至会潜移默化到网站业务健康运转和互连网企业的进步(那决不是在震惊)。

是什么?

Eureka 是 Netflix 开源的贰个 RESTful服务,主要用于服务登记与发现。

它由Eureka server 和Eureka client组成。

Eureka server提供服务的注册、删除、查询、续约等成效,是劳务管理主旨。

Eureka cliet用来向server注册服务、查询服务、调用服务等。

入门Demo示例

网上demo很多,仅供参考。
史上最简易的SpringCloud教程 | 第①篇:
服务消费者(rest+ribbon)

Why not use HA proxy for load balancing?

  1. 跟session非亲非故时,能够绝不ha proxy;
  2. haproxy的弹性、灵活度没有Eureka client高, 因为Eureka
    server恐怕会动态变化。

周边难点及缓解方案

  1. Eureka进入了自小编爱戴方式,

提醒音讯如下:EME奥迪Q5GENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES
ARE UP WHEN THEY’RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE
THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.

消除方案:

 1、 注册中心关闭自我保护机制,修改检查失效服务的时间。

eureka:
  server: 
    enable-self-preservation: false
    eviction-interval-timer-in-ms: 3000
2、 微服务修改减短服务心跳的时间。

# 默认90秒
lease-expiration-duration-in-seconds: 10
# 默认30秒
lease-renewal-interval-in-seconds: 3


eureka:
  server:
    enable-self-preservation: false  #关闭自我保护,仅在开发环境中采用此配置。
    eviction-interval-timer-in-ms: 3000 续期时间,即扫描失效服务的间隔时间(缺省为60*1000ms)
  instance:
    prefer-ip-address: true
    lease-expiration-duration-in-seconds: 10 # 发呆时间,即服务续约到期时间(缺省为90s)
    lease-renewal-interval-in-seconds: 3 # 心跳时间,即服务续约间隔时间(缺省为30s)
  client:
    registry-fetch-interval-seconds: 3 # 默认为30秒

产生原因:Eureka
Server在运转时期,会总括心跳战败的百分比在1五秒钟以内是还是不是低于85%,假若现身低于的情状(在单机调节和测试的时候很不难满意,实际在生养条件上无独有偶是出于互联网不平稳造成),Eureka
Server会将近来的实例注册音讯保险起来,同时提示那几个警示。体贴形式首要用以一组客户端和Eureka
Server之间存在网络分区场景下的保卫安全。一旦进入爱抚格局,Eureka
Server将会尝试尊敬其服务注册表中的音讯,不再删除服务注册表中的数据(也便是不会撤消任何微服务)。

  1. 哪些处理服务挂掉后照旧手动关闭服务后,Ribbon负载均衡依旧直接调用那几个服务,然后调用@HystrixCommand断路器申明的措施:利用Hystrix,在error
    callback方法中能够shutdown钦定的server

    ZoneAwareLoadBalancer<Server> lb = (ZoneAwareLoadBalancer<Server>) springClientFactory.getLoadBalancer("CLOUD-SERVICE");
    Server server = lb.chooseServer();
    System.out.println("error->" + server.getHostPort());
    lb.markServerDown(server);
    

    除此以外在Camden.SRubicon3中得以布署Ribbon请求重试,能够参见DD大神的新作:为Spring
    Cloud
    Ribbon配置请求重试(Camden.S福睿斯2+)

  2. 改变eureka server中注册的劳务的例行检查和测试方法

私下认可的心跳达成情势得以有效的检查eureka客户端进程是还是不是健康运转,可是不可能担保客户端应用能够健康提供劳务。

是因为超越贰分之一微服务应用都会有一部分别的的表面能源信赖,比如数据库,REDIS缓存等,如果大家的运用与那几个外部能源不能接通的时候,实际一月经无法提供符合规律的对外地劳工务了,但因为客户端心跳如故在运转,所以它依然会被劳务消费者调用,而如此的调用实际上并不能够获得预期的后果。

大家能够通过在eureka客户端中布局:eureka.client.healthcheck.enabled=true,就足以改变eureka
server对客户端健康检查和测试的办法,改用actuator的/health端点来检查和测试。

改变eureka
server中注册的劳动的符合规律检查和测试方法

Spring
Cloud实战小贴士:健检

How Peer Replicates集群怎样进展联合?

具体落到实处格局:接收到Service Provider请求的Eureka
Server,把请求再度转向到任何的Eureka
Server,调用同样的接口,传入同样的参数,除了会在header中标记isReplication=true,从而制止重复的replicate。

Eureka 入门

高可用性–>集群

哪些创设集群?

Eureka server 还能当做 Eureka client,指向其余三个Eureka Server。

Eureka sever A

spring:
  profiles: development_ha1
  application:
      name: eureka-server-ha1
eureka:
  server:
    enable-self-preservation: false  #关闭自我保护,仅在开发环境中采用此配置。
    eviction-interval-timer-in-ms: 3000
  instance:
    prefer-ip-address: true
    lease-expiration-duration-in-seconds: 10
    lease-renewal-interval-in-seconds: 3
  client:
    registry-fetch-interval-seconds: 3 # 默认为30秒
    serviceUrl:
      defaultZone: http://ziyun:dd2016@192.168.100.119:10001/eureka/

Eureka sever B

spring:
  profiles: development_ha2
  application:
      name: eureka-server-ha2
eureka:
  server:
    enable-self-preservation: false   #关闭自我保护,仅在开发环境中采用此配置。
    eviction-interval-timer-in-ms: 3000
  instance:
    prefer-ip-address: true
    lease-expiration-duration-in-seconds: 10
    lease-renewal-interval-in-seconds: 3
  client:
    registry-fetch-interval-seconds: 3 # 默认为30秒
    serviceUrl:
      defaultZone: http://ziyun:dd2016@192.168.100.118:10001/eureka/

重庆大学配置为

client:
    serviceUrl:
      defaultZone: http://ziyun:dd2016@192.168.100.118:10001/eureka/

client:
    serviceUrl:
      defaultZone: http://ziyun:dd2016@192.168.100.119:10001/eureka/

发表评论

电子邮件地址不会被公开。 必填项已用*标注