微服务|微服务系列:服务发现与注册-----Eureka(面试突击!你想了解的Eureka都在这里.持续更新中......)

1.什么是落地SOA(面向服务架构)?
SOA面向服务架构,是一种架构思想,是跨语言和平台的.SOA宗旨简单明了,根据项目服务完成架构搭建,以服务为基准点完成组件化和模块化.提供服务是项目的基本内容,其他的Controller层和View层,只是体现服务的一种形式而已,目标是服务.
面向服务的架构(SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
微服务的概念是14年由James Lewis与Martin Fowler共同提出的,他们定义了微服务是由单一应用程序构成的小服务,拥有自己的进程与轻量化处理,服务依业务功能设计(微服务一个业务一个项目),以全 自动方式部署,与其它服务使用HTTP API 通讯(每个项目都是一个标椎的web项目,不再像之前RPC项目分为provider和consumer)
2.什么是微服务? 新的架构理念,把所有的应用:大型应用,分布式应用,SOA应用 拆解,拆解的极度细致,细致到拆成一个一个的单一的小应用,细致的程度:最细的应用可能就一个方法栈或者一个功能组.以一个方法栈来说:比如说一个电商后台商品新增,从控制器,到服务,到Mapper,到pojo 放在一起打成一个项目,这些项目控制器,服务.接口与接口实现,pojo,配置文件,环境.放在一起,达成一个包,形成一个小的应用,启动 ! 功能就一个方法栈---新增商品.以一个功能组来说:比如说商品后台的管理有:分页查询, 新增商品, 更新(修改)商品, 删除商品, 上架和下架商品 6种功能.这些项目控制器,服务.接口与接口实现,pojo,配置文件,环境.放在一起,达成一个包,形成一个小的应用,启动 !每个单一的小应用就是一个小服务,每个小服务都有自己独立的进程,进程内部自主进行线程规划管理.作为一个轻量化的服务对调用者而言没有任何的侵入.想调用服务,不需要接口,不需要任何的依赖,因为它是基于http协议调用的. 全自动方式部署,用docker做虚拟化开发,或者做打包部署,没有任何的配置,每个jar包就是一个项目,不用任何的环境,启动就完事了!可通过Docker虚拟化技术进行集中化管理,也可通过远程控制的方式集中化管理,(运维方面)自动部署平台集中管理.可跨语种开发.
2.1提出的核心点: 1.微服务是架构 ;
2.微服务中项目都称为服务 ;
3.微服务拆分颗粒度为业务 ;
4.微服务中服务与服务之间使用HTTP协议通信;
(1).微服务目的在于微和跨平台,想把市面上的各种服务抽取出来 ,变成为服务,让所有的服务尽可能的不重复.比如说,一个专门做图片管理的运营商,买了很多的服务器,专门做图片管理,上传图片,在线查看图片,下载图片.任何一个开发的项目都可以买我的服务做图片管理,不管是用什么语言开发的,都可以用,以协议作为标准.
5.微服务和Docker结合使用更方便
(1).docker虚拟化技术,比如拿docker可以虚拟化一个JDK环境,你把你写好的代码放到我的环境里,我再把它打包成一个新的虚拟化工具,你拿走,放到任何地方,知道有docker环境,就可以运行.
6.微服务是分布式架构的一种
(1).RPC软件模型,SOA面向服务编程,微服务架构
2.2为什么使用微服务? 单体应用的特点:大部分的开发者都开发过单体应用,无论是传统的Servlet+JSP ,还是SSM, 还是现在SpringBoot,他们都是单体应用,主要弊端原因如下:
a).部署成本高(无论是修改1行代码,还是10行代码,都要全量替换);
b).改动影响大,风险高(不论代码改动多少,成本都相同);
c).因为成本高,风险高,所以导致部署频率低(无法快速交付客户端需求).
d).无法满足快速扩容,弹性收缩,无法适应云环境特性等环境.
注意: 单体应用虽然有上面的缺点,但是依然有自己的市场,如果项目规模比较小,办公类等不需要频繁修改版本的应用使用单体架构还是很方便的.
2.3微服务特点: 针对特定服务发布,影响小,风险小,成本低; 频繁发布版本,快速交付需求; 低成本扩容,弹性伸缩,适应云环境等特点.
微服务架构与现在企业中敏捷开发思想是匹配的,核心都是强调希望项目快速更新迭代(当项目需要快速更新迭代时微服务架构就特别合适)(这就是为什么使用微服务).
我们知道一个朴素的概念,任何事物都不可能是完美的,任何东西都有两面性,有得必有失,那么选择微服务在解决了快速响应和弹性伸缩的问题的同时,他又给我们带来了什么问题呢?
2.4简单总结如下(微服务架构的缺点): 1.分布式系统的复杂性;
2.部署,测试和监控的成本问题;
3.分布式事务和CAP的相关问题
4.分布式中微服务架构相对于单体架构还需要处理很多事情.例如:分布式事务,团队合作等问题都需要明确的提前设计好.
3.应用架构的变迁: 应用向CloudNative演进, 微服务是CloudNative的事实标准 第一代: 单体架构;

  • 紧耦合
  • 系统复杂、错综交互 , 动一发而牵全身 .
  • 重复制造各种轮子: OS、DB、Middleware
  • 完全封闭的架构
