For investors
股价:
5.36 美元 %For investors
股价:
5.36 美元 %认真做教育 专心促就业
我们在前几期的文章中给大家简单介绍了微服务架构的一些基础知识与应用场景等内容,而本文我们就继续来学习一下,如何进行服务可用性治理。
1、流量调控
流量调度中的金丝雀场景,你可以先放行一部分流量到一个新的服务实例中,这个新的服务实例只有你的研发和测试团队可以接入。可以在上面试用或者测试,直到你确认你的服务是健康的,没有bug的,再把流量逐渐的迁移过去。
这个的好处是减少发布新功能存在的风险,而且全程是无停服发布,对用户是透明无感知的,大大提高了可用性。
2、流量染色
流量染色也是一种的场景。如果你想让不同的用户群体(比如这边的GroupA、GroupB、GroupC)使用的功能也是不同的,那流量染色是一个不可缺少的功能。
它可以把符合某些特征的用户流量调控到对应的服务版本中。比如GroupA是学生群体,对应到V1版本,GroupB是老人群体,对应到V2版本。需要注意的是,如果是一条完整的链路,那链路上的各个服务包括数据存储层都应该有不同的版本,这样才能一一对应。
3、请求高可用
假设你有两个服务,服务A和服务B,服务A向服务B请求数据。但是B服务由于非常繁忙,在给定的时间周期内(红色时间线)都无法响应。而这个红色时间线是A服务固定的超时时间,如果这个时间之后还没有等到B服务的响应,A服务就不等了,去执行其他的任务。
这个其实就是一个超时的基本概念。它的意义在于可以避免一些长时间的无意义的等待,因为这个时候下游可能是处于故障或者有请求堆积,短时间内可能是无法返回正常的结果的。
因此,服务A在超时之后,可以及时释放自己的一些资源,比如线程或者是请求相关的其他资源。
在实践中,超时时间的设置通常要比正常的请求时间稍微大一些(正常的返回时间可以根据平响进行分析),这样可以避免请求还没有来得及返回就触发超时。当然这个超时时间也不能设置太大。如果太大的话,在服务B出现异常的时候,服务A不能够及时的释放资源,会导致请求堆积,降低自身服务的吞吐能力。
4、重试
跟上面一样,A服务向B服务获取数据,由于B服务非常繁忙,在给定的超时时间内无法获得响应数据。于是A设置了重试机制,在超时时间结束之后,重新获取一下B服务的数据,这时候B服务已经不忙碌了,很快就把正常数据响应给A服务。
可以看到,重试的意义在于可以提升一次请求的成功率。通常重试不仅可以配合超时,也可以配合一些其他种类的失败。
比如B服务5xx错误了,但可能是有概率的错误,所以重试一次就可能获取到想要的结果。当然重试也有一些注意事项,避免重试带来其他灾难。
重试尽量避开之前已经选择过的失败实例,因为这个时候再重试,大概率还是错误的,意义不是特别大。
其次重试的次数也不能太多,否则很容易对服务B造成数倍的压力,导致服务B发生一些雪崩。
对于多次重试,我们通常可以配合一些类似于退避重试的策略来减缓对服务B的压力。退避策略说明,算法
5、快速重试(backuprequest)
同上面一样,服务A向服务B发起一个正常的请求,服务B工作繁忙,A服务在给定的超时时间之前都无法获得响应。按照之前的做法就是等超时时间达到的时候,再发起一次请求。
但是可以在超时时间到达之前做一次更智能的处理,比如超时时间线的中间点,再请求一次服务B。可以看到,重试其实就是一次backuprequest。正是由于它在正常的超时之前就触发了,所以我们叫它快速重试。
这次快速重试,刚好服务B可能已经缓过来。他就收到了这个请求,给服务A返回了这个结果。
服务A在正常的超时触发之后,就是红色这条线,他也会发起一次正常的标准重试,这个时候服务B也有可能会再给他返回一次信息,快速重试的返回和正常返回,他们的时序是有可能不一定的。通常我们的处理方法是服务A先收到哪一个回复,就以哪个为准。后面收到了就会被抛弃掉。
这边需要注意的是,多一次重试会有一定的额外资源开销,所以在使用的时候,需要注意快速重试和正常重试合理设置,避免总的重试次数过多导致服务可用性反受影响。
6、负载均衡
假设服务B有多个实例,对于服务A的请求,我们希望它是比较均匀的流向B服务的各个实例,这样才能真正做到负载均衡,提供更稳定的服务。比较常用的一些策略比如随机轮询、RR顺序轮询等。
我们在实际的生产实践中会有一些比较高级的负载均衡策略,比如说LeastConn、LeastRequest,他会观测你后端集群中连接数、请求数少的实例进行分配。
还有如LA负载均衡策略,它可以动态计算后端的压力,比如说,可以根据qps和延迟来算一个权重。那些qps很高,延迟又很低的后端实力,我们可以认为它是一个比较优秀的后端实例,处理能力比较强,我们会给它比较高的权重,反之就给一个稍微低一些的权重。
另外一个比较常用的负载均衡策略就是一致性哈希。一致性哈希指的是说保证相同来源的请求能够落入相同的后端实例。这在一些后端实例有缓存,或者是有一些类似的场景的话,可以大幅提升请求的性能。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。