服务治理的大概内容

一、序言

1.为什么要微服务拆分

单体架构下：

可扩展性受限

服务和模块的可重用性低

故障隔离范围低

运维复杂度高

没有服务治理

微服务化之后，这些问题都可以解决。

2.为什么要服务治理

服务治理是对于服务的管理，以保证：

1.避免微服务场景下潜在问题发生

服务限流、熔断，都可以避免服务端的瘫痪或者潜在的雪崩风险

2.实现服务的方式是最佳实践

比如服务路由，流量分配

二、服务治理的具体内容

1.服务配置

(1)服务路由

服务路由是通过配置一定的规则，让某些流量，进入某些特定的服务器，一般有以下四种应用场景：

• 线下测试联调

  配置路由规则， 将流量接入用待联调的测试版本。一旦联调出现错误，会将错误范围局限在本服务中。

• 蓝绿发布

  蓝绿发布时，将蓝组或者绿组的流量去除，进行更新和发布，这个时候流量由剩下一组承担。发布完成之后，对剩下一组进行同样的操作。

• 灰度引流

  灰度发布时，灰度推送到目标机器上。

• 多机房流量收敛

  通过机房便签，对流量进行收敛到同机房内。防止服务之间跨机房产生的额外延迟。所有流量全部收敛在一个机房内，可以避免跨机房带来的延迟。

(2)服务权重

一个服务一般会在多个机器上部署，这些服务器可能存在地域、性能上的差异。我们可以给性能更强的服务端，配置更高的权重。如果负载均衡是默认的随机选择，那就权重高的就更容易被选中。

sofa默认也就是随机

(3)服务容错策略

FailOver：失败自动切换。个人理解就是服务的重试。就是服务消费者发现调用失败或者超时后，自动从可用的服务节点列表总选择下一个节点重新发起调用，也可以设置重试的次数。这种策略要求服务调用的操作必须是幂等的，也就是说无论调用多少次，只要是同一个调用，返回的结果都是相同的，一般适合服务调用是读请求的场景。

比如对于非幂等的调用场景，如果调用失败后，不能简单地重试，而是应该查询服务端的状态，看调用到底是否实际生效，如果已经生效了就不能再重试了；如果没有生效可以再发起一次调用。

FailBack：失败通知。就是服务消费者调用失败或者超时后，不再重试，而是根据失败的详细信息，来决定后续的执行策略。

FailCache：失败缓存。就是服务消费者调用失败或者超时后，不立即发起重试，而是隔一段时间后再次尝试发起调用。

FailFast：快速失败。就是服务消费者调用一次失败后，不再重试。

目前sofa里面只有快速失败和重试(failover)

而快速失败使用起来非常麻烦，重试则需要考虑幂等。所以我们现在不建议使用容错，错了直接返回报错。

2.服务保护

(1)服务限流

在特殊场景、时期下，可能会存在大量请求涌入服务端。而服务端本身承受能力有限，为了保护服务端不被压垮，我们可以对流量进行限制。

雪崩效应：

某个服务本身能承受较大负荷，但是后续调用到的系统并不能承受这般压力，引发崩溃。比如redis雪崩，引发数据库的崩溃。

上下游：

P被C调用，P是上游，C是下游。C要调用P，C没有P无法进行，所以P是上游，C是下游。

限流算法

计数器法和滑动窗口法，都属于流量限制。限制流量的数目。

漏桶法和令牌桶法，都属于流量整形。将大流量，整形为可接受的均匀流量。

1.计数器法

每一个时间段内，统计请求的数目，不超过阈值。等本时间段结束，下一个时间段开始时，计数器清零。

存在边界问题。

 

sofa中的qps算法就是计数器法

2.滑动窗口法

这样就避免了计数器法的临界问题。

 

3.漏桶算法

 

无论什么样的流入流量，流出都是匀速的。桶里装不下的流量，全部丢弃。

4.令牌桶算法

 