第二代: SOA架构; 通过ESB中间件进行服务调用 ,是要有状态的,相对来说量级较重,效率较低
  • 松耦合
  • 通常通过ESB进行系统集成
  • 有状态
  • 大团队 :100 ~ 200 人
  • TTM : 1年、半年 、月
  • 集中式、计划内停机扩容
第三代: 为服务架构; 自洽(可以自己和自己玩) , 自省 (和外部可交互可不交互), 内聚(需要的代码都放在项目内部).独立访问,独立使用,独立运行. 多版本并行服务(比如游戏在线更新).整体来说 "自动化" .
  • 解耦
  • 小团队 : 2 Pizza Team\
  • TTM: 按天、周进行升级发布
  • DevOps : CI、CD、全自动化
  • 可扩展性 : 自动弹性伸缩
  • 高可用 : 升级、扩容不中断业务
3.1RPC架构和SOA架构和微服务架构的区别? SOA 架构 : 核心消息总线 . 消息总线过于杯中在目前的项目中已经很少使用了.
RPC 架构 : 主要有被调用的远程服务器( Provider) 和调用的服务器 ( Consumer),把所有数据库操作都封装到了Provider. 一个单体拆分成多个,之间使用HTTP通信,每个项目又拆分成两个(Provider和Consumer),之间使用Dubbo协议通信,mapper和service 写到provider中,service和contorller写到consumer中.
微服务服务架构: 每个业务是一个项目.业务之间通信使用HTTP通信协议,不再对一个业务(模块)项目进行拆分成Provider和Consumer了.mapper和service和controller都写到一个项目中.
3.2目前市场上微服务架构的常用实现框架:
实现框架: SpringCloud.
Spring Cloud Netflix : 市场上使用最多的.
Spring Cloud Alibaba :基于Dubbo实现的.
SpringCloud 里面目前包含三体体系:
Spring 自己的 :为了摆脱受Netflix公司限制,所有功能都自己又逐渐推出一套.
4.1SpringCloud简介:
Spring Cloud 是Spring旗下的一个顶级项目.他没有具体的内容,但里面包含了很多的二级子项目, SpringCloud就是这些二级子项目的统称.
Spring Cloud包含了很多二级子项目,每个二级子项目都有对应的功能,所以S品牌日那个Cloud整体的包含的功能是比较强大.
强调:SpringCloud是完全基于SpringBoot的,官方文档中就没有xml配置版本.
Spring Cloud集成时会把Netflix的软件进行打包成一个依赖,我们的项目依赖了对应的jar,可以直接使用这个软件,免去了软件安装的过程(这也是SpringCloud非常大的优点).
4.2.SpringCloud 与Dubbo 的对比:
SpringCloud和Dubbo(SpringCloud Alibaba) 都是微服务开发框架.不是新的技术就一定是好技术.Dubbo优势在于开发简单,效率高.SpringCloud 优势在于功能全面且可靠性高.
微服务|微服务系列:服务发现与注册-----Eureka(面试突击!你想了解的Eureka都在这里.持续更新中......)
文章图片

