微服务实践:服务治理

微服务实践:服务治理

在微服务的演进过程中,为了最大化利用微服务的优势,保障系统的高可用性,需要通过一些类的服务支撑组件来协助服务间有效的协作,这便是服务治理的范畴。

注册发现

为什么需要服务注册发现

  在微服务系统中,服务的消费者需要知道服务提供者的网络地址,才能与之通信。比较简单的实现方式是直接在消费者端或者负载均衡器上进行注册,在发生变化时手动更新。随着服务数量的增多,这种方式会面领如下挑战:

  • 手动注册实例地址的成本高
  • 无法识别服务重启后的网络地址的变化
服务注册发现——客户端发现

  当服务发现的逻辑位于服务消费者端时,称为客户端发现。服务发现简单来说,服务注册发现的过程(客户端发现),共分为以下3个步骤:

  

  1、 服务提供者将实例信息注册到注册中心。

  2、服务调用者根据服务标识,从注册中心查询服务,获取包含网络地址的服务实例列表

  3、与服务实现通信。

   客户端发现的缺点是实现起来较为复杂,因为在各个服务消费者中需要完成以下功能:首先需要维护服务提供者的列表,并且需要不断与注册中心同步以获取服务最新信息;其次,如果服务部署多实例,服务消费者需要实现路由逻辑,即实现负载均衡器。

服务注册发现——服务端发现

  

  1、 服务提供者实例向注册中心注册地址信息。

  2、调用者向服务发送请求,请求被送到负载均衡器。

  3、负载均衡器从服务注册中心查找服务体用这注册的信息。

  4、负载均衡器将请求转发给具体的服务提供者实例。

  服务端发现的好处是服务消费者的实现复杂度会降低。服务消费者只需要发送请求,不需要关心如何与注册中心交互。缺点是由于多个请求多了一次网络跳转,整体性能会有所损失,需要保证它的高可用性。

 

负载均衡

什么是负载均衡

  为了提高可用性、降低延迟,同一个服务可能会部署多个实例,负载均衡就是为了在服务的多个实例之间进行分配负载,已达到优化资源使用、最大化吞吐率,同时避免过载。

服务端负载均衡

  优点是负载均衡对于服务消费者来说是透明的,服务消费者完全感知不到负载均衡的存在,也不需要关心具体被转发至哪个实例。但是当服务数量或调用了增大时,一旦负载均衡器发生故障就导致整个系统不可用。常见的复杂均衡器有如下:

  

 

  还有一些商用的负载均衡器,如F5、NetScaler、Array、AWD的ELB、华为云的ELB等。

客户端负载均衡

  将负载均衡的功能以库的形式集成到服务消费中。服务消费者需要访问某服务时,需要通过内置的负载均衡组件向服务注册中心查询,得到可用的服务提供者列表,然后按照某种负载均衡策略选择一个目标服务地址,最后向目标服务发起请求。

  

 

  服务端负载均衡将负载均衡能力实现在服务内部,因此服务消费者与提供者之间是直接调动,没有额外开销,性能较好。目前客户端负载均衡在很多开源框架中都有实现,如Spring Cloud、Dubbo、ServiceComb等。

负载均衡策略
  • 随机策略
  • 轮询策略
  • 权重策略
  • 响应事件策略

 

配置管理

   服务在运行过程中,需要和其他服务协作,同时他也会依赖基础设施或其他服务完成某项业务功能。在这个过程中,就需要多样化的配置信息。

  • 基础设施的连接信息
  • 协作服务的地址信息
  • 业务行为的配置参数
  • 与特性相关的信息

  源码中硬编码配置信息,虽然实现成本低,但是这种方式不仅缺乏灵活性,而且容易造成信息泄露。因此,较好的方式是将配置与代码分离。采用独立于代码的外部机制存储配置信息。

微服务的配置管理策略

  下图为集中化的配置管理示意图:

  

  其配置变更流程如下:

  

 

多实例的配置信息变更

  对于服务多实例的场景,可以引入轻量级的消息代理,通过广播事件或者消息的方式通知各个实例更新配置。

  

 

