Go可用性(七) 总结: 一张图串联可用性知识点

发布时间：2025-11-05 12:11:54 来源：云智核 作者：人工智能

在前面的可用几篇文章当中我们聊到了 隔离设计、令牌桶算法、性总漏桶算法、结张自适应限流和熔断，图串可用性的用性建设远不止这些，这一部分的知识内容在进阶训练营中也讲了 7 个小时，其他部分如果感兴趣的可用话推荐购买源课程观看。

由于前面的性总文章大部分都在讲限流相关的内容，所以我们先看一下不同的结张限流方式的对比

限流对比

微服务可用性设计总结

接下来我们就一起来串联我们之前讲到的和课程上讲到的一些内容总结一下可用性应该怎么做。

微服务可用性设计总结

如上图所示，图串我们从一个简单的用性用户访问出发，用户访问到我们的知识服务一般是先通过我们的移动客户端或者是浏览器，然后请求再依次通过 CDN、可用防火墙、性总API网关、结张BFF以及各个后端服务，整条链路还是比较长的。云南idc服务商

我们上图其实已经一部分体现了隔离设计，所以后面我就不再提了。

1. 移动客户端/浏览器

客户端是触及用户的第一线，所以这一层做的可用性优化尤为的重要

降级: 降级的本质是提供给用户有损服务，所以在触及用户的第一线如何安抚好或者说如何骗过用户的眼睛尤为重要

流控:在服务出现问题的时候，用户总是会不断的主动尝试重试，如果不加以限制会让我们本就不堪重负的后端服务雪上加霜

2. BFF/Client

BFF 是我们后端服务的桥头堡，当请求来到 BFF 层的时候，BFF 既是服务端，又是客户端，因为它一般需要请求很多其他的后端服务来完成数据的编排，提供客户端想要的数据

超时控制：超时控制需要注意的两点是默认值和超时传递

负载均衡：一般我们比较常用的负载均衡策略就是轮训，或者说加个权重，这个比较大的问题就是，我们的服务性能并不是每个实例都一样，收到宿主机的型号，当前机器上服务的数量等等因素的影响，并且由于我们的服务是在随时漂移和变化的，所以我们没有办法为每个实例配上合适的权重。

重试： 重试一定要注意避免雪崩

熔断：一般来说如果只是部分实例出现了问题，我们通过负载均衡阶段+重试一般就可以解决，但如果服务整体出现了问题，作为客户端就需要使用熔断的措施了。

降级： 当我们请求一些不那么重要的服务出现错误时，我们可以通过降级的方式来返回请求，降级一般在 BFF 层做，可以有效的防止污染其他服务的缓存。常见的讨论有返回 mock 数据，缓存数据，空数据等

3. Server

BFF 其实也是服务端，但是为了流畅的讲解，主要将其作为了客户端的角色。服务端主要的是限流的措施，当流量从 BFF 来到我们的服务之后，我们会使用令牌桶算法尝试获取 token，如果 token 不够就丢弃，如果 token 足够就完成请求逻辑。

我们的 token 是从哪里来的呢?

拦截器会定时的向 Token Server 上报心跳数据，包含了一些统计信息，同时从 Token Server 获取一定数量的 Token，当 Token Server 接收到请求之后会通过最大最小公平分享的算法，根据每个服务实例上报的统计信息进行 Token 的分配。

这个其实就是之前没有讲到的分布式限流的思路，在单个服务实例上又使用了单机限流的算法

总结

到这里我们的可用性相关的知识点就算是告一段落了，前面的文章主要讲解了限流的相关知识点，虽然其他的没有细说，但是这一篇总结也算是都涉及到了，包括隔离设计、限流(单机限流、自适应限流、分布式限流)、超时控制、降级、熔断、负载均衡、重试。OK，话不多说，我们下篇文章见。

本文转载自微信公众号「mohuishou」，可以通过以下二维码关注。转载本文请联系mohuishou公众号。

相关文章