4.3什么是是服务治理化?
就是做服务开发的,简单粗暴地说,没有微服务的话,就是Provider ,Consumer开发,加了微服务开发,就是简单的微服务处理. 服务注册中心:纯粹的Dubbo没有服务注册中心.
服务调用方式:基于Dubbo的永远是远程调用RPC,SpringCloud 也是RPC,但是它底层协议单一:HTTP.Rest也是HTTP协议下的一套远程请求标椎.
服务网关:Dubbo没有网关.
4.3.1断路由是什么?
就是容错处理.Dubbo容错处理简单粗暴,就是集群容错.说直接一点,远程调用:Consumer调用Provider,调用完了以后出错了,注意:这个出错不是抛异常,因为抛异常是有结果的.远程调用无响应,没有任何结果这是服务调用错误.当你的远程调用服务错误的时候,Consumer再调用一遍(重试),立即返回错误结果(超时),远程服务调用不存在,就当你这个服务没调用,返回一个null,这也是一个返回结果.不管怎么找,这都是一个集群容错
而SpringCloud则使用断路由的方式解决,它可以给你一个你想要的结果,通过配置也好,代码逻辑也好.反正给你一个你想要的结果
总体来说,SpringCloud和Dubbo的对比,SpringCloud大而全(综合性的治理平台 ),Dubbo小而精.
5.Spring Cloud 版本号说明: 1 .常见版本号说明:
开发中,使用的框架版本,最好是RElEASE版本或Final版本.
常见版本号格式为: x.y.z.stage
x - 数字格式主版本号,当功能模块有较大更新或者整体架构发生变化,主版本号会更新
y - 数字格式次版本号,次版本表示只是局部的一些变动.
z - 数字格式修正版本号,一般是bug的修复或者是小变动.
stage - 希腊字母版本号 , 也称为阶段版本号,用于标注当前版本的软件处于那个开发阶段,常用的阶段版本包括: BASE、ALPHA、BATE、RELEASE/FINAL
BASE - 设计阶段.只有相应的设计没有具体的功能实现
ALPHA - 软件的初级版本.存在较多的bug.
BATE - 表示相对ALPHA有了很大的进步,消除了严重的bug,还存在一些潜在的bug.
RELEASE/FINAL - 该版本表示最终版 , 即正式发布版本.
Spring Cloud 是一个包含若干子框架的框架集合体,是一个完整的微服务框架体系,如果使用场景版本号来进行标记,容易混淆主框架版本和子框架版本.所以SpringCloud 使用一种全新的版本号来对主框架进行版本标记,而子框架的版本标记大多还是使用常用版本号标记的
Spring Cloud 版本格式如下: 版本号命名.stage
版本号命名:SpringCloud 主框架版本号是使用英国伦敦地铁站名称来进行标记的.并根据地铁名成的首字母的英文自然升序排列来识别版本的递增.如: Angle、Brixton、Camden、D案例三通、Edgware、Finchley、Greenwich、Hoxton等.后续版本提升会继续根据首字母升序排列.
stage : 现阶段版本号.常用的阶段版本包括:BUILD-xxx[SNAPSHOT]、GA、PRE(M1、M3等)、RC、SR.
BUILD-XXX[SNAPSHOT] - 开发版本、一般是开发团队内部使用.
GA - 稳定版,内部开发到一定阶段了,各个模块集成后,经过全面测试发现没有问题,可对外发行了.这时候叫GA(General Availability).基本上可以使用了.没有严重的BUG问题,但是有未测出的BUG隐患.不推荐商业使用.
PRE - 里程碑版 ,由于GA还不属于公开发行版,里面还有些功能不完善或者bug,于是就有了milestone(里程碑版).milestone版主要修复了一些bug.一个GA后,一般会有多个里程碑版.例如M1、M2、M3\......不推荐商业使用.
RC - 候选发布版,从BUILD后到GA再到M基本上系统就算定型了.这时候系统就进入到Release Candidate(候选发布版本).该阶段的软件类似于最终发行前的一个观察期.该期间支队一些发现的等级高的bug进行修复,发布RC1 RC2 等版本.可以考虑RC版本.
SR - 正式发布版,公布正式发布.正式发布版一般也有多个发布,例如 SR1 SR2 SR3等等,一般用来修复大bug或者优化,最好使用SR版本.
要注意 : Spring Cloud 是基于Spring Boot,不同的Spring Cloud 要使用不同的Spring Boot版本.使用SpringCloud H版本一定使用的是2.2x 不能使用2.3.x版本,如果使用2.3.x可能会出现问题 .
附 : Spring Data的版本命名也是和Spring Cloud 一样的.Spring Data 版本使用字母命名,里面子项目使用数字命名.因为SpringData 和SpringCloud 都是一些列框架的统称.
6.1.Eureka 简介 : Eureka是什么?(本质也是微服务,目的是提供其他服务的注册和发现它们的功能)
Eureka是由Netflix 公司 推出的服务注册和发现工具.现已被SpringCloud集成(集成以后通过SpringBoot快速开发平台封装了一下,变成了一个启动器starter),提供了开箱即用的支持.(直接在项目中直接集成,快捷使用) .写一个启动类,上面加一个@什么什么注解,一运行,你的Eureka就创建好了.
Eureka在使用的时候,它会分成两个角色,一个叫Eureka Server,一个叫Eureka Client.(Eureka,提供服务注册和发现功能.简称注册中心 ; 其它的,通过SpringCloud 集成,开发的微服务,需要在Eureka Server 上进行服务注册和发现的,这些其他的微服务,统称为Eureka Client)
Eureka Client 又人为地分成两个小角色,所有的微服务都是独立的 , 都可以自己运行 ,但相互之间又可以做远程调用. \
无论是服务端还是客户端其本质都是一个项目,在SpringCloud中主要通过启动类上添加@EnableEurekaServer 和 @EnableEurekaClient(可以省略)来区分当前应用程序是服务福安还是客户端.
Eureka Server 可以理解成Zookeeper注册中心,只是现在使用的而是Java项目实现的(Spring Cloud内嵌Eureka)
Eureka Client 可以理解成所有需要注册到Eureka Server 中的项目.为什么需要向注册中心中注册呢? 因为注册后别人才能通过注册中心获取到项目信息和项目所在服务器信息,通过这些信息调用这个项目. SpringCloud中每个项目调用的信息都存储在了注册中心中(Eureka).
注意 : 在这里, Spring Cloud 中没有Provider 和Consumer说法. 若果A项目访问B项目,称A项目为 Application Client , 称B项目为Application Service.同事可能存在C访问A的qingkuang ,这是C项目是Application Client ,A项目是ApplicationService . 发现A项目又是Application Service 又是Application Client ,主要看针对哪个业务场景.无论是Application Service 还是Application Client都是Eureka Client.
6.1Eureka 和Zookeeper 对比(面试):
那既然说Eureka是一个注册中心,那Zookeeper作为Dubbo的注册中心时,这两者有什么样的区别呢?这是一个概念问题.你要说区别这两个注册中心的横向对比.区别一下各个维度的横向对比,那就涉及一个理论-----CAP理论或者说是CAP定理(分布式一致性理论)
6.1.1.CAP理论(核心是C.A.P分别代表一个方面,在分布式环境中,只能三选二,不可兼得):
著名的CAP理论指出,一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性).由于分区容错性在分布式系统中必须要保证的,因此我们只能该在A和C之间进行权衡. 在此Zookeeper保证的是CP,而Eureka则是AP.
C(一致性):在分布式系统中,是否立即达到数据同步的效果(平时多说一致性),在分布式系统一定最终会一致的.如果请求时,整个分布式系统同步后才会返回结果叫做强一致性,(满足一致性).如果先返回结果,在一定时间后才实现一致性就叫做若一致性.
1).所谓的强一致性是任意时间点,任意位置,只要你去找这个服务,不管是服务,还是数据,结果必须准确.
A(可用性) : 在分布式系统中, 其中一些节点出现问题,整个整体是否还可用.
1).1只要你访问分布式中任何一个节点,不管是数据节点,还是服务节点,一定在规定的范围时间内有结果,无论何种情况,必须有结果,不管对错.
P(分区容错性) : 在分布式系统中,是否可以在有限的时间内达到数据一致的效果,如果因为网络等问题最终没有达成一致性,这时称为出现分区错误.
1).所谓的分区容错,就是说当我的分布式环境出现区域性隔离的时候.比如说:搭建某某购物平台的服务器,北京有上还有苏州有等等各地方都有,当你想处理某个业务时,或者说想买个东西,想下单,能不能保证每个地理位置上的相对来说物理隔离的分布式节点最终一致.不管是数据上的还是服务上的,最终是否能达到一致?就像你在北京买东西,新疆不包邮,在新疆买东西,新疆一样还是不包邮,你在北京访问的是北京服务器,在新疆访问的是新疆服务器,都是新疆不包邮,这叫什么? 这叫分区一致. 那如果你在北京访问的是新疆不包邮,在新疆访问的是新疆包邮.那这就是 分区不一致,他就出现了分区错误,因为在最终结果不同,相对物理隔离的多个区域结果不一样.这个结果允许延迟,但这个延迟必须是客户所能容忍的.
6.2.Zookeeper保证 CP :
在Zookeeper 集群中,Zookeeper 的数据保证的是一致性.当Leader出现问题是,整个Zookeeper不可用,需要花费30~120s 来重新选择Leader ,当Leader选举成功以后才能进行访问整个Zookeeper.
1).解释: Zookeeper是单主集群,它的特性是这样的:放几个ZK:1~N个Zookeeper,形成一个单节点或者高可用.当一个单节点或者高可用.它对外提供的服务永远是唯一的一个,不是集群,它只是一个高可用.ZK是内部的节点投票选出来的,你的所有请求都在这个主节点上,响应也都在主节点上.档主节点宕机的时候,其它的节点会商量一下,有所为的投票,投票主节点宕没宕机,会商量一下.相互之间做一个网络通信,然后再都访问一下主节点,看有没有返回结果.如果他们之间的投票超过50%.就会认为主节点宕机.其他节点回来一次选举,再选出一个主节点. 要先投票,再选举,所以它很耗时,比较慢. 这个投票和为选举的过程,就会造成整个这一个Zookeeper离线.没有任何的服务请求可以访问到它,并且响应得到结果.相当于它消失了.那它就不能提供一个A (可用性).因为它难以保证在有限的时限内,一定返回结果.所以他只能保证C(一致性)和P(分区容错性).
一致性:Zookeeper.因为只有一个节点对外提供服务.结果一定是准确的,你任何时间访问这个主节点,数据就一份.都是这个主节点内部的数据,其它节点只负责备份 .所以说它的数据是强一致的.
分区容错:你即使是把他物理隔离在三个不同的Zookeeper,只要出现了主节点宕机,整个集群不对外提供任何服务.只要它提供了服务,它一定是唯一的一个主节点提供的服务,我给他物理隔离只是为了异地多活,避免一个凉凉,全部宕机.
通过这点有也可以看出Zookeeper 是强一致性的, 集群所有节点必须能通信,才能用集群.虽然这样集群数据安全了,但是可用性大大降低了.而作为注册中心来说可用性是很重要的.
6.3Eureka 保证AP :
Eureka 发现Zookeeper 的问题,所以它舍弃了Zookeeper中强一致性,而保证了可用性.在Eureka集群中所有的节点都是保存完整的信息,当Eureka Client 向Eureka中注册信息时,弱国发现节点不可用,会自动切换到另一台的Eureka Server 也就是说整个集
1).解释:Eureka特征是无主集群. 比如说我现在放三个Eureka,你的Eureka Client访问任何一个Eureka节点,无论你做注册,还是发现,都相当于访问整个集群.没有主集群,( 它避免了Zookeeper单点访问的瓶颈.因为它是唯一主节点集群,当Zookeeper主节点访问受限,并发访问将很难处理 ). 访问1号节点做注册的时候,它会自动同步到其他节点(有延迟).如果在2号节点上做发现,这时在2号节点上,可能现在这个时间点上没有服务信息,下一次就有服务信息了,为了保证最终结果的一致,SpringCloud所有的微服务,在做注册和发现的时候,都是周期性的,每隔一段时间,访问一下Eureka,做一次自己的注册和发现. 为了保证最终结果的一致.它的同步效率确实很高,通常是毫秒级别的(几十毫秒-几百毫秒,网络正常通畅的情况下).好处:我在Eureka Client上配置 Eureka Server 节点的时候.把所有的节点和IP都配置上,当Eureka访问第一个节点没有响应逐个访问,直到有反馈为止.除非所有节点都同时宕机.它能保证在容忍的范围时间内一定有结果A(可用性),又因为整体的集群保证了数据的同步,而且还是毫秒级别的,它又保证了P(分区容错).在一定时间内所有区域内的结果最终一致.
【微服务|微服务系列:服务发现与注册-----Eureka(面试突击!你想了解的Eureka都在这里.持续更新中......)】虽然Eureka没有保证强一致,但它保证的最终一致,最终到结果的时候,肯定是相同的.
6.4.ZooKeeper和Eureka完整对比:
对比项
ZooKeeper
Eureka
备注
CAP定理
CP
AP
Dubbo集成
已支持
-------
kv服务
支持
-------
ZK支持数据存储,Eureka不支持
使用接口(多语言工能)
提供客户端(ZKClient、Curator)
http协议(跨语言)
ZK的跨语言支持比较弱
SpringCloud集成
已支持
已支持
watch支持
支持
支持
什么是Watch支持?
就是客户端监听服务端的变化情况.ZK通过订阅监听来实现.
Eureka通过轮询的方式来实现
集群监控
metrics
metrics,
运维者可以收集并报警这些度量信息.达到监控的目的

