微服务治理

服务治理

服务化的关键是服务治理。

服务治理主要包括服务发现、负载均衡、限流、熔断、超时、重试、服务追踪。

服务发现

如果服务少，可以通过硬编码或配置文件提供服务地址。但是面对大量服务实例和频繁的上线部署，服务之间如果想知道彼此的服务地址和运行状态，这时候就需要服务发现组件来实现。

服务发现概述

使用一个注册中心来记录分布式系统中全部服务信息，以便让其他服务能快速找到这些已经注册的服务。要尽量做到高可用。服务发现模块需要有服务注册、服务查找、服务健康检查和服务变更通知等关键功能。可以通过服务名称来查找和使用服务，而不需要提供网络地址和端口号。

DNS可以说是最早的服务发现实例。

微服务更新、发布频繁，并且常根据负载情况进行弹性伸缩，因此微服务IP地址变化是常态。

服务发现基本机制：

• 服务提供者在服务启动时，将服务名称、IP地址、访问端口以及其他服务的元数据信息注册到注册中心。
• 注册中心与服务提供者无法维持心跳探测时会将服务从注册中心剔除。
• 服务消费者从注册中心获取服务提供者最新信息时，可以使用定期拉取和事件通知两种方式。

负载均衡

实现高可用、网络流量疏导、和扩容的重要手段。本质是通过算法将请求分摊到多个服务节点。

服务端的负载均衡

负载均衡器会维护一个可用服务列表，并通过心跳检测将发生故障而无法及时响应心跳的服务移除。当负载均衡器接收到客户端请求时，通过轮询、权重或流量负载等负载均衡算法将请求转发到相应的服务器。

传输层（第四层）负载均衡：基于IP地址和端口号进行负载均衡。

通过修改报文中的目标地址和端口号，转发请求。

四层负载均衡的性能强于七层负载均衡。

应用层（第七层）负载均衡：基于URL和请求头。解析应用层的内容，转发请求。

七层的优势是充分理解应用层协议的意义，转发更加灵活。Nginx是七层的。

服务端负载均衡的：

• 优势：对业务开发无侵入性；不影响应用代码。

• 缺点：服务端负载均衡器是整个系统处理的瓶颈。另外需要经过负载均衡器进行转发，效率低。

• 场景：服务端负载均衡多用于前端与后端交互、应用与数据库交互等场景。

对于应用后端服务之间的调用，还是通过客户端负载均衡实现的方案居多。

客户端负载均衡

与服务端负载均衡的区别是，客户端来选择连接到哪个服务器，而不是由客户端连接到一个服务端再由服务端分发请求。

• 优点：由客户端内部程序实现，并且直接连到服务端，而不是经过中间负载均衡器转发。绕过了中心化的负载均衡和代理节点，不用考虑中心节点的高可用。

• 缺点： 应用程序更加复杂。无法做到异构语言之间的负载均衡透明化。客户端和服务端的连接多。

采用客户端负载均衡的框架有：Dubbo 和 Spring Cloud的Ribbon（这些都是侵入式治理方案）。

Ribbon提供了客户端的负载均衡算法，并可以与服务发现和注册中心（Eureka）有效的整合到一起（Ribbon会通过Eureka注册中心获取服务列表）。另外，Ribboon还提供了连接超时和重试的能力。

限流

保护服务不会被突然的流量洪峰冲垮。对一个时间窗口内的请求流量进行限速来实施对系统的保护。一旦达到限速阈值，则进入限流的处理流程：

• 拒绝服务： 定向到错误页面，或返回失败。
• 排队等待：将请求放入队列，等有时间再处理，客户端通常有超时等待时间。适用于 “秒杀”或抢购。

限流算法

• 计数器限流算法： 统计一段时间窗口之内的请求数量来进行限流。

• 漏桶算法：容量固定的桶，桶底有一个洞，入桶速度任意，但是出桶速度固定。这个方法主要是控制其他系统的回调洪峰。

• 令牌桶算法：使用存放固定数量的令牌的桶，按照固定速率向桶中添加令牌，如果有请求需要被处理，就从桶中取出令牌，当令牌用光了，就将请求放入队列或直接被拒绝。

令牌桶算法与漏桶算法最明显的区别是： 其允许一定程度上的流量突发。

熔断

流量过载时，禁止客户端对服务端访问。比如当大量响应超时，熔断可以让对该服务的调用快速返回，防止目标服务宕机。

熔断可以防止雪崩。

熔断器模式

• 关闭状态：对应用无干涉，仅仅计算时间窗口内的失败次数。
• 开启状态：对服务的访问立即返回错误。

• 半开启状态：只允许少量请求调用服务，如果调用结果符合预期，就认为服务端问题已经修复，这样熔断器会关闭；否则认为熔断器仍然有问题，转换到开启状态，并重新计时。

降级

服务降级是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。

举个栗子：双十一的时候，我们买东西是不是都不允许修改购物地址，不允许发起退货，不允许退款还有很多服务都不可以用，只允许用户选择商品加入购物车付钱。那天只有一个目的就是让一些不是很重要的服务所占用的cpu资源都让出来，给购物，付款这样的核心服务。这样的话，用户付款的速度就会越来越快，毕竟前多少名支付的用户是有免单机会的（大家都会挤在0点那一刻去付款）。服务降级主要用于当整个微服务架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时，为了保证重要或基本的服务能正常运行，将一些 不重要 或 不紧急 的服务或任务进行服务的 延迟使用 或 暂停使用。
降级就是为了解决资源不足和访问量增加的矛盾。

服务降级方式

• 延迟服务：定时任务处理、或者mq延时处理。比如新用户注册送多少优惠券可以提示用户优惠券会24小时到达用户账号中，我们可以选择再凌晨流量较小的时候，批量去执行送券。
• 页面降级：页面点击按钮全部置灰，或者页面调整成为一个静态页面显示“系统正在维护中，。。。。”。
• 关闭非核心服务：比如电商关闭推荐服务、关闭运费险、退货退款等。保证主流程的核心服务下单付款就好。
• 写降级：比如秒杀抢购，我们可以只进行Cache的更新返回，然后通过mq异步扣减库存到DB，保证最终一致性即可，此时可以将DB降级为Cache。
• 读降级：比如多级缓存模式，如果后端服务有问题，可以降级为只读缓存，这种方式适用于对读一致性要求不高的场景。

参阅：https://www.cnblogs.com/liufei1983/p/11470081.html