赞
踩
微服务架构是一种架构模式或者说是一种架构风格,它提倡将单一应用程序划分为一组小的服务,每个服务运行在其独立的自己的进程中,服务之间相互协调、互相配合,为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API),每个服务都围绕着具体的业务进行构建,并且能够被独立的构建在生产环境、类生产环境等。另外,应避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建,可以有一个非常轻量级的集中式管理来协调这些服务,可以使用不同的语言来编写服务,也可以使用不同的数据存储。
Eureka
:服务注册与发现Zuul
:服务网关Ribbon
:客户端负载均衡Feign
:声明性的Web服务客户端Hystrix
:断路器Config
:分布式统一配置管理服务调用方式:
注册中心:
服务网关:
Eureka
:服务注册中心(可以是一个集群),对外暴露自己的地址提供者
:启动后向Eureka注册自己信息(地址,提供什么服务)消费者
:向Eureka订阅服务,Eureka会将对应服务的所有提供者地址列表发送给消费者,并且定期更新心跳(续约)
:提供者定期通过http方式向Eureka刷新自己的状态(每30s定时向EurekaServer发起请求)
当一个服务未按时进行心跳续约时,在生产环境下,因为网络延迟等原因,此时就把服务剔除列表并不妥当,因为服务可能没有宕机。 Eureka就会把当前实例的注册信息保护起来,不予剔除。生产环境下这很有效,保证了大多数服务依然可用。但是有可能会造成一些挂掉的服务被剔除有延迟。
1、ZooKeeper中的节点服务挂了就要选举
,在选举期间注册服务瘫痪,虽然服务最终会恢复,但是选举期间不可用的, 选举就是改微服务做了集群,必须有一台主其他的都是从。
2、Eureka各个节点是平等关系
,服务器挂了没关系,只要有一台Eureka就可以保证服务可用,数据都是最新的。 如果查询到的数据并不是最新的,就是因为Eureka的自我保护模式导致的。
3、Eureka本质上是一个工程
,而ZooKeeper只是一个进程
。
4、Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像ZooKeeper 一样使得整个注册系统瘫痪。
5、ZooKeeper保证的是CP
,Eureka保证的是AP
CAP解释:
C:一致性Consistency (取舍:强一致性、单调一致性、会话一致性、最终一致性、弱一致性)
A:可用性 Availability
P:分区容错性Partition tolerance
zuul是对SpringCloud提供的成熟对的路由方案
,他会根据请求的路径不同,网关会定位到指定的微服务,并代理请求到不同的微服务接口,他对外隐蔽了微服务的真正接口地址。
三个重要概念:
动态路由表
:Zuul支持Eureka路由,手动配置路由,这俩种都支持自动更新路由定位
:根据请求路径,Zuul有自己的一套定位服务规则以及路由表达式匹配反向代理
:客户端请求到路由网关,网关受理之后,在对目标发送请求,拿到响应之后在 给客户端Zuul的应用场景: 对外暴露,权限校验,服务聚合,日志审计等
在Spring Cloud Netflix中,Zuul巧妙的整合了Eureka来实现面向服务的路由。
实际上,API网关将自己注册到Eureka服务注册中心上,也会从注册中心获取所有服务以及它们的实例清单。在Eureka的帮助下,API网关已经维护了系统中所有serviceId与实例地址的映射关系
。当有外部请求到达API网关的时候,根据请求的URL找到最匹配的path,API网关就可以知道要将该请求"路由"到哪个具体的serviceId上去。 最终通过Ribbon的负载均衡策略
实现请求的路由。
1.feign采用的是基于接口
的注解
2.feign整合了ribbon,具有负载均衡
的能力
3.整合了Hystrix,具有熔断
的能力
1、通过动态代理生成实现类
2、根据接口类的注解生命规则,解析出底层的methodhandler
3、拦截器负责对请求和返回进行包装和处理
4、通过均衡负载http去访问远程服务
在分布式系统,我们一定会依赖各种服务,那么这些个服务一定会出现失败的情况,就会导致雪崩,Hystrix就是这样的一个工具,防雪崩利器,它具有服务降级,服务熔断,服务隔离,监控等一些防止雪崩的技术。
Hystrix有四种防雪崩方式:
服务降级
:接口调用失败就调用本地的方法返回一个空服务熔断
:接口调用失败就会进入调用接口提前定义好的一个熔断的方法,返回错误信息服务隔离
:隔离服务之间相互影响服务监控
:在服务发生调用时,会将每秒请求数、成功请求数等运行指标记录下来。1、构造一个 HystrixCommand
或HystrixObservableCommand
对象,用于封装请求,并在构造方法配置请求被执行需要的参数;
2、执行命令,Hystrix提供了4种执行命令的方法;
3、判断是否使用缓存响应请求,若启用了缓存,且缓存可用,直接使用缓存响应请求。Hystrix支持请求缓存,但需要用户自定义启动;
4、判断熔断器是否打开,如果打开,跳到第8步;
5、判断线程池/队列/信号量是否已满,已满则跳到第8步;
6、执行HystrixObservableCommand.construct()
或HystrixCommand.run()
,如果执行失败或者超时,跳到第8步;否则,跳到第9步;
7、统计熔断器监控指标;
8、走Fallback
备用逻辑
9、返回请求响应
服务熔断:
熔断机制是应对雪崩效应
的一种微服务链路保护机制
。
当某个微服务不可用或者响应时间太长时,会进行服务降级,进而熔断该节点微服务的调用,快速返回“错误”的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。
在SpringCloud框架里熔断机制通过Hystrix
实现,Hystrix会监控微服务间调用的状况,当失败的调用到一定阈值,缺省是5秒内调用20次,如果失败,就会启动熔断机制。
服务降级:
服务降级,一般是从整体负荷考虑。就是当某个服务熔断之后,服务器将不再被调用,此时客户端可以自己准备一个本地的fallback回调
,返回一个缺省值。
雪崩效应是在大型互联网项目中,当某个服务发生宕机时,调用这个服务的其他服务也会发生宕机,大型项目的微服务之间的调用是互通的,这样就会将服务的不可用逐步扩大到各个其他服务中,从而使整个项目的服务宕机崩溃。
集群:
注册多台 Eureka,把 SpringCloud服务互相注册,客户端从 Eureka获取信息时,按照 Eureka的顺序来访问。
Run()
:过滤器的具体业务逻辑shouldFilter()
:判断过滤器是否有效filterOrder()
:过滤器执行顺序filterType()
:过滤器拦截位置通过path
配置拦截请求,通过 Serviceld
到配置中心获取转发的服务列表,zuul内部使用 Ribbon
实现本地负载均衡和转发。
使用Nginx的 upstream
设置Zuul服务集群,通过location
拦截请求并转发到 upstream
,默认使用轮询机制对Zuul集群发送请求。
通俗易懂的理解:
集群:是把一个的事情交给多个人去做,假如要做1000个产品给一个人做要10天,叫10个人做就是一天;
负载均衡:用来控制集群,他把做的最多的人让他慢慢做休息会,把做的最少的人让他加量让他做多点。
在计算中:
负载平衡可以改善跨计算机计算机集群,网络链接,中央处理单元或磁盘驱动器等多种计算资源的工作负载分布,负载平衡旨在优化资源使用,最大化吞吐量,最小化响应时间并避免任何单一资源的过载,使用多个组件进行负载平衡,而不是单个组件,可能会通过冗余来提高可靠性和可用性,负载平衡通常及专用软件或硬件,例如多层交换机或域名系统服务器进程。
Hystrix实现服务降级的功能是通过重写 HystrixCommand
中的 getFallback()
方法,当 Hystrix的run方法或 construct执行发生误时转而执行 getFallback()
方法。
发送端(endpoint)构造事件event,将其publish到context上下文中(spring cloud bus有一个父上下文,bootstrap),然后将事件发送到channel中(json串message),接收端从channel中获取到message,将message转为事件event,然后将event事件publish到context上下文中,最后接收端(Listener)收到event,调用服务进行处理。
整个流程中,只有发送/接收端从context上下文中取事件和发送事件是需要我们在代码中明确写出来的,其它部分都由框架封装完成。
springcloud config实时刷新采用 SpringCloud Bus
消息总线
熔断机制:
是应对雪崩效应的一种微服务链路保护机制
。
当某个微服务不可用或者响应时间太长时,会进行服务降级,进而熔断该节点微服务的调用,快速返回“错误”的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。
在SpringCloud框架里熔断机制通过Hystrix
实现,Hystrix会监控微服务间调用的状况,当失败的调用到一定阈值,缺省是5秒内调用20次,如果失败,就会启动熔断机制。
服务降级:
一般是从整体负荷考虑。就是当某个服务熔断之后,服务器将不再被调用,此时客户端可以自己准备一个本地的fallback回调,返回一个缺省值
雪崩效应是在大型互联网项目中,当某个服务发生宕机时,调用这个服务的其他服务也会发生宕机,大型项目的微服务之间的调用是互通的,这样就会将服务的不可用逐步扩大到各个其他服务中,从而使整个项目的服务宕机崩溃
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。