7.实战!体验自己的第一个Eureka Server: 7.1.创建一个SpringBoot项目,添加如下依赖:
org.springframework.boot spring-boot-dependencies 2.3.2.RELEASE pom import org.springframework.cloud spring-cloud-dependencies Hoxton.SR8 pom import

dependencyManagement标签:
通过它元素来管理jar包的版本,让子项目中引用一个依赖而不用显示的列出版本号。Maven会沿着父子层次向上走,直到找到一个拥有dependencyManagement元素的项目,然后它就会使用在这个dependencyManagement元素中指定的版本号。
统一管理项目的版本号,确保应用的各个项目的依赖和版本一致,才能保证测试的和发布的是相同的成果,因此,在顶层pom中定义共同的依赖关系。同时可以避免在每个使用的子项目中都声明一个版本号,这样想升级或者切换到另一个版本时,只需要在父类容器里更新,不需要任何一个子项目的修改;如果某个子项目需要另外一个版本号时,只需要在dependencies中声明一个版本号即可。子类就会使用子类声明的版本号,不继承于父类版本号。
dependencies标签:
相对于dependencyManagement,所有生命在dependencies里的依赖都会自动引入,并默认被所有的子项目继承。

dependencyManagement与dependencies区别:
dependencies即使在子项目中不写该依赖项,那么子项目仍然会从父项目中继承该依赖项(全部继承)
dependencyManagement里只是声明依赖,并不实现引入,因此子项目需要显示的声明需要用的依赖。如果不在子项目中声明依赖,是不会从父项目中继承下来的;只有在子项目中写了该依赖项,并且没有指定具体版本,才会从父项目中继承该项,并且version和scope都读取自父pom; 另外如果子项目中指定了版本号,那么会使用子项目中指定的jar版本。
7.2.在该SpringBoot项目下创建一个Maven的子moudle____eureka-server写上以下依赖 :
org.springframework.cloud spring-cloud-starter-netflix-eureka-server