请求来了之后，让请求去桶里取令牌，一个请求需要一个令牌。也就是桶里现在有多少令牌，现在就能同时相应所少请求，若无可用令牌，则会直接决绝掉，不响应。（漏桶算法则会在桶里等待，不会直接拒绝掉）

令牌桶会允许一个时间段内，流量超过阈值。比如在一个瞬间，接住了突然来的大流量，然后令牌还在不断生成，所以那个瞬间之后的一个时间段内，处理的请求数确实会超过阈值，最多这个时间段内，如果请求不断的情况下，最多拉到2倍的阈值。

(2)服务熔断

熔断是停止consumer向某一个provider发起的调用行为。

熔断的触发条件，是响应时间异常或者调用出错率较高。这就说明了服务端接口不稳定。为了保障我们的业务能够正常进行，减少后续的出错，我们直接将这个服务熔断掉，从服务提供者列表中剔除。后续请求就会在剩余服务提供者中进行选择。所以熔断并不是直接保护服务端，保护服务端是限流做的事情。

熔断本身和重试没有太大关系，网上很多地方说熔断是重试过多后依然失败，就熔断。而实际上，至少在SOFA体系里面，熔断的触发条件，就是出错的比率和返回时间，和重试没有任何关系。

熔断是通过熔断器来实现的：

 

触发熔断，熔断器打开，拦截所有请求。经过一段时间之后，熔断器试探性的释放一部分请求，观察调用结果，如果有达到预期目标的成功数目，熔断器就关闭，释放所有请求。

半开状态下的调用失败，执行的都是FailFast快速失败策略。

如果基于filter实现，不用单独熔断器，客户端熔断和服务端熔断都存在问题：

这里先阐述一下相关的细节，熔断的开启，是需要满足一定的条件才能触发，比如一段时间内的错误率或者是超时。

1.先看客户端(consumer)熔断：

首先熔断配置，一定会推送所有客户端上。

熔断配置的推送，仅仅是推送一个熔断filter的配置信息，也就是触发条件。而且推送到单个客户端实例上是没有必要的，因为一个服务被熔断，就理应让所有客户端都感知到，都不去这个服务端。

当其中一个客户端实例A1，触发了服务端其中一个实例B1的熔断，这个时候，这个服务端实例大概率是不可用的了。但是剩下的客户端实例A2A3是感知不到的，因为熔断是每个客户端实例自带的filter，所以其他客户端实例A2、A3还会继续调用B1，直到他们也出发了B1的熔断。所以就算B1被熔断，A2A3还是会继续调用B1，进而还会因为B1而导致错误的发生。

2.再看服务端(provider)熔断：

服务端熔断也是会推送到所有服务端上的。当其中一个服务端实例B1的熔断，被客户端实例A3触发之后，才会生效。但是服务端熔断会有个缺点，就是熔断发生在服务端，无法推送给客户端，所以所有的客户端实例A1A2A3还是会继续去调用B1，只有在调用了之后，才会发现，这个服务端已经被熔断掉了，所以直接返回错误信息。只有服务端实例B1达到时间窗口之后，释放一定量的请求，A1A2A3才会得以调用。

上述的问题，需要引入专门的熔断器比如Hystirx才能解决，但是引入专门的熔断器，还需要考虑熔断器本身的HA，需要专门去维护才行。

(3)服务降级

它的作用是在流量高峰期，根据实际业务情况及流量，对某些不重要的服务，不处理或换种简单的方式处理，从而释放服务器资源以保证核心业务正常运作或高效运作。它需要手动去开启。

举个例子就是，双十一的时候，淘宝流量过大，这个时候就可以关闭次要功能，比如评论功能，减少展示一个商品页面所需要的的返回信息。

3.服务安全

黑白名单鉴权

为服务设计黑白名单。黑名单就是不允许被某些应用调用，白名单就是只允许某些应用调用。

我们这里使用较少。