容错机制

  生产环境中的每个微服务并不是具有百分百的可靠性。一方面,线性系统的可靠性等于其所包含的每个组件的可靠性之乘积,而各个微服务之间存在错综复杂的关系,让它比线性系统更复杂。另一方面,服务之间跨网络调用,增加了调用失败的可能性。因此,如何保证微服务系统的可靠性,也变得更为复杂和困难。所以,微服务系统在设计之初就需要考虑容错机制,当系统负载过高时,可以确保核心业务不被破坏,以及当某个服务出错时,把影响范围降低到最小,避免整个系统不可用。下面介绍一下常见的容错模式。

限流

  服务的流量可能是动态的,如果流量增加,超过服务承载范围,就会影响用户掩。通过限制服务能使用的资源,当监控到流量超过设定的阈值时,服务拒绝处理新的用户请求。当系统压力过大时,对系统的非核心业务进行限流,避免因压力过大导致整个系统奔溃。

超时和重试

  超时时指当前消费者依赖的服务出现响应延迟时,消费者不用无限等待,而是根据事先设计的超时时间中断调用,及时释放Web容器、数据库等的连接资源。重试通常与超时结合起来,当出现超时时重新发起调用,常用于因网络抖动等导致服务调用出现超时的场景。

  服务雪崩现象如下:

  

 

  服务提供者不可用——>重试加大流量——>服务消费者不可用

  对于服务提供者来说,可通过自动扩容和限流来应对。对于服务消费者来说需要引入服务降级来避免服务雪崩,具体措施包括隔离、熔断和回退。

服务隔离

  微服务架构下系统会包含多个服务,每个服务拥有一个或多个消费者,服务负载过多或故障将影响所有消费者。消费者可以同时向多个服务发送请求,每个请求都消耗资源。当消费者向错误配置或未响应的服务发送请求时,客户端请求使用的资源可能无法及时释放,继续对服务请求会耗尽资源,如耗尽客户端的连接池,导致消费者对其他服务的请求也受到影响,进而不能再向其他服务发送请求

  在软件行业中,可以考虑通过资源隔离来防止有限的资源被耗尽:

  

 

  服务A依赖于服务B、C、D,假设运行服务A的容器有120个线程,当服务B不可用时,服务A重试或外部流量增加,服务A的120个线程会因为服务B的不可用而耗尽。

  如果采用线程隔离的机制,对于服务B、C、D的调用使用不同的连接池,每个服务各分配40个线程。当服务B不可用时,为服务B分配的线程会被耗尽,而为服务C、D分配的80个线程不受影响,服务A仍然可用。

   

 

   使用隔离机制的好处在于:

  • 防止引发服务级联故障
  • 在发生服务故障的时保留一些功能,系统的其他服务和功能将继续运行。

  

熔断和回退

  当电路发生短路时,断路器能够主动熔断电路,以避免灾难发生。借用断路器的原理,引入熔断机制,在服务出现非临时性的故障时,先通过回退机制(直接返回错误、返回空值/缺省值、返回缓存/备份数据)防止重复尝试执行可能失败的操作,同时检测故障是否持续,是否已解决。如果问题已经修复,则重新发起请求。

  熔断机制可以通过「代理 → 断路器」统计最近发生的故障数,来决定是否继续操作或者返回异常。如图 3-40 所示,断路器的状态包括关闭状态、打开状态和半开状态。

   

 

   ● 关闭状态:在默认情况下,断路器处于关闭状态,如果调用持续出错,失败计数器在给定时间段内超过了阈值,断路器进入打开状态

  ● 打开状态:在指定时间段内,不再向服务提供者发送请求,而是直接回退到失败的结果,此时断路器进入打开状态,并且启动超时计时器。

  ● 半开状态:计时器超时后,断路器进入半开状态,即允许发送少量请求进行尝试,并且通过成功计数器计算成功的请求数。如果调用仍然失败,则返回到打开状态,如果成功计数器超过阈值,则断路器回到关闭状态

   熔断机制提供稳定性,让服务从故障中恢复,并最大限度地减少性能的影响。这种机制可定制性较强,可以根据故障类型进行调整。例如,可以将超时计时器的超时时间逐步增加。最初可以将断路器置于打开状态几秒钟,然后如果故障没有解决,将超时时间增加到几分钟。

 

转载于:https://www.cnblogs.com/MrSaver/p/11457085.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值