7.3.在eureka-server创建启动类,如下图所示:
微服务|微服务系列:服务发现与注册-----Eureka(面试突击!你想了解的Eureka都在这里.持续更新中......)
文章图片


package com.cy.eureka; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer; /** * @EnableEurekaServer - 通知Spring Boot 和Spring Cloud.准备Eureka服务器环境 * 1.启动tomcat * 2.初始化Eureka Server 环境 * 3.发布Eureka Server 服务 (包含一个基于WEB视图的管理平台) * */ @EnableEurekaServer @SpringBootApplication public class EurekaServerApplication { public static void main(String[] args) { SpringApplication.run(EurekaServerApplication.class,args); } }

7.4.接下来将要在eureka-server写一个配置文件,如下示例代码:

#Eureka Server 提供服务的注册和发现的端口,默认是8761 #如果tomcat端口和服务的端口不一致.当前应用同时占用两个端口. server: port: 8761 #tomcat 默认端口仍旧是8080.#Spring Cloud Netflix Eureka Server 对微服务集群的管理基于应用名称. #同名的微服务,自动形成一个服务集群,默认值,是null或''. spring: application: name: eureka-server#给当前的spring应用起名,唯一即可#配置Eureka Client相关信息 #Eureka Server 它同时也是一个Eureka Client: #当它给其它的服务提供注册和发现逻辑的时候,他是Eureka Server #当它向其它Eureka Server提供注册和发现的时候,它就是Eureka Client. #搭建单机版Eureka Server 的时候,不能让这个微服务在本身上注册和发现 #会形成一个无限死循环. eureka: client: register-with-eureka: false #是否注册到其它的Eureka Server 上. 默认 true fetch-registry: false #是否从Eureka Server发现其它服务.默认 true.

