认识达内从这里开始

随着互联网的不断发展，越来越多的人都在学习软件编程开发等互联网技术，而本文我们就通过案例分析来简单了解一下，微服务如何进行服务可用性治理。

我们有很多种方法对服务进行治理来保障服务的高可用。但总的来说有4类：

流量调控：方法主要是金丝雀发布(灰度发布)、ABTesting、流量染色。

请求高可用：方法主要有超时重试、快速重试以及负载均衡。

服务的自我保护：主要包括限流、熔断和降级。

应对故障实例：主要分为异常点驱逐和主动健康检查。

一、流量调控

1、金丝雀发布、ABTesting

流量调度中的金丝雀场景，你可以先放行一部分流量到一个新的服务实例中，这个新的服务实例只有你的研发和测试团队可以接入。可以在上面试用或者测试，直到你确认你的服务是健康的，没有bug的，再把流量逐渐的迁移过去。

这个的好处是减少发布新功能存在的风险，而且全程是无停服发布，对用户是透明无感知的，大大提高了可用性。

2、流量染色

流量染色也是一种的场景。如果你想让不同的用户群体(比如这边的GroupA、GroupB、GroupC)使用的功能也是不同的，那流量染色是一个不可缺少的功能。

它可以把符合某些特征的用户流量调控到对应的服务版本中。比如GroupA是学生群体，对应到V1版本，GroupB是老人群体，对应到V2版本。需要注意的是，如果是一条完整的链路，那链路上的各个服务包括数据存储层都应该有不同的版本，这样才能一一对应。

二、请求高可用

1、超时

假设你有两个服务，服务A和服务B，服务A向服务B请求数据。但是B服务由于非常繁忙，在给定的时间周期内(红色时间线)都无法响应。而这个红色时间线是A服务固定的超时时间，如果这个时间之后还没有等到B服务的响应，A服务就不等了，去执行其他的任务。

这个其实就是一个超时的基本概念。它的意义在于可以避免一些长时间的无意义的等待，因为这个时候下游可能是处于故障或者有请求堆积，短时间内可能是无法返回正常的结果的。

因此，服务A在超时之后，可以及时释放自己的一些资源，比如线程或者是请求相关的其他资源。

在实践中，超时时间的设置通常要比正常的请求时间稍微大一些(正常的返回时间可以根据平响进行分析)，这样可以避免请求还没有来得及返回就触发超时。当然这个超时时间也不能设置太大。如果太大的话，在服务B出现异常的时候，服务A不能够及时的释放资源，会导致请求堆积，降低自身服务的吞吐能力。

2、重试

跟上面一样，A服务向B服务获取数据，由于B服务非常繁忙，在给定的超时时间内无法获得响应数据。于是A设置了重试机制，在超时时间结束之后，重新获取一下B服务的数据，这时候B服务已经不忙碌了，很快就把正常数据响应给A服务。

可以看到，重试的意义在于可以提升一次请求的成功率。通常重试不仅可以配合超时，也可以配合一些其他种类的失败。

比如B服务5xx错误了，但可能是有概率的错误，所以重试一次就可能获取到想要的结果。当然重试也有一些注意事项，避免重试带来其他灾难。

重试尽量避开之前已经选择过的失败实例，因为这个时候再重试，大概率还是错误的，意义不是特别大。

其次重试的次数也不能太多，否则很容易对服务B造成数倍的压力，导致服务B发生一些雪崩。

对于多次重试，我们通常可以配合一些类似于退避重试的策略来减缓对服务B的压力。退避策略说明，算法

3、快速重试(backuprequest)

同上面一样，服务A向服务B发起一个正常的请求，服务B工作繁忙，A服务在给定的超时时间之前都无法获得响应。按照之前的做法就是等超时时间达到的时候，再发起一次请求。

但是可以在超时时间到达之前做一次更智能的处理，比如超时时间线的中间点，再请求一次服务B。可以看到，重试其实就是一次backuprequest。正是由于它在正常的超时之前就触发了，所以我们叫它快速重试。

这次快速重试，刚好服务B可能已经缓过来。他就收到了这个请求，给服务A返回了这个结果。

服务A在正常的超时触发之后，就是红色这条线，他也会发起一次正常的标准重试，这个时候服务B也有可能会再给他返回一次信息，快速重试的返回和正常返回，他们的时序是有可能不一定的。通常我们的处理方法是服务A先收到哪一个回复，就以哪个为准。后面收到了就会被抛弃掉。

这边需要注意的是，多一次重试会有一定的额外资源开销，所以在使用的时候，需要注意快速重试和正常重试合理设置，避免总的重试次数过多导致服务可用性反受影响。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。