eureka原理及执行流程(eureka原理及使用)

前言

现在在大型项目开发中,基本上都用到了微服务架构。微服务架构有很多优点,核心是把大型复杂项目拆分成多个单元进行开发部署,实现了项目解耦。在开发过程中,分拆后的独立单元开发难度降低。在项目运行过程中,可针对用户访问流量大的服务单独扩展,从而能够节约资源。今天通过一个生活中的例子给大家讲一讲Spring Cloud微服务架构。

如何开好一家饭店

假如要开一家饭店,首先要考虑的是饭店运营问题。通常的做法是,根据运营情况来安排工作岗位,招聘人员来实现岗位职责。这个过程就是微服务中的服务分拆。假如经过分拆后有以下岗位,经理、保安、点餐员、厨师、配菜员、收费员、清洁工等等。每个岗位都一个服务,每个服务不是都面对客户,比如厨师不面对客户,只按照点餐员的要求做菜,做完菜也不用上菜,由服务员上菜。这就是服务间的互相调用,服务间拆分之后又相互协作,就支撑起了饭店的整体运营工作。理解了这个,下面讲一下Spring Cloud五大组件。

Spring Cloud五大组件

Spring Cloud包含五大组件,分别为eureka、zuul、RibbonHystrixSpring Cloud Config。下面根据饭店营业过程来详细聊一聊这五个组件的作用。

注册中心

现在饭店刚开业,员工们之间都相互不熟悉,会有一大堆问题,这就需要经理来协调了。比如点餐员说:“客人已点完餐了,找谁做?”,经理会说让某某厨师去做。厨师会问:“食材没有了,找谁”,经理会说让后勤人员采购,等等!经理就相当于注册中心,任何服务在运行之前要注册,在调用其它服务时有注册中心负责协调。

eureka原理

eureka原理及执行流程(eureka原理及使用)

eureka主要功能

  • 服务注册:保存注册客户端的IP、端口号,如有故障的客户端会交期在删除。
  • 功能提供:向外提供已注册服务的IP、端口号。

其它常用的注册中心有:dubbo、nacos、consul

网关

饭店知名度比较好,每天来的人非常多。来的客人中有来吃饭的,有来观光旅游的,有的迷路来问路,更有甚者就是竞争对手来捣乱的。这搞得每天服务大厅人满为患,服务员应接不暇。饭店服务瞬间处于停滞,这时候需要保安对要进入的客人进行甄别。比如来吃饭的,“请进”;来旅游的,“在门口拍照就行了”;来问路的,“出门右拐”;来捣乱的,报警移送公安。保安就相当于网关,对访问进行控制。

在微服务架构中,后端服务往往不直接开放给调用端,而是通过一个API网关根据请求的url,路由到相应的服务。当添加API网关后,在第三方调用端和服务提供方之间就创建了一面墙,这面墙直接与调用方通信进行权限控制,后将请求均衡分发给后台服务端。

zuul网关

  • 统一入口:未全部为服务提供一个唯一的入口,网关起到外部和内部隔离的作用,保障了后台服务的安全性。
  • 鉴权校验:识别每个请求的权限,拒绝不符合要求的请求。
  • 动态路由:动态的将请求路由到不同的后端集群中。

其它常用的网关有:gateway

负载均衡

饭店生意非常火爆,每天来就餐的客人特别多。只有一个厨师,是满足不了这么多客人的需求的,通常一般大饭店都会有多个厨师同时做菜的。这里面就要引入一个机制,如何高效安排多个厨师的问题。

Ribbon负载均衡策略

  • 随机策略:客户下完单后随机找一个空闲的厨师做菜。
  • 轮询策略:给厨师安排一个顺序,厨师按序号做菜。
  • 最小空闲策略:找一个当时相对空闲的厨师做菜。
  • 最佳匹配策略:比如客户点的是鱼,就找擅长做鱼的厨师。
  • 加权策略:比如有个高级厨师段长菜快且菜品好,就优先安排他做菜。