7.5.尝试启动,启动成功后,浏览器地址栏输入localhost:8761成功后会出现如下界面:
微服务|微服务系列:服务发现与注册-----Eureka(面试突击!你想了解的Eureka都在这里.持续更新中......)
文章图片

7.6.测试:将端口号改为 8080 ,再次测试一次.会发现服务器的注册和关闭的地址还都是端口号 8761.它同时需要占用两个端口.如下图所示:
微服务|微服务系列:服务发现与注册-----Eureka(面试突击!你想了解的Eureka都在这里.持续更新中......)
文章图片

7.7 在yml配置文件里配置 service-url.defaultZone.如下代码:
#Eureka Server 提供服务的注册和发现的端口,默认是8761 #如果tomcat端口和服务的端口不一致.当前应用同时占用两个端口. server: port: 8080 #tomcat 默认端口仍旧是8080.#Spring Cloud Netflix Eureka Server 对微服务集群的管理基于应用名称. #同名的微服务,自动形成一个服务集群,默认值,是null或''. spring: application: name: eureka-server#给当前的spring应用起名,唯一即可#配置Eureka Client相关信息 #Eureka Server 它同时也是一个Eureka Client: #当它给其它的服务提供注册和发现逻辑的时候,他是Eureka Server #当它向其它Eureka Server提供注册和发现的时候,它就是Eureka Client. #搭建单机版Eureka Server 的时候,不能让这个微服务在本身上注册和发现 #会形成一个无限死循环. eureka: client: register-with-eureka: false #是否注册到其它的Eureka Server 上. 默认 true fetch-registry: false #是否从Eureka Server发现其它服务.默认 true. # 在Eureka Servere 上配置, 是提供服务注册和发现的端口配置 # 在Eureka Client 上配置,是要访问的注册中心注册和发现的地址配置 service-url: defaultZone: http://localhost:8080/eureka/ #配置服务发现和注册的地址.