负载均衡的策略还有很多,终归一点就是在高并发的情况,为上游快速提供优质服务

熔断器

这家饭店有一道祖传招牌菜酸菜鱼,每天点得特别多。为什么好吃呢?因为都是活鱼现杀现作,肉质细嫩。现在梳理一下客人点酸菜鱼的处理流程:

eureka原理及执行流程(eureka原理及使用)

可以看到客人点完餐后,由点餐员给厨师下单,这时厨师要向杀鱼要食材。这时候假如杀鱼师傅太少或者临时有事,就造成了厨师什么也不做等待杀鱼师傅提供食材,点餐员等待厨师做菜,客人等待上菜,整个流程都处于等待之中,甚至于全体员工都处于等待之中而无所事事。这时候又来一个客人,说我不吃鱼,我只要一碗清汤面。而你告诉客人,现在做不了,因为所有人都在等待杀鱼师傅杀鱼。客人会不会有一种心态要崩的感觉?这个时候就需要引入熔断器机制,及时对有问题的服务进行降级,限制对故障服务的访问。

Hystrix熔断器原理

因服务提供者的不可用导致服务调用者的不可用,并将不可用逐渐放大的过程叫雪崩效应。熔断器来监控服务健康情况并对服务进行降级。熔断器开关由关闭到打开的状态转换是通过当前服务健康状况和设定阈值比较决定的(服务的健康状况 = 请求失败数 / 请求总数)。

  1. 当熔断器开关关闭时,请求被允许通过熔断器. 如果当前健康状况高于设定阈值,开关继续保持关闭。如果当前健康状况低于设定阈值, 开关则切换为打开状态。
  2. 当熔断器开关打开时,请求被禁止通过。
  3. 当熔断器开关处于打开状态,经过一段时间后, 熔断器会自动进入半开状态,这时熔断器只允许一个请求通过。当该请求调用成功时,熔断器恢复到关闭状态。若该请求失败, 熔断器继续保持打开状态,接下来的请求被禁止通过。,

熔断器的开关能保证服务调用者在调用异常服务时,快速返回结果,避免大量的同步等待。 并且熔断器能在一段时间后继续侦测请求执行结果,提供恢复服务调用的可能。

继续上面案例,如果杀鱼环节出现故障,熔断器就会限制厨师访问杀鱼环节。如果在客人下单环节发现下游流程中可能会调用到杀鱼环节,也会限制访问,可以直接给客人一个反馈“鱼已售磬”。

分布式配置中心

这个比较好理解,比如在饭店管理中要保证统一的对外形象。这就需要企业要有一套标准的规章制度,包括仪容仪表、考勤纪律等等。每个员工在工作中都遵循统一的形象要求,不然就像一个大杂烩。

Spring Cloud Config配置中心

用来统一管理项目中所有配置的系统,同时配置中心要支持高可用。具有有以下优势:

  1. 采用“配置集中管理”,可以很好地解决传统的“配置文件过于分散”的问题。所有的配置都集中在配置中心这一个地方管理,不需要每一个项目都自带一个,这样极大地减轻了开发成本。
  2. 采用“配置与应用分离”,可以很好地解决传统的“配置文件无法区分环境”的问题,配置并不跟着环境走,当不同环境有不同需求的时候,就到配置中心获取即可,极大的减轻了运维部署成本。
  3. 具备“实时更新”的功能,就是用来解决传统的“静态化配置”的问题。线上系统需要调整参数的时候,只需要在配置中心动态修改即可。

其它常用的配置中心Apollo

今天就分享到这里,希望对大家有所帮助!谢谢支持!

每天一个小知识,每天进步一点点!!![加油][加油][加油]

    

使用无须实名的阿里云国际版,添加 微信:ksuyun  备注:快速云

本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 cloud@ksuyun.com 举报,一经查实,本站将立刻删除。
如若转载,请注明出处:https://www.hanjifoods.com/22247.html