7.9.再次重启测试:
微服务|微服务系列:服务发现与注册-----Eureka(面试突击!你想了解的Eureka都在这里.持续更新中......)
文章图片

但通常我们还是用 8761 端口作为默认常用进行定义的.以上第7部分就是Eureka Server 单机版的演示.
8.实战! 体验自己第一个Eureka Client . 8.1.创建一个eureka-client 的 maven工程,添加如下依赖:
org.springframework.boot spring-boot-starter-web org.springframework.cloud spring-cloud-starter-netflix-eureka-client

8.2.创建一个启动类,如下代码:
package com.cy.client; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; /** * 低版本的SpringCloud中 ,EurekaClient启动类上需要增加注解 * * @EnableEurekaClient *代表当前应用是一个基于Eureka注册中心的微服务,当前应用时Eureka客户端, * 或者 * @EnableDiscoveryClient *代表当前应用需要基于微服务注册中心,微服务的发现 *当前应用是一个需要做服务发现的客户端 * */@SpringBootApplication public class EurekaClientApplication { public static void main(String[] args) { SpringApplication.run(EurekaClientApplication.class,args); } }

8.3.创建一个controller包,如下代码:
package com.cy.client.controller; import org.springframework.stereotype.Controller; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.ResponseBody; @Controller public class FirstController { @RequestMapping(value = "https://www.it610.com/test",produces = "text/plain; charset=UTF-8") @ResponseBody public String test(){ return "ok!test run"; } }

8.4.创建application.yml文件配置,如下代码:
server: port: 8080 spring: application: name: first-eureka-client eureka: client: service-url: #在Eureka Client中配置此属性,代表注册中心的地址是什么. #多个注册中心地址,使用逗号','隔开. #默认值就是http://localhost:8761/eureka/ defaultZone: http://localhost:8761/eureka/

8.5.先启动Eureka Server ,再启动Eureka Client .登陆localhost:8761.成功会有如下显示:
微服务|微服务系列:服务发现与注册-----Eureka(面试突击!你想了解的Eureka都在这里.持续更新中......)
文章图片

附:如果想测试服务器集群,可在Eureka Client中复制一份启动类.application.yml修改一个端口号后启动第二个启动类.即可看到同名不同端口的服务器集群,如下图所示:
微服务|微服务系列:服务发现与注册-----Eureka(面试突击!你想了解的Eureka都在这里.持续更新中......)
文章图片

8.6.如果页面出现以下红字:
微服务|微服务系列:服务发现与注册-----Eureka(面试突击!你想了解的Eureka都在这里.持续更新中......)
文章图片

给大家解释一下,这个叫自我保护,说难听点,就是自己骗自己,谁骗自己呢------Eureka Server.
这所谓自我保护,它是对服务列表的一种保护.默认环境中,微服务每隔30秒发一个心跳信息,发到Eureka Server 上,Eureka Server每隔30秒检查一下心跳信息,在间隔三次无心跳,代表服务离线,从服务列表中删除该服务信息.极值最大90s,最小60s.
但微服务注册中心Eureka它有这样一种想法:如果在一定的时间内,大面积服务宕机离线.它会自己骗自己,做到自我保护.它认为这是网络波动而导致的无心跳.这个大面积具体点指的是85%服务有效,15%服务无效..让管理人员看到这个警告以后,检查一下是否是因为网络而导致的问题.
因为微服务中,如果真的超过15%的服务同时离线的话,这是一个很严重的问题了.
9.搭建Eureka Server 高可用集群. 9.1.eureka-server创建配置文件application-eureka1.yml和application-eureka2.yml(之前那个application.yml将不再使用,根据自己需要选择删除或者改名):
server: port: 8761 spring: application: name: eureka-server-cluster eureka: instance: hostname: eureka-one #实例名称,只要多个eureka server命名不同即可。 client: service-url: #配置集群中,除本身外的所有节点的地址, 多个地址用逗号分隔 #代表当前Eureka Server 作为微服务角色的时候。在那些注册中心上注册和发现服务 #定义的地址信息,最好基于域名或主机名配置,IP也可 defaultZone: http://eurekatwo:8761/eureka/


server: port: 8761 spring: application: name: eureka-server-cluster eureka: instance: hostname: eureka-two #实例名称,只要多个eureka server命名不同即可。 client: service-url: #配置集群中,除本身外的所有节点的地址, 多个地址用逗号分隔 #代表当前Eureka Server 作为微服务角色的时候。在那些注册中心上注册和发现服务 #定义的地址信息,最好基于域名或主机名配置,IP也可 defaultZone: http://eurekaone:8761/eureka/

9.2.准备打包:
9.2.1.在总pom文件里加入以下代码:
org.springframework.boot spring-boot-maven-plugin repackage repackage

9.2.2.在eureka-server的pom文件里加入以下代码:
org.springframework.boot spring-boot-maven-plugin

9.2.3 .在eureka-server的Maven里双击package打包。
微服务|微服务系列:服务发现与注册-----Eureka(面试突击!你想了解的Eureka都在这里.持续更新中......)
文章图片


9.2.4.可在文件目录里查看一下:
微服务|微服务系列:服务发现与注册-----Eureka(面试突击!你想了解的Eureka都在这里.持续更新中......)
文章图片

9.2.5在target目录下输入cmd打开控制台,输入运行java -jar -Dspring.profiles.active=eurekaone eureka-server-0.0.1-SNAPSHOT.jar :
微服务|微服务系列:服务发现与注册-----Eureka(面试突击!你想了解的Eureka都在这里.持续更新中......)
文章图片

???????微服务|微服务系列:服务发现与注册-----Eureka(面试突击!你想了解的Eureka都在这里.持续更新中......)
文章图片

解释上述是做什么的:-D是给它一个启动环境变量。它读取的是我们写的application-eureka1.yml的配置代码文件。但目前应该是处于一个错误状态。因为找不到另外一个服务。因为咱们再配置的时候写了一下,要在eurekatwo:8761中做注册。目前找不到,因为eurekatwo还没有启动。

    推荐阅读